How is 550 5.7.509 different from 550 5.7.1?

5.7.1 (RFC 3463) is the generic 'delivery not authorized' — a single SPF hard-fail, a blocklist hit, or a policy refusal, and it long predates DMARC. 5.7.509 is specific and newer: it fires only when the sender's *own* From domain publishes a DMARC policy of `p=reject` and the message failed DMARC — no SPF or DKIM pass that aligns with that From domain. The wording is the giveaway: 'does not pass DMARC verification and has a DMARC policy of reject.' 5.7.1 says 'something refused you'; 5.7.509 says 'you told the world to reject unaligned mail from your domain, and this message was unaligned, so we did.'

It's my legitimate mail. Why is Microsoft rejecting it under my own policy?

Because passing an authentication check isn't the same as aligning it, and DMARC only counts alignment. DMARC passes when an SPF *or* DKIM result aligns with the domain in your visible From header. A third-party sender — a marketing platform, a helpdesk, a billing system — often passes SPF on its own bounce domain and signs DKIM with its own signing domain. Both pass; neither matches your From; so DMARC sees no aligned pass and fails. Once your domain publishes p=reject, a Microsoft mailbox honors it and returns 5.7.509. The mail is 'yours,' but from DMARC's point of view it authenticated as someone else.

Didn't Microsoft used to ignore p=reject?

For years, effectively yes — Exchange Online Protection would override a sender's reject policy and quarantine or junk the message instead of bouncing it, which quietly undercut DMARC. That changed: Microsoft rolled out DMARC policy handling that honors the sender's published action by default, so p=reject now means reject (5.7.509) and p=quarantine means quarantine. On the receiving side it's governed by the tenant's anti-phishing policy (the HonorDmarcPolicy setting), but the default now respects your policy. That's why mail that 'always worked' can suddenly bounce with no change on your end — the receiver stopped ignoring the instruction you'd been publishing all along.

Views: 12

550 5.7.509: Fix Microsoft's DMARC Reject Bounce

550 5.7.509 means Microsoft enforced your own p=reject policy on unaligned mail. Fix alignment in 4 checks: SPF, DKIM, DMARC. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your mail to a Microsoft 365 or Outlook recipient bounces with 550 5.7.509 and a line like “Access denied, sending domain [your-domain] does not pass DMARC verification and has a DMARC policy of reject.” Nothing was delivered. This isn’t a spam score or a reputation dip — and the twist that trips everyone up is that the rejecting server is enforcing your rule, not one of its own. Your From domain publishes DMARC p=reject, this particular message didn’t pass DMARC, and Microsoft did exactly what your policy told every receiver to do: refuse it.

That makes 5.7.509 a strangely honest error. It’s not asking you to get past a filter. It’s telling you that a message claiming to be from your domain couldn’t prove it, and you’ve already instructed the world to reject exactly that. So there are only two real cases, and your whole diagnosis is picking which one you’re in: the mail is legitimately yours but not DMARC-aligned, or the mail is spoofed and the reject is working as designed.

Symptoms

The bounce/NDR carries 550 5.7.509 and names DMARC and a policy of reject explicitly.
It affects a specific sending stream — often one vendor or app (a CRM, a newsletter tool, a ticketing system) — while mail sent straight from your primary provider still lands.
It can start suddenly with no change on your side, because the receiver began honoring p=reject rather than quietly quarantining.
Mail from the same domain through a well-configured path is fine; the failing path is the one that isn’t aligned.
The recipient is on Microsoft (Microsoft 365 / Exchange Online / outlook.com), which is what pins the code to Microsoft’s DMARC handling.

What 550 5.7.509 Actually Means

DMARC ties two existing checks — SPF and DKIM — to the domain a human actually sees in the From header, and adds a published policy for what to do when neither one aligns. “Alignment” is the whole point: an SPF pass counts for DMARC only if the domain SPF authenticated matches your From domain, and a DKIM signature counts only if the signing domain (d=) matches your From domain. A message passes DMARC if at least one of those aligns. If neither does, the message fails DMARC, and the receiver applies whatever your DMARC record’s p= tag says: none, quarantine, or reject.

550 5.7.509 is Microsoft applying p=reject. The receiving side is governed by the recipient tenant’s anti-phishing policy — the HonorDmarcPolicy control — but the modern default honors the sender’s stated policy instead of overriding it, which is a change from the years when Exchange Online would silently downgrade a reject to a quarantine. So the code is precise: it means DMARC failed and your domain asked for rejection. Reissuing nothing, whitelisting nothing on the receiver’s end, changing no spam setting will move it. The only thing that clears 5.7.509 for legitimate mail is making that sending stream produce an aligned SPF or DKIM pass.

This is also what separates it from its neighbors. 5.7.1 is the old generic policy denial with no DMARC semantics. 5.7.26 is Gmail’s “multiple authentication checks failed” bulk-sender rule — same idea, different receiver and rulebook. 5.7.515 is Outlook.com’s consumer bar for high-volume senders, a separate enforcement track. And 5.7.520 isn’t authentication at all — it’s Microsoft blocking external auto-forwarding. 5.7.509 is the one, and only, code that means “your published DMARC reject policy caught this message.”

Top Causes

A third-party sender that isn’t aligned to your domain — The most common by far. A marketing, support, or billing platform sends “as” you but passes SPF on its own return-path and signs DKIM with its own domain. Both authenticate; neither aligns with your From; DMARC fails; p=reject bounces it. The fix is to make that vendor sign DKIM as your domain (usually a CNAME they provide) or align the Return-Path so SPF matches.
SPF-only setup broken by forwarding — If a stream relies on SPF alignment alone and the mail gets forwarded, the forwarding hop changes the envelope sender and SPF no longer aligns (or fails outright). Without an aligned DKIM signature to fall back on, DMARC fails after the forward. DKIM alignment is the durable fix, because a valid DKIM signature survives forwarding when the body is unchanged.
Genuine spoofing — working as intended — If you don’t actually send from that domain through the failing path, 5.7.509 is DMARC doing its job: someone forged your domain and your p=reject stopped it at a Microsoft mailbox. There’s nothing to “fix” on the message; the correct response is to confirm the source is not yours and treat the reject as a successful defense.

Diagnose with DechoNet

Email / DMARC Check reads your domain’s published SPF, DKIM, and DMARC records from DNS — including the actual p= value that’s driving the reject and whether your SPF and DKIM are set up to align with your From domain in the first place. That tells you what policy you’ve committed to and whether an aligned path even exists.
Email Header Analyzer is the other half: paste the bounced message’s headers (or a delivered copy) and read the Authentication-Results line to see exactly which check passed, which aligned, and which failed. That’s how you tell “SPF passed but didn’t align” from “DKIM was never signed,” which decides your fix.
DNS Lookup confirms the TXT records the vendor asked you to add (DKIM selector CNAMEs, SPF includes) are actually live and resolving, since a missing or mistyped record is a frequent reason a “configured” stream still isn’t aligned.

Resolution Checklist

Confirm the message is legitimately yours. If you don’t send through that path, 5.7.509 is your DMARC policy blocking a spoof — no fix needed; it’s working.
Read the bounced message’s Authentication-Results. Establish whether SPF and/or DKIM passed, and separately whether either aligned with your From domain. Passing without aligning is the classic 5.7.509 cause.
For a failing third-party stream, set up DKIM signing as your domain with the vendor (the CNAME/selector they provide). Aligned DKIM is the most reliable path and survives forwarding.
Align SPF where you can — use a Return-Path/bounce domain on your own domain so the SPF-authenticated domain matches your From.
Verify with an external Email / DMARC Check that your published records resolve and that at least one aligned method now exists, then re-send and confirm the bounce is gone.
Only consider loosening your DMARC policy (to p=quarantine or p=none) as a temporary, deliberate step while you fix alignment — not as the fix. Weakening the policy to stop the bounce also weakens the protection you published it for.

When to Escalate

If the failing mail comes through a third-party platform, escalate to whoever administers that platform and your DNS: they need to enable domain-aligned DKIM and/or an aligned Return-Path for your domain. The Microsoft recipient can’t fix this — they’re only honoring the policy you published.
If mail breaks only after forwarding, escalate to the forwarding operator or move the stream to rely on aligned DKIM rather than SPF; SPF cannot survive most forwards, and no receiver-side change on Microsoft’s end will restore alignment.
If you’ve confirmed the source isn’t yours, there’s no delivery to rescue — but treat the pattern as intelligence: repeated 5.7.509 rejects for mail you didn’t send is a signal that something is spoofing your domain and your p=reject is catching it.