# 550 5.7.509 "does not pass DMARC verification": how to fix it This bounce comes from Microsoft's mail servers, usually for mail sent to Outlook.com, Hotmail, Live.com or MSN addresses: ``` 550 5.7.509 Access denied, sending domain [example.com] does not pass DMARC verification and has a DMARC policy of reject. ``` Two things are true at once: the message failed DMARC for the domain in its **From** address, and that domain publishes `p=reject`, which asks receivers to refuse failing mail. Microsoft did what the domain asked. ## Is it your mail, or someone spoofing you? The bounce goes to the return address of the failed message. If you get 5.7.509 bounces for mail you never sent, someone sent mail pretending to be you, Microsoft refused it, and your `p=reject` policy worked. You don't need to fix anything. See [someone is pretending to be my company](/guides/someone-is-pretending-to-be-my-company) if it keeps happening. If the bounce is for a message you or a system of yours really sent, your own mail is failing DMARC. The rest of this guide is for that case. ## How it differs from 5.7.515 and 5.7.26 - **5.7.509** applies to any domain with `p=reject`, at any volume. Microsoft has rejected these at its consumer service since 2023. - **[5.7.515](/guides/550-5-7-515)** is Microsoft's high-volume sender rule: domains sending more than 5,000 messages a day must pass SPF, DKIM and DMARC, even with `p=none`. - **[5.7.26](/guides/550-5-7-26)** is Gmail's code for unauthenticated mail. Microsoft 365 business mailboxes let each organisation choose whether to reject or quarantine mail that fails DMARC with `p=reject`. Some report the same rejection as `550 5.7.1` instead. ## Why legitimate mail fails DMARC DMARC passes when SPF or DKIM passes **for the From domain** (or a subdomain of it). Microsoft lists these causes: - **A third-party service** (newsletter, CRM, helpdesk, billing) sends as your domain but uses its own domain for the return path and its own DKIM signature. SPF and DKIM pass, but for the wrong domain. - **No DKIM signature**, or a DKIM key that isn't published in your DNS. - **SPF problems**: the sending server isn't in your record, or the record breaks the [10-lookup limit](/guides/spf-too-many-dns-lookups). - **Forwarding and mailing lists**: the message passed when you sent it, but a forwarder changed it or resent it from a server SPF doesn't know. ## Step 1: read the bounce Microsoft attaches the original message's headers to the bounce. Find the `Authentication-Results` line: ``` Authentication-Results: spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=bounces.mailer.example; dkim=pass header.d=mailer.example; dmarc=fail action=oreject header.from=example.com ``` Here both checks passed, but for `mailer.example`, not `example.com`: a third-party sender that isn't aligned. If `spf=` or `dkim=` say `fail` or `none`, the record or signature itself is the problem. Your DMARC aggregate reports show the same thing for every source sending as your domain, which is the quickest way to find all of them. ## Step 2: fix it ### A third-party service Set the service up properly rather than removing it from your policy: 1. Turn on DKIM signing **with your domain** in the service and publish the records it gives you. See [set up DKIM](/guides/dkim-setup). 2. If it offers a custom return path ("custom MAIL FROM" or "bounce domain"), set it to a subdomain of yours and add the record it asks for. 3. Add it to your SPF record only if it sends from your return path domain. Aligned DKIM alone is enough to pass DMARC. ### Your own mail system Make sure Microsoft 365 or Google Workspace is signing with your domain's DKIM key, not the default `onmicrosoft.com` or Google one, and that SPF lists it. ### Forwarded mail You can't fix someone else's forwarder from your DNS. DKIM survives most forwarding where SPF doesn't, so make sure every message is DKIM signed. Receivers that support ARC can then trust the forwarder's results. ### While you fix it If important mail is bouncing and the fix will take time, you can lower the policy to `p=quarantine` for a short while. Mail that fails then goes to Junk instead of bouncing. Note that Microsoft's consumer service treats `p=quarantine` failures strictly too. Move back to `p=reject` once the reports are clean: [DMARC from none to reject](/guides/dmarc-none-to-reject). ## Check your domain The [DMARC checker](/tools/dmarc-checker) shows your policy and records. The [free scan](/#scan) checks SPF, DMARC and the lookalike domains that could send email as you. ## Sources - [Microsoft: Non-delivery reports in Exchange Online (5.7.509, why DMARC fails)](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/non-delivery-reports-in-exchange-online) - [Microsoft: Announcing new DMARC policy handling defaults (July 2023)](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/announcing-new-dmarc-policy-handling-defaults-for-enhanced-email-security/3878883) - [Microsoft: Set up DMARC to validate the From address domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) - [Microsoft: Anti-phishing policies (honor DMARC policy)](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989) --- Source: https://nameward.app/guides/550-5-7-509 (updated 2026-10-31)