Microsoft 365 / Outlook
Microsoft 365 550 5.7.509 — sending domain does not pass DMARC
550 5.7.509
The full text reads "Access denied, sending domain [your domain] does not pass DMARC verification and has a DMARC policy of reject." Microsoft 365 checked the domain in the visible From address, found that neither SPF nor DKIM passed in alignment with it, and applied the policy your own DMARC record asks for: reject. So the rejection is your DMARC policy working as written. Either the message really was spoofed, or one of your legitimate senders isn't authenticated with your domain yet.
How to fix it
- 1
Identify which service sent the bounced message
Check the bounced message's headers for the sending IP and the Return-Path domain. The usual culprits are a newer tool sending as your domain (a CRM, help desk, invoicing or marketing platform) that was never set up with your domain's DKIM, or a server sending directly with an IP that isn't in SPF.
- 2
Make DKIM sign with your domain
DKIM is the reliable way to pass DMARC because it survives forwarding. In the sending platform, turn on custom-domain DKIM and publish the records it gives you, so the signature's d= domain is your domain (or a subdomain of it). Verify with the DKIM checker.
- 3
Or make SPF align
SPF only counts for DMARC when the Return-Path (envelope sender) domain matches your From domain. Many platforms use their own bounce domain by default; set up a custom return path or bounce domain on your domain, then confirm the platform's include is in your SPF record and you're under 10 DNS lookups.
- 4
Use DMARC reports to find every failing source
Aggregate reports list each IP sending as your domain with its SPF, DKIM and alignment results. Fix every legitimate source that fails before relying on p=reject. If many legitimate sources fail and the business can't wait, moving temporarily to p=quarantine reduces outright bounces while you fix them, but treat that as a stopgap.
- 5
If you received this as an outside sender's bounce
If the bounce is for a message you didn't send, someone spoofed your domain and Microsoft blocked it. That's the protection doing its job; nothing needs fixing.
Meaning current as of 2026-10-24, cross-checked against the provider's own documentation. Providers do occasionally redefine codes — if this doesn't match what you're seeing, the source link is the authoritative reference.