550 5.7.509: your mail fails DMARC so the receiver rejects it outright

Fix it now

Microsoft publishes 5.7.509 as access denied because the sending domain does not pass DMARC verification and has a DMARC policy of reject. The receiver followed your own published instruction. Fix the authentication, not the policy.

Resolve-DnsName contoso.com -Type TXT
Resolve-DnsName _dmarc.contoso.com -Type TXT
Resolve-DnsName selector1._domainkey.contoso.com -Type CNAME

1. Get a failing message and read its Authentication-Results header. It states the SPF result, the DKIM result and the DMARC verdict, and the domain each was evaluated against.
2. List every system that sends using your domain in the From address: Exchange or Exchange Online, marketing and invoicing platforms, scanners and copiers, monitoring tools and line-of-business applications.
3. Publish exactly one SPF TXT record covering all of them. More than one record for a domain makes SPF return permerror, and so does needing more than 10 DNS lookups to evaluate it.
4. Enable DKIM signing for the domain. In Microsoft 365 that means publishing the two selector CNAME records the tenant gives you and then switching signing on for that domain.
5. Send a test message to an external mailbox and read the Authentication-Results header on what arrives.

Most Microsoft 365 organisations need include:spf.protection.outlook.com in the SPF record for the domain.

If the header shows dmarc=pass for your domain you are finished. If SPF passes and DMARC still fails, that is alignment, and the next section is about exactly that.

Why it happens

DMARC does not ask whether SPF passed. It asks whether SPF passed for the same domain that appears in the From line the recipient sees. That is alignment, and it is where most failures live. Microsoft documents two modes, controlled by the aspf and adkim tags: relaxed, the default, where the organisational domains must match and subdomains are allowed; and strict, where the fully qualified domain names must match exactly with no subdomain matching. A marketing platform can produce a perfect SPF pass for its own bounce domain and still fail DMARC for you, because the domain that passed is not the domain in your From header.

DMARC passes if either check aligns and passes, which gives you two independent routes and one important practical consequence: DKIM is the more durable of the two. When a message is forwarded the envelope sender is usually rewritten, so SPF breaks. A DKIM signature survives forwarding as long as the body and the signed headers are not modified, which is why a mailing list that rewrites the subject or appends a footer still breaks it. If your mail is signed, forwarded copies keep passing.

There is a cost to publishing an enforcing policy before your sending sources authenticate, and it is not only the bounces. Microsoft documents that outbound mail from domains in Microsoft 365 that fails DMARC checks at the destination is routed through the high-risk delivery pool when the domain’s DMARC policy is p=reject or p=quarantine, and states there is no override for that behaviour. So a badly timed policy change degrades delivery for the mail that is still getting through, not only for the mail that bounces.

Three of the codes people arrive with here – 5.7.20, 5.7.21 and 5.7.24 – are not in Microsoft’s non-delivery report reference at all. Two that are documented are narrower than they look: 5.7.23 is a Sender Policy Framework violation, and 5.7.26 is specifically about IPv6 – a message sent over IPv6 must pass either SPF or DKIM, and this one is not signed.

Full reference

What alignment actually compares

Relaxed is the default and is the sensible choice for most organisations, because it lets a bounce subdomain or a marketing subdomain align with the organisational domain. Strict is worth having only where you control every sending path and want the exact match, and it is a common cause of a DMARC failure that looks inexplicable until you notice the s in the record.

Which check is failing, from the header

Rolling a policy out without breaking mail flow

1. Publish v=DMARC1; p=none; pct=100; rua=mailto:rua@contoso.com and monitor.
2. Move to p=quarantine, using pct= to raise the share of affected messages gradually – 10, 25, 50, 75, then 100.
3. Move to p=reject; pct=100 once the reports show only legitimate, aligned sources.
4. Repeat for each remaining subdomain in increasing order of volume and complexity, and leave the parent domain until last.
5. Expect some false positives. Microsoft’s own guidance is to go slowly and deal with the issues methodically, because blocking legitimate mail in volume is not acceptable to users.

The codes, and how much of each is published

For the three that are not published, do not reason from the number. Get a copy of the rejected message, read the Authentication-Results header, and fix whichever of SPF, DKIM and alignment it names. That works regardless of which receiver produced the code and regardless of whether anyone has documented it.

Removing the DMARC record makes the bounces stop and hands your domain back to anyone who wants to forge it. That is a decision to stop protecting the domain, not a fix. If you need immediate relief while you work, move the policy to p=none and keep the reporting address so you can still see what is happening.

Things worth checking once and writing down

• Exactly one SPF TXT record per domain and per subdomain that sends.
• The lookup count in that record, kept comfortably under 10.
• Both DKIM selector records published, so a key rotation does not create a gap.
• An aggregate reporting address that somebody actually reads.
• A list of every system that sends as the domain, kept with the DNS records rather than in somebody’s head.

Every code this article covers

Confirm the fix worked

1. A test message to an external mailbox shows an Authentication-Results header with a DMARC pass for your domain.
2. The domain returns exactly one SPF TXT record, and it covers every sending system you identified.
3. That record needs 10 or fewer DNS lookups to evaluate.
4. _dmarc.contoso.com returns the policy you intended, including an aggregate reporting address.
5. Aggregate reports over the following days show your legitimate sources passing, with no unexplained sources left.

Questions people ask about this