550 5.7.509 — Sending domain does not pass DMARC verification (Microsoft)
Retrying will not help. The message will not be delivered.
The reply
550 5.7.509 Access denied, sending domain <domain> does not pass DMARC verification.Microsoft could not authenticate the message against the From: domain's DMARC policy, and that policy says to reject. Your own DNS asked for this, which means you can also call it off — by fixing the authentication, not the policy.
What it means
DMARC passes when SPF or DKIM passes *and* the domain that passed matches the one in the visible From:. Both halves matter, and alignment is where this usually fails: an SPF pass for your ESP's bounce domain is a genuine pass that DMARC does not count. Microsoft enforces the policy it finds published, so a p=reject with broken alignment is a self-inflicted block.
Why it happens
- SPF passes for the envelope sender but the visible From: is a different domain.
- No DKIM signature, or one whose d= domain does not align with the From:.
- A sending service that was never added to the SPF record.
- An SPF record exceeding ten DNS lookups, which returns permerror and fails everywhere.
- Forwarding that broke both SPF and the DKIM signature, with no ARC chain to preserve the original result.
What to do
- Sign with DKIM where d= is the From: domain — the fix that also survives forwarding.
- Align the envelope sender with the From: domain so SPF counts for DMARC as well.
- Count the DNS lookups in your SPF record and stay under ten.
- Read your DMARC aggregate reports to find which source is failing; it is usually a service you forgot sends as you.
- Test with a message to a mailbox you control and read Authentication-Results on the delivered copy.
Questions
Gmail accepts the same message.
Receivers differ in how strictly they enforce a published policy, and some weigh their own reputation signals alongside it. A pass at one receiver does not mean the alignment is correct — check the headers rather than inferring it from delivery.
Should I relax my DMARC policy?
No. The policy is doing what you asked. Withdrawing it leaves your domain forgeable and does not fix the authentication that is actually broken.