Why does Microsoft bounce email with 550 5.7.509?

Microsoft refused the message because it failed DMARC, and the domain in its From address has a DMARC policy of p=reject. The policy is the domain owner's own request, and Microsoft followed it. The owner of that domain fixes it. Either a service that sends as the domain is not set up for it, or the mail went out through a server that cannot pass DMARC for it.

The bounce

Microsoft's list of Exchange Online bounce codes lists this text under the code 5.7.509. In your bounce it follows 550 5.7.509:

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

As the possible cause, Microsoft writes: "The sender's domain in the 5322.From address doesn't pass DMARC." The 5322.From address is the From address people see. Microsoft adds that a person "receives this bounce message because it failed DMARC, and the DMARC policy is set to reject all failures. The user should contact their email administrator for more help."

The same failure can come back with another code. Microsoft's DMARC guide says that Microsoft 365 handles failing mail from a domain with p=reject as "Rejected during SMTP (550 5.7.1)", when the receiving organization has its "Honor DMARC record policy" setting on. Each organization chooses that setting, so the same message can be refused by one company and delivered to another.

What Microsoft checked

Two things. First, DMARC: did SPF or DKIM pass for the domain in the From address? A check that passed for another domain, such as a sending service's own, does not count, because it is not aligned. Second, the domain's policy. p=reject asks mailbox providers to refuse failing mail, and Microsoft did.

Under "Why does DMARC fail?", Microsoft's list of bounce codes names three causes. The first is the DNS records: "Alignment issues, missing SPF, and policy issues". The second is DKIM: a missing key in DNS, or a message that was not signed. The third is forwarding: "Message forwarding that breaks SPF or DKIM".

Who has to fix it

Look at the domain in the brackets of the bounce.

• It is your domain. Your DMARC record asks for reject, and mail you need fails. Find the service that sent it and set it up for your domain: custom DKIM, or its include in your SPF record together with a bounce address of yours. Until then, every mailbox provider that follows your policy refuses its mail. If you cannot fix the service quickly, you can step the policy back. p=quarantine sends its failing mail to spam folders instead, and p=none delivers it. Both do the same for mail forged in your name.
• It is someone else's domain. The mail went out with that domain in the From address through a server that cannot pass DMARC for it. A website form that puts the visitor's address in From does this, and so does a scanner or an app set to send as someone else. Send from your own domain and put the other address in Reply-To. If the domain belongs to a company that wrote to you, its own administrator has to fix its setup.
• The recipient's company wants your mail anyway. On Microsoft 365, its administrator can let one sender's failing mail through, for example with an allow entry. Microsoft's DMARC guide warns: "Be careful when overriding p=reject for legitimate senders." That helps at that one company only, so fix the sending side as well.
• The mail was forwarded. A forwarding rule or an alias breaks SPF, and a mailing list that changes the message breaks DKIM too. Forwarded and mailing-list mail fails DMARC explains what the sender and the forwarder can each do.

The records

This is the record behind the bounce, for example.com:

_dmarc.example.com  TXT  v=DMARC1; p=reject; rua=mailto:k3x9p2m7q4w8@rep.mailmoni.com

Keep it, and fix the service instead. The fix is usually the DKIM key the service gives you, under the selector it names:

s1._domainkey.example.com  CNAME  s1.dkim.newsletter.example

Set up DKIM for a sending service has the steps. If you stepped the policy back while you fixed it, Move to a stricter DMARC policy takes you back up.

What it looks like in your DMARC reports

In the aggregate reports for your domain, refused mail from the service shows up as a row like this:

<row>
  <source_ip>192.0.2.10</source_ip>
  <count>40</count>
  <policy_evaluated>
    <disposition>reject</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <dkim>
    <domain>newsletter.example</domain>
    <selector>s1</selector>
    <result>pass</result>
  </dkim>
  <spf>
    <domain>bounces.newsletter.example</domain>
    <result>pass</result>
  </spf>
</auth_results>

RFC 9990 defines reject as "Failed DMARC, marked as reject". The dkim and spf under policy_evaluated are the alignment results for your domain, and both fail. Under auth_results, both pass, but for the service's own domains. Microsoft's DMARC guide calls pass with alignment fail the "classic alignment problem".

In Mailmoni, the source's page lists its recent records with what the mailbox provider did with each, and when we recognise the service, its explanation names the service's domains and the setting to turn on.