Bounce and error codes

550 5.7.509 Access denied, sending domain does not pass DMARC verification

Last updated 2026-08-26

This bounce is your own policy doing exactly what you asked. Microsoft checked the message, DMARC failed, your record says p=reject, so Microsoft rejected it. The interesting question is whether the message was yours.

The exact bounce

First, decide which of the two situations you are in

Everything after this depends on the answer, so do not skip it.

• You sent it. A system you own or pay for is sending as your domain without aligned authentication. The classic is the invoicing app nobody remembered was still running, set up years before anyone published a DMARC record.
• You did not send it. Someone is putting your domain in the From header and Microsoft is refusing to deliver it. There is nothing to fix. The bounce is arriving in your inbox because the spoofer forged your address as the envelope sender too, which is common and annoying.

The bounce itself usually carries enough of the original message to tell them apart: look for the Subject: and the sending IP in the attached headers. Beyond that, your aggregate reports already carry the answer: reading one by hand shows every source, aligned or not.

Causes when the mail is yours

1. A SaaS tool sending as your domain with no domain authentication. Ticketing, invoicing, HR, surveys, monitoring. It signs with the vendor's key and uses the vendor's return-path, so both checks pass for them and neither aligns for you.
2. Forwarding. A recipient auto-forwards to Outlook. SPF breaks at the forwarding hop because the connecting IP is now theirs. If DKIM survives you are fine, which is the practical argument for making sure DKIM works everywhere.
3. A mailing list. Lists that add a footer break the DKIM body hash, and lists that do not rewrite the From header then fail DMARC. Body hash did not verify covers this.
4. A subdomain you forgot. Your policy applies to subdomains unless sp= says otherwise, and a marketing subdomain set up before the policy went to reject is a common casualty.

Diagnose

Confirm the policy you think you published, including sp=. Then run the domain through the DMARC checker for a read of every tag in the record.

Get the message headers if you can. In the raw source of any delivered copy, Authentication-Results: tells you which check failed and why. Microsoft adds its own compauth= verdict, which is composite authentication and can fail even when SPF passes. What you are looking for is whether header.from matches the domain SPF or DKIM authenticated.

Fix

For a SaaS sender, the vendor's setup page will have a domain authentication or custom sending domain step. Complete it. Adding the vendor to your SPF record alone frequently does not help, because a vendor that uses its own return-path never consults your SPF at all. Check the provider pages for the specific one.

For forwarding and lists, DKIM is the answer. If your mail is DKIM-signed with your own domain and the intermediary does not modify the body, alignment survives an arbitrary number of hops.

As a stopgap while you fix a real sender you cannot fix today, you can move to p=quarantine so the mail goes to spam rather than vanishing. That is a decision with a cost, so read the policy ramp before you make it, and put a date on going back.

You fixed this sender. Tomorrow the reports name the other hosts still sending as you, and we turn a day of XML into one email with a verdict per sender. On the paid plans, the day a report first names a new sender failing, you hear about it. Get the weekly digest. The first domain is free.