sfw/fix
550 5.7.509 critical

550 5.7.509 Access Denied, Sending Domain Does Not Pass DMARC (Exchange Online)

Exchange Online rejected the message because the sending domain failed DMARC and publishes a p=reject policy.

What you see

550 5.7.509 Access denied, sending domain does not pass DMARC
verification and has a DMARC policy of reject.

What’s actually happening

Mail to Outlook.com, Hotmail, and Microsoft 365 tenants bounces with 550 5.7.509 while other providers may still accept it. The problem is on the sending side, not the recipient's. DMARC needs SPF or DKIM to both pass and align with the From domain; here neither does, and the domain's own DNS tells Microsoft to reject on failure. Microsoft now enforces p=reject as a hard rejection rather than routing to junk.

Common causes

  • A third-party sender (CRM, invoicing platform, newsletter tool) sends as your From domain but is not listed in your SPF and does not DKIM-sign with your domain.
  • DKIM is signing with the vendor's own d= domain, so it passes DKIM but fails alignment against your From address.
  • SPF passes for the envelope (Return-Path) but the visible From is a different domain, so SPF alignment fails.
  • The domain publishes p=reject (often after a rushed DMARC rollout) before every legitimate source was authenticated and aligned.
  • A forwarding hop broke the SPF chain and there is no surviving DKIM signature to carry alignment.

How to fix it

  1. Read the failing message's Authentication-ResultsGet a copy of a rejected message's headers. Look at dmarc=, spf=, and dkim= and which domains aligned. That tells you whether SPF, DKIM, or both fell over, so you fix the right one instead of guessing.
  2. Authenticate the actual sending sourceFor each legitimate sender, add it to SPF (or set up the vendor's custom Return-Path) and enable DKIM signing with your domain so the d= matches your From. Get at least one of SPF or DKIM passing and aligned.
  3. Confirm alignment, not just passDMARC needs the passing mechanism's domain to match the From domain (relaxed alignment allows a subdomain). A green SPF/DKIM check still fails DMARC if the domains do not line up.
  4. Loosen the policy only while you fix the sourceIf business-critical mail is bouncing, you can drop to p=quarantine or p=none briefly to stop hard rejections, then return to p=reject once the source authenticates. Do not leave it at p=none permanently.
  5. Use DMARC aggregate reports to find every sourceAdd an rua= address and read the XML (or feed it to a reporting tool). It lists every IP sending as your domain and whether each aligns, so no legitimate sender gets missed before you enforce.

Stop it recurring

Stand up DMARC at p=none with aggregate reporting first, authenticate and align every sending source from those reports, and only then move to p=reject.

Related errors