550 5.7.509: Microsoft Says Your Domain Failed DMARC

A 550 5.7.509 bounce means Microsoft refused your email because it failed your own domain’s DMARC check, and your DMARC record tells receivers to reject such emails. It comes back when you email anyone on Outlook.com, Hotmail, Live or a business using Microsoft 365. Microsoft is doing what your domain’s records asked; the fix is on your side.
What the message looks like
550 5.7.509 Access denied, sending domain [YOURBUSINESS.CO.UK]
does not pass DMARC verification and has a DMARC policy of reject.
Microsoft usually puts the domain in capitals, and adds a reference in brackets. The code 5.7.509 is what matters.
What it means
DMARC is a record on your domain that tells receivers what to do with email that claims to be from you but can’t prove it. Proof means passing SPF or DKIM for your own domain (the domain in the From line). Your record says p=reject, so when an email fails, Microsoft refuses it.
That is a good setting when everything that sends as you is set up properly: it stops criminals sending in your name. This bounce means one of your genuine emails wasn’t set up properly.
If you get this bounce for an email you never sent, someone tried to send in your name and DMARC stopped it. You don’t need to do anything, but it’s worth watching your DMARC reports.
Common causes
- A system that sends as you isn’t set up. An invoicing, booking or newsletter tool, a website form or a new email provider sends from your address without being in your SPF record or signing with DKIM for your domain.
- DKIM was never switched on for your own domain in Microsoft 365 or Google Workspace, and SPF doesn’t line up (for example because the email went through another service first).
- Forwarding. Your email reached the recipient through a forwarding address or an old mailbox that passes it on. Forwarding breaks SPF, and if anything changes the email on the way, DKIM too.
- DMARC was set to reject too early, before every sending system was checked in the reports.
How to fix it
- Find what sent the bounced email. Your normal mailbox, a website form, a scanner, an invoicing system? The bounce usually includes the original email; the Received lines in its headers show the server that sent it.
- Set up SPF and DKIM for that system. Add it to your SPF record (one SPF record only, under 10 lookups), and switch on DKIM for your domain in it. Most services have a “domain authentication” page with the records to add.
- If you’re not sure everything is covered, step DMARC back to quarantine or none while you fix it. Change
p=rejecttop=quarantine(orp=none) in your DMARC record. That is a stopgap; put it back once the reports are clean. - For forwarding, ask whoever runs the forwarding to rewrite the sender (SRS), or replace the forward with a proper mailbox.
- Send a test to an Outlook.com or Hotmail address.
My guide to what DMARC reports tell you explains how to find every system sending as you before tightening the policy again.
How to check it worked
Send from the same system to an Outlook.com or Hotmail address and to a personal Gmail address. Both should arrive. In Gmail, under “Show original”, SPF or DKIM should show PASS and DMARC PASS.
When to ask for help
If only one system is failing and it has a domain authentication page, you can usually fix it yourself in half an hour. If you can’t tell what sent the email, or several systems send as you, the DMARC reports hold the answer but take some reading.
Where to go from here
- Why Emails Bounce (and What the Bounce Message Is Telling You).
- 550 5.7.26: Gmail Says the Sender Is Unauthenticated, Gmail’s version of the same problem.
- Domain email forwarded to Gmail or Yahoo?, if forwarding is involved.
- What is SPF, DKIM and DMARC?.
Need help fixing this?
I provide:
- Free initial assessment
- Clear explanation of the issue
- Fixed-price solutions
- UK-based support
Send me the bounce, and I’ll find which system is failing DMARC and set it up so your emails are accepted again.
