Setup Guides · Microsoft 365
Microsoft 365 DMARC Setup: The Enforcement Path Without Breaking Your Mail
The DMARC record itself is one TXT entry. On Microsoft 365 the real work is alignment: because the tenant default signs as onmicrosoft.com, your DMARC leans on SPF alone until you fix DKIM - and SPF breaks the moment mail is forwarded. This guide covers the exact record, the monitor-then-enforce path to p=reject, and the Microsoft-specific traps. For the generic policy mechanics, see DMARC setup and enforcement.
Last updated 30 August 2026 · applies to all Microsoft 365 / Exchange Online tenants
Why alignment is the hard part on Microsoft 365
DMARC does not ask whether SPF or DKIM passed - it asks whether the domain that passed matches your From domain (see what alignment means). Microsoft 365 gives you two alignment paths, and out of the box only one of them half-works:
- SPF aligns when you publish
include:spf.protection.outlook.com(see the Microsoft 365 SPF guide). It aligns on direct mail - but SPF breaks whenever a message is forwarded, so it cannot carry an enforced policy alone. - DKIM aligns only after you enable custom-domain DKIM. Until then Microsoft signs as
d=yourtenant.onmicrosoft.com, which never aligns (the onmicrosoft.com trap). Aligned DKIM survives forwarding - it is what makesp=rejectsafe.
Before you enforce DMARC, finish custom-domain DKIM and a correct SPF record. DMARC is only as safe as the alignment underneath it.
What you need
- Custom-domain DKIM enabled and verifying as
d=yourdomain.com. - An SPF record containing
include:spf.protection.outlook.com. - Access to your public DNS to publish one
_dmarcTXT record. - A free DMARC monitor to read the reports before you tighten the policy.
The setup, step by step
1 Confirm both alignment paths
Send one email and check the headers (or run it through Postbox Mailtester). SPF should show your domain via spf.protection.outlook.com, and the DKIM-Signature should read d=yourdomain.com - not onmicrosoft.com. If DKIM still shows the tenant default, fix that first; enforcing now would rely on SPF alone.
2 Publish the DMARC record at p=none
In your public DNS, add one TXT record. This changes nothing about delivery - it only asks receivers to report what is sent as your domain.
Name: _dmarc.yourdomain.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r
DMARC lives in DNS, not the Microsoft 365 admin center - the admin center only manages SPF and DKIM. If a checker shows two _dmarc records, merge them into one.
3 Monitor - see who sends as your domain
Aggregate reports arrive as raw XML from dozens of receivers. Point the rua address at Postbox DMARC Monitor to get a plain-English weekly digest of every source and whether it aligns. Microsoft 365 tenants almost always find sources they forgot - a marketing platform, an invoicing tool, a scanner or app relaying through a connector.
4 Align the strays (the Microsoft-365-specific ones)
For each legitimate source, add it to SPF or give it aligned DKIM. Watch for the Microsoft-365 patterns: mail sent through an inbound/outbound connector or smart host may bypass Exchange Online Protection's signing, and high-volume marketing often sends from a separate platform that needs its own alignment. Do not enforce until the reports show every real source passing DMARC.
5 Ramp to quarantine, then reject
Move to p=quarantine (ease in with pct=25, still honoured by most receivers though DMARCbis has removed it), watch a week, then p=reject. Add sp=reject for subdomains you never send from, plus np=reject to block spoofed non-existent ones. Only unaligned, likely-spoofed mail is affected. The full ramp mechanics, and the pct=-to-t= change, are in the shared enforcement guide.
Microsoft-specific notes
Microsoft 365 is also a receiver: once you publish an enforcing policy, Microsoft honours it on inbound mail claiming to be you, and your DMARC result feeds the compauth verdict its filters stamp. Microsoft has also joined Google and Yahoo in requiring bulk senders to publish a DMARC policy (at least p=none) with aligned SPF and DKIM - so this setup is now table stakes for reaching the inbox, not just anti-spoofing hygiene.
The failures we keep finding
1. Enforcing on SPF alignment only
The tenant still signs as onmicrosoft.com, so DMARC passes on SPF - until a message is forwarded, SPF breaks, and at p=reject that legitimate mail bounces. Enable custom DKIM before you enforce.
2. A connector or smart host that bypasses signing
Mail relayed out through a device or app connector may not get EOP's DKIM signature, so it fails alignment while direct mail passes. The reports flag it as an unaligned source from your own infrastructure - route it through EOP or give it its own aligned DKIM.
3. Jumping to reject before monitoring
Almost every tenant sends from more services than the admin remembers. Enforce before you have read the reports and you spam-folder or bounce that legitimate mail. Monitor at p=none first - always.
4. Subdomains left open
An enforced apex policy still leaves subdomains spoofable unless you set sp=. Set sp=reject for subdomains you never send from, and add np=reject (DMARCbis) to shut down spoofed non-existent subdomains at no monitoring cost.
Verify it end to end
- Check the record: the DMARC checker validates it; the DMARC generator builds a correct one.
- Monitor before enforcing: Postbox DMARC Monitor shows every source and its alignment - the evidence you tighten on.
- Confirm on a real message: send one email to Postbox Mailtester - it reports SPF, DKIM, DMARC and whether each aligns, and forecasts Microsoft's compauth verdict.
Frequently asked questions
Do I set the DMARC record inside Microsoft 365?
No - it is a TXT record in your public DNS at _dmarc.yourdomain.com, not an admin-center setting. Microsoft 365 supplies the SPF and DKIM alignment; the policy lives in DNS.
Why does my mail fail DMARC even though DKIM passes?
The default signature is d=yourtenant.onmicrosoft.com, which verifies but does not align. Until you enable custom-domain DKIM, DMARC relies on SPF alone - which breaks on forwarding.
Can I reach p=reject with just SPF?
Only for direct mail - forwarded messages break SPF and then fail DMARC, so they bounce at p=reject. Aligned custom DKIM survives forwarding, which is why you enable it first.
Do I need DMARC to meet Microsoft's sender requirements?
Yes. Microsoft, Google and Yahoo now require bulk senders to publish a DMARC policy (at least p=none) with aligned SPF and DKIM.
Related: DMARC enforcement path · Microsoft 365 DKIM · Microsoft 365 SPF · Google Workspace DMARC.
Ready to see who is sending as your domain?