5.7.509: DMARC failed and the domain’s policy is reject (Microsoft 365)

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code: varies; the enhanced code is the part that identifies the problem.
• Enhanced code 5.7.509: not in the IANA registry; the group is security or policy status (RFC 3463 §3.8).
• Who uses it: Microsoft (Exchange Online): sending domain does not pass DMARC verification and has a DMARC policy of reject.

A 5.7.509 bounce from Microsoft means your message failed DMARC, and your own domain's DMARC policy is p=reject. Microsoft did what your policy asked and refused it.

What it means

This is Microsoft's code, not one from the IANA registry. Microsoft's Exchange Online NDR reference describes it as a sending domain that does not pass DMARC verification and has a DMARC policy of reject.

DMARC passes when SPF or DKIM passes for a domain that matches the From: address. The policy in your DMARC record tells receivers what to do when neither does. With p=reject, you have asked them to refuse such mail. That is the right policy for a domain with every source set up, but any service you forgot to set up now bounces.

The general SMTP code for failed authentication is 5.7.26 (RFC 7372 §3.4); Gmail uses that code for DMARC rejections too.

Common causes

• A new sending service (a newsletter tool, an invoicing system, a help desk) sends as your domain without DKIM signing for your domain.
• The service signs with its own domain and uses its own bounce domain, so SPF and DKIM pass, but neither matches your From: domain (see 5.7.32).
• A DKIM key was rotated or removed from DNS.
• Mail was forwarded and changed on the way, breaking DKIM, while SPF failed at the new hop (see 5.7.367).
• Someone is spoofing your domain. Then the bounce is your policy working.

How to fix it

1. Check the bounce for the server and service that sent the message.
2. Look up your record with the DMARC checker, and confirm the policy and the address for aggregate reports.
3. Use those reports to list every source that sends as your domain, and which of them fail.
4. For each legitimate source, set up DKIM signing with your own domain (DKIM checker), and add it to SPF with a matching bounce domain where it supports one (SPF checker).
5. If many sources fail and you cannot fix them quickly, lowering the policy to quarantine or none stops the bounces for now. It also removes the protection, so treat it as a pause, not a fix.
6. Resend once the source passes.

What to do with the address

Keep it. The recipient is fine; your domain's authentication needs fixing.

Related codes

• 550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it
• 550 5.7.23: SPF validation failed
• 5.7.32: From: domain not aligned with SPF or DKIM (Gmail)

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.