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
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 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 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.
- 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:
- Turn on DKIM signing with your domain in the service and publish the records it gives you. See set up DKIM.
- 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.
- 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.
Check your domain
The DMARC checker shows your policy and records. The free scan checks SPF, DMARC and the lookalike domains that could send email as you.