Outlook · bounce code

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

Your own DMARC record tells receivers to reject mail that fails DMARC, and Microsoft did exactly that. Either a service you use sends as your domain without aligned authentication, or someone else is sending as your domain.

Check your domain — free

What the bounce says

The rejection as reported in Outlook bounces (the domain in brackets is yours):

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

Microsoft documents the same decision in the message header as dmarc=fail action=oreject: the sender's domain published p=reject and the message failed DMARC.

When a message fails DMARC

• SPF alignment: SPF passes and the envelope sender domain (smtp.mailfrom) matches your From domain.
• DKIM alignment: a DKIM signature verifies and its signing domain (d=) matches your From domain.
• One aligned pass is enough. The message fails DMARC only if both fail; with p=reject it is then refused.

First: is it your mail at all?

If the bounce belongs to a message you never sent, someone used your domain and your DMARC policy blocked it. That is the policy working; there is nothing to fix. If it belongs to real mail from you, a tool or mailbox, follow the steps below.

Find the service that breaks alignment

1. Read the header of a rejected or test message. In Authentication-Results, compare smtp.mailfrom= and header.d= with header.from=. A typical failure: SPF and DKIM pass, but for the service's own domain, not yours.
2. Fix it at the service, not in Outlook. Set up the service's domain authentication so it signs DKIM with your domain (d=yourdomain), or let it use a bounce address on your domain so SPF aligns.
3. Forwarding and mailing lists change the envelope sender, so SPF alignment breaks on the way; DKIM survives if the body is not modified. Signing with your domain matters most here.
4. Use your DMARC reports. With a rua= address in the record, receivers send daily summaries by sending IP. A known service with SPF pass but alignment fail is the classic case.

Should you lower the policy?

Microsoft's guidance is a gradual rollout: p=none, then p=quarantine, then p=reject, watching the reports at each step. Stepping back to p=quarantine or p=none while you fix a sender stops the rejections, but it also lets spoofed mail through again. Fix the sender first if you can.

What a fix cannot promise

Passing authentication is a requirement, not a guarantee: content, list quality and sender reputation also decide where mail lands. We do not promise inbox placement.

Sources

• Microsoft Learn, Set up DMARC to validate email in Microsoft 365 (updated 17.07.2026) (checked 31.10.2026)
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) (checked 31.10.2026)

Fix & Verify: we work out the exact records for every service that sends as your domain, you publish them, we re-check independently.