Skip to content
inboxprobe

Checkers

Generators

Guides

Bounce error codes · Microsoft 365 (Exchange Online)

550 5.7.509: does not pass DMARC verification

A Microsoft 365 mailbox refused the message because it failed DMARC for the From domain, and that domain's own DMARC policy says to reject failures.

The exact error text

  • 550 5.7.509 Access denied, sending domain [$SenderDomain] does not pass DMARC verification and has a DMARC policy of reject.

Quoted from Microsoft Learn — Email non-delivery reports in Exchange Online

Check your domain

Find out which record is missing or failing. The check runs in your browser and takes a few seconds.

What 5.7.509 means

This bounce comes from Exchange Online, the mail service behind Microsoft 365 business mailboxes. Unlike Outlook.com's 5.7.515, it isn't a Microsoft rule: the receiving server is doing what your DMARC record asks. You published p=reject, the message failed DMARC, so it was refused.

That's DMARC working as designed when someone spoofs your domain. When the bounce reaches you for a message you really sent, one of your own systems isn't authenticated.

Why DMARC failed

Microsoft lists three groups of causes:

  • Missing or incorrect records: an alignment problem, SPF missing for the sending source, or a policy problem.
  • Missing DKIM: no DKIM public key in DNS, or the message wasn't signed when it was sent.
  • Forwarding: a forward or mailing list changed the message or the sending server, so SPF or DKIM broke on the way.

In practice the first two usually mean a tool someone added later, such as a CRM, a helpdesk or a billing system, that sends with your address in From but signs with its own domain.

Fix it step by step

  1. Read the bounce. Microsoft includes the original message's headers in the non-delivery report. Look for Authentication-Results with spf=, dkim=, dmarc=fail action=oreject and header.from=, or paste them into the header analyzer.
  2. Find the source. The smtp.mailfrom domain and the header.d DKIM domain show which system sent the message. If you collect DMARC aggregate reports, they list every source with its pass/fail counts.
  3. Authenticate that source. Turn on custom-domain DKIM in the sending service and add its SPF include if it uses your domain as envelope sender. The check above shows your current SPF, DKIM and DMARC.
  4. Decide on the policy while you fix it. If many legitimate messages are failing, a temporary p=quarantine or p=none stops the rejections. You lose spoofing protection while it's lowered, so go back to p=reject as soon as reports are clean.

Temporary step back from reject, with reports

Type
TXT
Host / name
_dmarc
Value
v=DMARC1; p=quarantine; rua=mailto:[email protected]

Forwarded mail and mailing lists are the hard case: you can't fix someone else's forwarding. DKIM survives plain forwarding better than SPF, and Microsoft recommends ARC for forwarders and mailing lists.

Questions

I'm not the email admin. What should I do?

Microsoft's advice for users who get this bounce is to contact their email administrator. The fix is in the domain's DNS or the sending service's settings, not in your mail app.

Is 5.7.509 the same as 5.7.515?

No. 5.7.515 is Outlook.com enforcing its own high-volume sender requirements. 5.7.509 is a Microsoft 365 recipient applying the p=reject policy that the sending domain published.

Should I remove p=reject to make the bounces stop?

Only as a short-term measure. Lowering the policy also lets spoofed mail through. Fix the failing sender, confirm in DMARC reports that legitimate mail passes, then restore reject.

Someone else is getting 5.7.509 bounces for my domain. Why?

If you didn't send those messages, someone spoofed your domain and DMARC stopped it. That's the point of p=reject. You may see these in DMARC reports, not as bounces in your own inbox.

Sources

Last reviewed: