Does Microsoft 365 honor DMARC p=reject, and how do you control it?

When a domain publishes DMARC with p=reject, it's asking receivers to refuse mail that fails authentication. Whether your Microsoft 365 tenant does that is your choice, made in the anti-phishing policy. This guide explains the setting, its defaults, what overrides it and how to read the result, as documented at the time of writing (October 2026). For publishing DMARC on your own domain, see DMARC setup for Microsoft 365.

Does Microsoft 365 honor DMARC p=reject?

Yes, by default. The anti-phishing setting Honor DMARC record policy when the message is detected as spoof (HonorDmarcPolicy) is selected by default. With it on, Microsoft 365 rejects messages that fail the sender's p=reject policy and quarantines messages that fail p=quarantine (Microsoft Learn).

That's a decision for each receiver. RFC 9989, the current DMARC standard, says "the final handling of any message is always a matter of local policy". It adds that receivers "SHOULD NOT reject messages solely because of a published policy of 'reject'" and should use other analysis to avoid rejecting legitimate mail. Microsoft says something similar: a composite authentication failure "doesn't directly result in a message being blocked."

What are the Honor DMARC settings and their defaults?

All three settings live in each anti-phishing policy, under spoof protection. These are Microsoft's values for the default policy and the Standard and Strict presets:

Sources: Microsoft's recommended settings and the Set-AntiPhishPolicy reference. If you choose Quarantine the message, Microsoft uses the quarantine policy selected for spoof intelligence. Our guide to anti-phishing policy settings covers the rest of the policy.

How does spoof intelligence change what happens?

The outcome depends on two switches: spoof intelligence and Honor DMARC. Microsoft separates explicit failures (a sender's DMARC fails) from implicit ones (Microsoft's own composite authentication flags a message from a domain with weak or no DMARC).

This is a condensed version of Microsoft's table in Spoof protection and sender DMARC policies. The practical point: with Honor DMARC off, a sender's p=reject is treated like any other spoof and goes to Junk by default.

How do you check and turn on Honor DMARC?

1. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Anti-phishing, or open https://security.microsoft.com/antiphishing.
2. Select each policy, including Office365 AntiPhish Default, by clicking its row. In the details flyout, select Edit in the actions section.
3. Make sure Honor DMARC record policy when the message is detected as spoof is selected.
4. Check the two actions: Quarantine the message for p=quarantine and Reject the message for p=reject.
5. Save. Microsoft says to allow up to 30 minutes for a policy change to apply.

To review every policy at once in Exchange Online PowerShell:

Get-AntiPhishPolicy |
  Format-List Name, Enabled, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

To set the defaults back explicitly:

Set-AntiPhishPolicy -Identity "Office365 AntiPhish Default" `
  -HonorDmarcPolicy $true -DmarcQuarantineAction Quarantine -DmarcRejectAction Reject

Policies created by the Standard and Strict preset security policies can't be edited this way. Microsoft applies Strict, then Standard, then custom policies, then the default. If a user is in a preset, its settings win; see preset security policies.

What does a DMARC rejection look like?

For messages Microsoft 365 receives, check the Authentication-Results header. Microsoft's DMARC article gives this example of a message that failed alignment (example):

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Our Microsoft 365 spam headers guide explains compauth and the reason codes.

The sender gets a bounce. Microsoft's NDR reference lists it as 5.7.509 (example):

Access denied, sending domain [example.com] does not pass DMARC verification and has a DMARC policy of reject.

Microsoft's DMARC article summarizes the same rejection as 550 5.7.1, so match on the text, not just the code. If you're the sender, our 5.7.509 reference covers the fixes.

Is Honor DMARC the same as your own DMARC policy?

No. They work in opposite directions, and admins often mix them up.

Your own p=reject also has a side effect inside Microsoft 365. Microsoft says outbound mail from your domains that fails DMARC at the destination is routed through its high-risk delivery pool when your policy is p=reject or p=quarantine, and "there's no override for this behavior." Fix your own senders before you enforce; our p=none to p=reject guide covers the order.

What happens to p=quarantine failures?

By default, Microsoft 365 quarantines them, because DmarcQuarantineAction defaults to Quarantine. You can choose the Junk Email folder instead. Microsoft's DMARC article describes the p=quarantine outcome as "Junk Email folder (configurable to quarantine)", which doesn't match the policy defaults above; check your own policy with Get-AntiPhishPolicy rather than relying on either summary. Quarantined messages follow your quarantine policy, which decides whether users can see and release them. See Microsoft 365 quarantine policies.

What overrides Honor DMARC in Microsoft 365?

Microsoft lists these ways to override the setting for specific messages or senders:

• Safe Senders. Users' Outlook Safe Senders lists, or the safelist collection an admin sets in PowerShell.
• Spoof intelligence insight allow decisions.
• Tenant Allow/Block List allow entries for spoofed senders (see our Tenant Allow/Block List guide).
• Allowed sender or domain lists in anti-spam policies.
• Mail flow rules that allow messages from particular senders, or that handle mail failing DMARC.

Each override opens a gap for that sender, including forged mail that claims to be from them. Our guide to allowlisting senders safely covers how to keep entries narrow.

Why is legitimate mail being rejected for DMARC, and how do you fix it?

Start from the rejected message's headers, then work down this list:

1. The sender's own setup is broken. A service sends as their domain without aligned SPF or DKIM. This is the most common cause, and the fix is theirs. Send them the bounce or headers.
2. Forwarding or a mailing list changed the message. Forwarding breaks SPF, and edits break DKIM. If a known service sits in between, add it in the Defender portal as a trusted ARC sealer under Email authentication settings > ARC (Microsoft Learn). See how forwarding breaks SPF and DMARC.
3. A gateway sits in front of Microsoft 365. Microsoft says Honor DMARC "is applied only if Enhanced Filtering for Connectors is enabled" on the inbound connector. Without it, Microsoft 365 checks the gateway's IP instead of the real sender's.
4. You need mail now. Microsoft suggests, in order: a trusted ARC sealer, a mail flow rule matching both the sender IP and domain, or a temporary Tenant Allow/Block List entry.

Mail that failed DMARC reached the inbox anyway

Microsoft's own troubleshooting table lists dmarc=fail action=oreject on a delivered message as a sign that "Honor DMARC [is] disabled, or allow list/override in place". Check the anti-phishing policy that applied, then the Tenant Allow/Block List and mail flow rules.

Next steps

1. Run Get-AntiPhishPolicy and confirm HonorDmarcPolicy is True in every policy.
2. Review allow entries and mail flow rules that could bypass DMARC, and remove any you can't justify.
3. If a filtering service sits in front of Microsoft 365, confirm Enhanced Filtering for Connectors is on; our Enhanced Filtering guide shows how.
4. Check your own domain's DMARC policy with the DMARC Checker, so the receivers you send to can do the same for you.

If you want filtering in front of Microsoft 365 that keeps these checks working, see how iBlockSpam sets up Microsoft 365. Browse more setup guides.