550 5.7.509: Sending Domain Does Not Pass DMARC (Microsoft)

550 5.7.509 means a Microsoft 365 mail system refused your message because the domain in your From address failed DMARC, and that domain's DMARC record says p=reject. Microsoft is doing exactly what the domain owner asked: reject anything that fails. The fix is to make that message pass DMARC, which means getting SPF or DKIM to pass on a domain that matches your From domain.

Microsoft documents the bounce as:

550 5.7.509 Access denied, sending domain example.com does not pass
DMARC verification and has a DMARC policy of reject.

What it means

DMARC (Domain-based Message Authentication, Reporting and Conformance) checks whether a message that claims to be from example.com really came from someone example.com authorized. It passes when either SPF or DKIM passes and the domain that passed is aligned with (matches) the visible From domain. If neither does, DMARC fails, and the receiver looks at the domain's policy: p=none (do nothing), p=quarantine (send to junk) or p=reject (refuse it).

Microsoft 365 honors that policy by default. In Defender's anti-phishing policies, "Honor DMARC record policy when the message is detected as spoof" is on in the default, Standard and Strict presets, and the default action for p=reject is to reject the message. 5.7.509 is that rejection.

It's about the From domain people see (the 5322.From), not the envelope sender. And it's per message: no reputation score, no blocklist, no delisting. Pass DMARC and the message gets through.

One wrinkle: Microsoft's own DMARC documentation describes p=reject failures as rejected during SMTP with 550 5.7.1, while its NDR reference lists 5.7.509. You may see either. If the bounce text mentions DMARC and reject, the diagnosis is the same. For the broader family of DMARC rejections at every provider, see email rejected per DMARC policy.

Common causes

Most likely first:

1. A sending service that isn't authenticated as your domain. You moved to p=reject, your main platform is set up correctly, but a CRM, ticketing system, invoicing tool or survey platform sends as you@example.com without custom DKIM or an aligned Return-Path. That one stream fails DMARC and bounces.
2. DKIM signed with the vendor's domain. Many platforms sign with their own domain (d=vendor-mail.example) until you configure custom DKIM. The signature passes, but it isn't aligned, so it doesn't count for DMARC.
3. SPF passes on the wrong domain. SPF is checked against the Return-Path domain. If that's the ESP's bounce domain, SPF passes but isn't aligned with your From domain.
4. Forwarding or a mailing list. A message passes DMARC on the way to the first server, then gets forwarded. The forwarder's IP isn't in your SPF record, and if the message was modified (a footer, a subject tag), DKIM breaks too. Microsoft lists forwarding as one of the main reasons DMARC fails.
5. A broken DNS record. A DKIM key that was rotated or deleted, or an SPF record over the 10-lookup limit, which returns a permanent error. See SPF's 10-lookup limit.
6. Someone spoofing your domain. If you never sent the bounced message, DMARC is working as intended.

How to fix it

1. Work out which message bounced and who sent it. Check the From address and the sending platform in the bounced message. Microsoft includes the original headers in the NDR, which saves a step.
2. Read the Authentication-Results header. Look for spf=, dkim= and dmarc= and the domains next to each. dmarc=fail action=oreject confirms this is a DMARC reject. If the header is hard to read, paste it into the header analyzer or follow how to read an email header.
3. Set up custom DKIM on the sending platform. Publish the CNAME or TXT records it gives you, and confirm the signature's d= is your domain (or a subdomain of it, under relaxed alignment). Aligned DKIM is the most reliable fix because it survives forwarding when the message isn't modified.
4. Align SPF where you can. Set a custom Return-Path (bounce domain) on your own domain and add the platform to that domain's SPF record. Check the lookup count with the SPF analyzer.
5. If a service can't authenticate as you, change the From address. Send it from a subdomain you've set up for that platform, or from the vendor's own domain. Don't leave it failing under a reject policy.
6. If forwarding is the cause, the fix sits with the recipient side. You can't add every forwarder to SPF. Aligned DKIM is your best defense. Microsoft 365 admins on the receiving end can mark a legitimate intermediary as a trusted ARC sealer.
7. Only as a last resort, step the policy back. Moving from p=reject to p=quarantine or p=none stops the bounces while you find the remaining sources, but it also removes your spoofing protection. Do it deliberately and come back. DMARC policy: none vs quarantine vs reject covers how to stage this.

If you're on the other side (a partner's mail to your Microsoft 365 users is bouncing with 5.7.509), the fix belongs to the partner. Send them the bounce. Overriding a sender's reject policy with an allow entry is possible but Microsoft warns against it, and it lets spoofed mail from that domain in too.

How to confirm it's fixed

Send a test from the fixed system to a Microsoft 365 mailbox you control and check the headers for dmarc=pass, plus dkim=pass with header.d matching your From domain (or spf=pass with an aligned smtp.mailfrom). Then watch your DMARC aggregate reports for a few days: the source that was failing should move to passing. The email checker confirms the DNS side.

How to keep it from coming back

• Before you move to p=reject, run at p=none long enough that your aggregate reports show every legitimate source passing.
• Make "new tool sends email as us" a change that requires DKIM and Return-Path setup before the first send.
• Keep reading your DMARC reports after you reach enforcement. A new failing source shows up there before it shows up as a pile of bounces.

For the full list of failure modes, DMARC fail: why it fails and how to fix it goes case by case.

When to get help

If your reports show a dozen sources and you can't tell which ones are yours, or everything passes in testing and Microsoft 365 recipients still bounce you, it's worth having someone go through your DMARC data with you.

FAQ

Is 5.7.509 a blocklist?

No. It's a per-message authentication check. There's nothing to delist from; fix the authentication and the next message is accepted.

Why does Gmail accept the same message?

It may not be the same path. Forwarding, a different sending server, or a recipient-side setting can change the outcome. If Gmail shows dmarc=fail too, it's likely sending it to spam or rejecting it as well, just with a different code, like 550 5.7.26.

The bounce is for a message I never sent. Should I worry?

Usually not. Someone sent mail using your domain, it failed DMARC, and Microsoft rejected it because of your p=reject policy. That's the protection working. Check your DMARC reports to confirm your own mail passes.