550 5.7.509 'Sending Domain Does Not Pass DMARC': Fixing the Microsoft Bounce

550 5.7.509 Access denied, sending domain example.com does not pass DMARC verification and has a DMARC policy of reject means Microsoft 365 checked the domain in your From address, found that the message failed DMARC, saw that the domain publishes p=reject, and refused it. The recipient's address is not the issue. Your authentication is. In cold email the usual cause is a sending tool that does not sign DKIM with your domain and uses its own bounce domain, so neither SPF nor DKIM aligns with your From address. Fix alignment at that tool, and the bounce stops.

Reading the bounce

Microsoft's Exchange Online NDR reference (updated 24 August 2026) lists it as:

Code	Text	Cause
5.7.509	Access denied, sending domain [$SenderDomain] does not pass DMARC verification and has a DMARC policy of reject.	The sender's domain in the 5322.From address doesn't pass DMARC.

5322.From is the From header your recipient sees. That is the domain DMARC protects. If your domain publishes p=reject, you have told receivers to refuse mail that fails DMARC, and Microsoft is doing exactly that.

Microsoft's DMARC guide (updated 3 July 2026) also shows the result as a general 550 5.7.1 rejection in its summary of p=reject handling, so you may see either code. The Authentication-Results header will show dmarc=fail action=oreject either way.

How DMARC passes and fails

From the same Microsoft guide: "A message passes DMARC if one or both of the described SPF or DKIM checks pass. A message fails DMARC if both of the described SPF and DKIM checks fail." The checks are:

• SPF alignment: SPF passes for the MAIL FROM (envelope, return-path) domain, and that domain matches the From domain.
• DKIM alignment: a DKIM signature verifies, and its signing domain (d=) matches the From domain.

"Matches" depends on the alignment mode in your DMARC record. Relaxed (r, the default) allows subdomains of the same organisational domain. Strict (s) needs the exact same name.

From address	MAIL FROM or DKIM d=	Relaxed	Strict
you@example.com	example.com	Pass	Pass
you@example.com	bounces.example.com	Pass	Fail
you@example.com	sendingtool.net	Fail	Fail

That third row is the cold email problem in one line.

Why cold email setups trip it

Cause	What it looks like	Fix
Sending tool signs DKIM with its own domain	dkim=pass header.d=sendingtool.net, dmarc=fail	Set up custom DKIM at the tool with your domain
Tool's bounce domain in MAIL FROM	spf=pass smtp.mailfrom=bounce.sendingtool.net	Set a custom return-path on your domain or a subdomain, if the tool supports it
New secondary sending domain without DKIM	Works on the main domain, fails on the new one	Publish DKIM for every sending domain
Strict alignment with a subdomain	aspf=s or adkim=s, MAIL FROM on a subdomain	Use relaxed alignment, or match the From exactly
Forwarding or a gateway that changes the message	DKIM breaks after an intermediary	Usually on the receiving side; ARC helps there
Someone spoofing your domain	Failures from IPs you do not use	Nothing to fix. DMARC is working

A setup that passes at Gmail can still fail at Microsoft if the message took a different path, so test each tool and each domain.

Step 1: read the headers

Send a test from the failing tool to a Microsoft 365 mailbox you can read (one you control, or a colleague's), and open the message headers. If it bounces, the NDR often includes the original headers. Find Authentication-Results. Microsoft's guide gives this example of SPF and DKIM passing while DMARC fails:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Compare three values:

• smtp.mailfrom= (the SPF domain)
• header.d= (the DKIM signing domain)
• header.from= (your From domain)

If neither of the first two matches the third, alignment is your problem. Our email headers explained post walks through the rest of the header, and the DMARC alignment checker does the comparison for you from a pasted header.

Step 2: fix alignment at the sending tool

Microsoft's guide suggests two questions, in order:

1. Can the tool use your domain in MAIL FROM (a custom return-path or bounce domain)? If yes, set it up and SPF aligns.
2. Can the tool sign DKIM with your domain (d=yourdomain.com)? If yes, publish the DKIM record it gives you and DKIM aligns.

You only need one aligned pass. DKIM is the better one to fix, because it survives forwarding and does not depend on the return-path.

If you send through Google Workspace or Microsoft 365 mailboxes connected to a sequencer, the mailbox provider's DKIM is what counts. Make sure it is turned on with your domain:

• Google Workspace DKIM setup
• Microsoft 365 DKIM setup

Find which selectors a domain already publishes with the DKIM selector finder.

Step 3: check every source, not just one

Many domains send from more than one place: mailboxes, a sequencer, a CRM, a billing tool. Any of them can fail DMARC.

1. Make sure your DMARC record has a rua= address so receivers send aggregate reports.
2. Read the reports with the DMARC report analyzer. Microsoft's guide notes the pattern to look for: SPF or DKIM passing but not aligned for a known sending IP.
3. Fix each legitimate source. Failures from IPs you do not recognise are probably spoofing, and your p=reject is blocking them as intended.

Check the whole domain at once with the email domain health checker. Our SPF, DKIM and DMARC explained post covers the three records from the start.

What about lowering the policy?

Changing p=reject to p=none stops this bounce because receivers stop acting on DMARC failures. It also stops them blocking anyone who spoofs your domain. Gmail and Yahoo require bulk senders to have a DMARC policy and to pass DMARC, so a domain that fails alignment has a problem there too, whatever the policy says.

If you must use it as a stopgap while a tool's DKIM is set up, do it for days, not months, and move back up in steps. Our DMARC none to reject guide and DMARC record examples cover a safe rollout.

5.7.509 vs other Microsoft authentication bounces

Code	Where	Meaning
550 5.7.509	Microsoft 365	DMARC failed and the From domain has p=reject
550 5.7.515	Outlook.com consumer	High-volume sender missing SPF, DKIM or DMARC requirements. See 550 5.7.515
550 5.7.606-649	Microsoft 365	Your IP is blocked. See 550 5.7.606

Outlook.com's own sender requirements are covered in Microsoft Outlook's bulk sender requirements. The short code page for this bounce is 550 5.7.509.

Where SimpleVerifier fits

This bounce is about your domain, not your list, so verifying addresses will not change it. SimpleVerifier's free tools help on the domain side: the DMARC alignment checker, DMARC report analyzer and email domain health checker need no account. Domain monitoring on every plan (one sending domain on Starter, ten on Pro) checks SPF, DKIM, DMARC, MX and blocklists daily, so a broken record is caught before a campaign.

Once authentication passes, the list matters again. The first 100 checks are free with a Google sign-in on the verify page. See pricing.