A 550 5.7.509 bounce means a Microsoft 365 or Outlook.com mail server refused your email because it failed DMARC, and your domain's own DMARC record tells receivers to reject email that fails. Neither SPF nor DKIM passed for your domain on that email, so Microsoft did exactly what your record asked.
DMARC is a DNS record that tells receivers what to do with email that claims to be from your domain but fails its checks. Your record says p=reject, the strictest setting. That protects you from people sending email pretending to be you, but it also bounces your own genuine email if a service that sends for you isn't set up properly.
What the bounce says
Microsoft gives the error as:
550 5.7.509 Access denied, sending domain yourbusiness.com.au does not pass DMARC verification and has a DMARC policy of reject.
Some bounces show a colon after 5.7.509. Microsoft explains it as: the sender's domain in the 5322.From address doesn't pass DMARC. The 5322.From address is simply the From address your recipient sees. A 550 code is a permanent rejection, so the email wasn't delivered and won't be retried.
Microsoft includes the headers of your original email in the bounce. Look for the line that starts with Authentication-Results. It looks something like this:
spf=fail smtp.mailfrom=yourbusiness.com.au; dkim=none (message not signed) header.d=none; dmarc=fail action=oreject header.from=yourbusiness.com.au
- spf= is the SPF result, and smtp.mailfrom= is the domain SPF checked.
- dkim= is the DKIM result, and header.d= is the domain that signed the email.
- action=oreject means your p=reject policy was applied.
For DMARC to pass, SPF or DKIM must pass for yourbusiness.com.au itself (or one of its subdomains). Passing for a service's own domain doesn't count.
Who sends this bounce
Two Microsoft services use this code:
- Microsoft 365 business mailboxes. Since July 2023, Microsoft 365 honours the sender's DMARC policy by default. Its anti-phishing setting Honor DMARC record policy when the message is detected as spoof rejects email that fails when the policy is p=reject. Each organisation can change that setting.
- Outlook.com, Hotmail and Live addresses. Microsoft has said its consumer service rejects email that fails DMARC when the policy is p=reject or p=quarantine.
So the bounce is about your domain's setup, not the recipient's.
Why your email failed DMARC
These are the usual causes:
- A service sending as you that isn't set up. A website contact form, newsletter tool, booking system, CRM, or a scanner that emails documents. It uses your address in the From line, but isn't in your SPF record and doesn't sign with DKIM for your domain.
- Microsoft 365 itself isn't fully set up. Your SPF record is missing include:spf.protection.outlook.com, or is broken (two SPF records, or more than 10 lookups), and DKIM isn't switched on for your domain. Without DKIM, Microsoft signs with your onmicrosoft.com domain, which doesn't count for DMARC.
- Something changed the email after it was signed. An email signature or disclaimer tool, or a filtering service, that edits the email after Microsoft 365 signs it breaks the DKIM signature.
- The email was forwarded. Forwarding breaks SPF. DKIM usually survives if nothing changes the email, which is why DKIM matters so much under p=reject.
Xero and MYOB invoices don't cause this bounce when Xero or MYOB send them from their own addresses, because your DMARC record doesn't apply to their domains.
How to fix it
1. Find which service sent the email
Was it your Microsoft 365 mailbox, a newsletter, your website or another tool? The Authentication-Results line helps. The domain after smtp.mailfrom= and header.d= often names the service.
2. If it was Microsoft 365
Check your SPF record includes Microsoft 365:
| Type | Name | Value |
|---|---|---|
| TXT | yourbusiness.com.au | v=spf1 include:spf.protection.outlook.com ~all |
If you already have an SPF record, add the include to it rather than creating a second one.
Then switch on DKIM. In the Microsoft Defender portal go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select yourbusiness.com.au and choose "Create DKIM keys" if it asks. Add the two CNAME records it shows (selector1 and selector2), copying each value exactly, then switch on "Sign messages for this domain with DKIM signatures".
3. If it was another service
Turn on DKIM signing for yourbusiness.com.au in that service, and add the DKIM record it gives you to your DNS. Most services call this "domain authentication". If the service offers a custom bounce or return-path domain, set that up too, so SPF also passes for your own domain.
If something is changing your email after it's sent, such as a signature tool, ask its provider how to keep DKIM intact.
4. If you need email flowing today
Change your DMARC record to monitoring mode while you fix the cause:
| Type | Name | Value |
|---|---|---|
| TXT | _dmarc.yourbusiness.com.au | v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com.au |
Changing to p=quarantine isn't enough here. Microsoft has said Outlook.com rejects failing email at quarantine too, and Microsoft 365 recipients get it in their Junk Email folder. Remember that p=none also stops protecting your domain, so move back to quarantine and then reject once your reports show all your genuine email passing.
5. Test, then resend
Send one email from the service that bounced to your private test address. We check SPF, DKIM, DMARC and alignment, and show a verdict for Outlook.com, Microsoft 365, Gmail, Google Workspace and Yahoo. If anything still fails, the report shows the exact record to change. When DMARC passes, resend the email that bounced.
Checked against: Microsoft Learn, Email non-delivery reports (NDRs) and SMTP errors in Exchange Online · Microsoft Exchange Team Blog, Announcing New DMARC Policy Handling Defaults for Enhanced Email Security · Microsoft Learn, Anti-phishing policies in Microsoft 365 (Spoof protection and sender DMARC policies) · Microsoft Learn, Set up DMARC to validate email in Microsoft 365.