550 5.7.509: sending domain does not pass DMARC verification

Microsoft 365 rejected your message because your domain publishes p=reject and the message failed DMARC. Trace the failing sender, fix SPF or DKIM alignment, and stop the bounces without weakening your policy.

Standards basis: Advice based on RFC 9989 for DMARC policy records, RFC 9990 for aggregate reports, and RFC 9991 for failure reports. Historical RFC 7489 behavior is called out where relevant.

Quick answers

What does 550 5.7.509 access denied mean?
A Microsoft 365 recipient rejected your message during the SMTP transaction because the domain in your From address publishes a DMARC policy of p=reject and the message failed DMARC evaluation. Neither SPF nor DKIM produced a result aligned with your From domain, so Microsoft honored your own policy and refused the message.
Can the recipient release the message from quarantine?
No. A 550 5.7.509 rejection happens during the SMTP transaction, before the message reaches a mailbox or a quarantine. There is nothing to release. The recipient can create an override for future messages, but the reliable fix is on the sending side: make SPF or DKIM pass with a domain aligned to the From address.
Why do only Microsoft 365 recipients bounce my mail?
Different receivers act on the same DMARC failure differently. Microsoft 365 rejects with 550 5.7.509 by default when the sender publishes p=reject. Gmail and Yahoo return their own code, 550 5.7.26, and some receivers quarantine instead of rejecting. If Microsoft recipients bounce your mail, the same messages are almost certainly failing DMARC everywhere else too, just less visibly.
Should I change p=reject to p=none to stop the bounces?
Not as a first move. Downgrading the policy reopens your domain to spoofing for every receiver worldwide to solve a delivery problem for one sender. Identify the failing source in your aggregate reports and fix its SPF or DKIM alignment. If a business-critical flow is down, a temporary p=quarantine is a smaller step back than p=none.
How do I find which service triggered the failure?
Read the bounce and the original message headers for the sending IP and the smtp.mailfrom and header.d domains, then compare them against your DMARC aggregate reports. The reports list every IP sending as your domain and whether each source passes aligned SPF or DKIM, so the failing service stands out.

The exact bounce

The sender receives a non-delivery report containing a line like this: 

550 5.7.509: Access denied, sending domain contoso.com does not pass DMARC verification and has a DMARC policy of reject
Remote server returned '550 5.7.509 Access denied, sending domain contoso.com does not pass DMARC verification and has a DMARC policy of reject'

Read it as two statements. First: the message failed DMARC. Second: your own DNS told the receiver to reject failures. Microsoft 365 checked the DMARC record for the domain in the visible From: address, found p=reject, and did exactly what the record asked.

This is different from a spam filter judgment call. The rejection is deterministic: fix the DMARC failure and the same message is accepted.

What it means in plain terms

DMARC passes when at least one of two checks produces a pass and the domain it validated matches your From domain. That match is called alignment:

  • Aligned SPF: the message came from a server your domain's SPF record authorizes, and the envelope sender domain matches your From domain.
  • Aligned DKIM: the message carries a valid DKIM signature whose d= domain matches your From domain.

A 550 5.7.509 bounce means both checks failed for that message. Either the sending service is not set up to authenticate as your domain, or an intermediary broke the authentication in transit, or the message never came from you at all.

Why Microsoft rejects instead of junking

Exchange Online Protection has a setting called Honor DMARC record policy when the message is detected as spoof, enabled by default in every anti-phishing policy. With it on, mail failing DMARC from a p=reject domain is rejected during SMTP by default, and mail from a p=quarantine domain is quarantined. The delivered copy of a failing message, when one exists, shows the verdict in its headers: 

Authentication-Results: spf=fail (sender IP is 203.0.113.10)
  smtp.mailfrom=bounce.espvendor.net; dkim=fail (signature did not verify)
  header.d=espvendor.net; dmarc=fail action=oreject
  header.from=contoso.com; compauth=fail reason=000

action=oreject means the sender's own record asked for rejection. The compauth field is Microsoft's composite authentication verdict; its reason codes are covered in compauth=fail reason codes.

Diagnose it in three steps

  1. Identify the actual sender. From the bounce or your mail logs, note the sending IP and the envelope sender domain (smtp.mailfrom). Was this your mail platform, a marketing tool, a CRM, an invoicing app, or something you do not recognize?
  2. Read the Authentication-Results header from a delivered copy of the same mail flow, for example a copy sent to a mailbox you control. Paste the headers into the email header analyzer. It runs in your browser, the headers are parsed locally and never uploaded. Compare three domains: header.from (your domain), smtp.mailfrom, and header.d. DMARC needs one of the last two to pass its check and match the first.
  3. Check your DMARC record to confirm what policy receivers see: 
    dig TXT _dmarc.contoso.com +short
    A p=reject here plus a failed alignment above fully explains the bounce.

Cause 1: a legitimate service sends without aligned authentication

The most common case. A marketing platform, helpdesk, or billing tool sends mail with your domain in the From address, but uses its own domain for the envelope sender and its own domain in the DKIM signature. SPF and DKIM can both technically pass and DMARC still fails, because neither passing domain is yours.

The fix is in that service's settings, usually under a name like "custom domain authentication", "domain verification", or "dedicated sending domain": add the CNAME or TXT records the service gives you so it signs DKIM with your domain. This exact scenario, including the per-provider steps, is covered in ESP mail fails DMARC despite spf=pass and dkim=pass.

Cause 2: a sender you forgot about

Line-of-business systems send mail too: monitoring boxes, scanners, on-premises applications, an old newsletter script. If such a system sends directly with your From domain and was never added to SPF or given a DKIM key, every message it sends now bounces at Microsoft recipients.

Either route it through your authenticated mail platform, or add its sending IP to SPF and align the envelope sender domain. Your DMARC aggregate reports are the inventory of every source currently sending as your domain, including the ones nobody remembered.

Cause 3: forwarding broke the authentication

If the bounce only appears when mail is forwarded, for example a recipient auto-forwards their mailbox into Microsoft 365, the forwarding hop rewrote the envelope sender (breaking aligned SPF) and possibly modified the body (breaking DKIM). The original message was fine.

On the receiving side, a Microsoft 365 admin can register the forwarder as a trusted ARC sealer so authentication results survive the hop. The mechanics are in email forwarding, mailing lists, and ARC. As the sender, the best defense is a DKIM signature that survives forwarding: it stays valid as long as the forwarder does not modify the signed content.

Cause 4: it was not you

If the rejected message did not come from any system you operate, this bounce is your DMARC policy working. Someone tried to send as your domain and Microsoft refused it on your instructions. No action needed on the sender side. Your aggregate reports show the volume and origin of these attempts.

Resist the p=none reflex

Downgrading p=reject makes the bounce disappear, and also tells every receiver in the world to deliver spoofed mail claiming to be you. You would be trading a targeted, fixable delivery issue for a domain-wide protection loss.

Fix the failing source instead. If a business-critical flow is down and you need breathing room, step back to p=quarantine temporarily rather than p=none, then return to reject once the source aligns. The staged approach is described in the p=none to p=reject migration guide.

If you administer the receiving Microsoft 365 tenant

When legitimate mail from a partner keeps bouncing and the sender cannot fix alignment quickly, Microsoft documents override paths: an allow entry for the spoofed sender in the Tenant Allow/Block List, the sender in users' Safe Senders lists, a mail flow rule scoped to the sender's IP and domain, or a trusted ARC sealer for forwarded mail. Use them narrowly. A broad override re-opens the exact spoofing vector the sender's DMARC policy exists to close, so prefer the sender-side fix whenever one is possible.

Validate the fix

After changing the service's authentication settings or your DNS, send a fresh message to a Microsoft 365 recipient and read its headers. You want either aligned SPF or aligned DKIM: 

Authentication-Results: spf=pass (sender IP is 203.0.113.10)
  smtp.mailfrom=contoso.com; dkim=pass (signature was verified)
  header.d=contoso.com; dmarc=pass action=none
  header.from=contoso.com; compauth=pass reason=100

Then check the whole domain with the DMARC checker to confirm the record, SPF, and DKIM setup are consistent.

Finally, watch your aggregate reports for a few days. The failing source should move from the failing column to passing, and any remaining failures are either senders you have not fixed yet or spoofing attempts. DMARCTrust turns those XML reports into a readable dashboard, free for one domain, so a failing sender shows up in your reports before it shows up as bounced invoices.

Was this page helpful? Send us feedback

Last updated: July 2026

Standards basis: Advice based on RFC 9989 for DMARC policy records, RFC 9990 for aggregate reports, and RFC 9991 for failure reports. Historical RFC 7489 behavior is called out where relevant.

← All guides Start now

Need expert help with email deliverability?

Hire an email deliverability consultant who has shipped billions of emails. Free assessment, hands-on engagement, written quote before any work starts.

Talk to a consultant