Microsoft 365 DMARC setup

Updated 2026-08-03 · Setup Guides

Microsoft 365 can authenticate your mail perfectly — but unlike Google Workspace, it doesn't fully do so out of the box. The SPF part is one include. The DKIM part is two CNAME records plus a switch, and until you flip that switch, Microsoft signs your mail with a domain that isn't yours. That last detail catches out more Microsoft 365 tenants than everything else combined, so this guide spends time on it.

Office 365 or Microsoft 365 — is the DMARC setup different?

No. Microsoft renamed most of its Office 365 subscription plans to Microsoft 365 in April 2020; a few enterprise plans kept the older name, and a great deal of documentation, support tickets and DNS runbooks still say Office 365, or shorten it to O365. Nothing behind the name changed for email authentication.

There is no separate DMARC for Office 365. An O365 DMARC record is the same v=DMARC1 TXT record at _dmarc, in the same DNS zone, as a Microsoft 365 one; the SPF include is the same hostname and the DKIM CNAMEs come from the same portal. Where you find one guide headed DMARC Office 365 and another headed DMARC Microsoft 365, both describe the records below. Follow the steps whichever name your subscription carries.

Step 1: SPF — one include

Microsoft publishes its sending infrastructure behind a single hostname:

example.com.   TXT   "v=spf1 include:spf.protection.outlook.com ~all"

As always: a domain may have only one SPF record. If one already exists, edit it and add include:spf.protection.outlook.com before the all mechanism rather than publishing a second record. For ordinary outbound mail, Microsoft 365 uses your own domain in the envelope-from, so an SPF pass is aligned and counts for DMARC.

Step 2: DKIM — two CNAMEs from the Defender portal

Microsoft's DKIM setup uses CNAME indirection: you publish two CNAME records on your domain that point into Microsoft's DNS, and Microsoft rotates the actual keys behind them. The records follow this pattern:

selector1._domainkey.example.com   CNAME   selector1-<domain-guid>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.example.com   CNAME   selector2-<domain-guid>._domainkey.<tenant>.onmicrosoft.com

Don't construct these by hand. The exact targets — your domain GUID and tenant name — are shown in the Microsoft Defender portal (security.microsoft.com), under its email authentication / DKIM settings, per domain. Copy both hostnames and both targets precisely from there into your DNS provider's record editor.

Once both CNAMEs resolve, return to the same Defender portal page and enable DKIM signing for your custom domain — the toggle that says messages for this domain should be signed with DKIM signatures. Publishing the CNAMEs without flipping the toggle changes nothing, and the toggle refuses to flip until the CNAMEs are visible in DNS, so expect a short propagation wait between the two actions.

The onmicrosoft.com trap

Here is the gotcha. Every Microsoft 365 tenant has a built-in address space on <tenant>.onmicrosoft.com (Microsoft calls it the MOERA domain), and until you enable custom-domain DKIM, Microsoft signs your outbound mail with that domain — d=contoso.onmicrosoft.com, not d=example.com.

That signature is cryptographically valid, so a raw DKIM check passes. But DMARC doesn't ask "did a signature verify?" — it asks "did a signature verify for the From domain?". A signature on onmicrosoft.com is unaligned with a From address on your domain, so it contributes nothing to DMARC. In your DMARC reports this shows up as a distinctive fingerprint: DKIM pass on the wrong domain, alignment fail. If you see Microsoft 365 sources in that state, the fix is exactly the two CNAMEs and the toggle above. The full pass-versus-aligned distinction is covered in DMARC alignment explained, and how DKIM's d= domain works in What is DKIM?

Why aligned DKIM is the one that matters

With both steps done, direct mail from Microsoft 365 passes DMARC twice over: aligned SPF and aligned DKIM. But the two are not equally durable.

SPF breaks on forwarding — when a recipient's old mailbox relays to a new one, or a mailing list redistributes your message, the final hop comes from the forwarder's server, which isn't in your SPF record. DKIM's signature travels inside the message and survives ordinary forwarding intact. Since DMARC only needs one aligned pass, aligned DKIM is what keeps your forwarded mail passing. Treat SPF as the bonus and DKIM as the foundation — and don't consider a Microsoft 365 tenant "done" on SPF alone.

Publish DMARC and confirm

Finish with a DMARC record at _dmarc on your domain, starting at p=none so you're monitoring rather than blocking:

_dmarc.example.com.   TXT   "v=DMARC1; p=none; rua=mailto:…"

Point the rua= address at a monitor and let a few days of reports accumulate — Add your first domain walks the DMARCmetric flow end to end. You can sanity-check the published SPF and DMARC records any time with the free checker. Once the reports show your Microsoft 365 mail passing with your domain in both the SPF and DKIM columns — and any third-party senders are aligned too — you're ready to ramp the policy up.

Office 365 DMARC setup checklist

Everything above on one screen. The values are the ones from Step 1 and Step 2 — substitute your own domain, and copy the two DKIM targets from the portal rather than typing them out from this page.

Work down the table in order: SPF and the two CNAMEs first, then the signing toggle, then DMARC. Starting the policy at p=none means nothing is blocked while the rest settles, and every optional tag you might add later is listed in DMARC record tags explained. When the lines are published, run the domain through the free DMARC checker to confirm the record is visible from the outside.

Common Office 365 DMARC questions

Where in Microsoft 365 do I add the DMARC record?

Nowhere in the portal. DMARC in Office 365 is not a tenant setting — the record is a TXT record in public DNS, so you create it wherever your domain's DNS is hosted, alongside the SPF record. The portal's involvement stops at DKIM: the Defender portal shows you the two CNAME targets and holds the signing toggle. If you have been hunting the admin centre for a DMARC page, that is why there isn't one.

Why does my Office 365 mail fail DMARC when DKIM passes?

Almost always the onmicrosoft.com trap described above. Until custom-domain DKIM is enabled, Microsoft signs with d=<tenant>.onmicrosoft.com: the signature verifies, so a plain DKIM check reports a pass, but it is unaligned with your From domain and contributes nothing to DMARC. The fix is the two CNAMEs and the toggle from Step 2; the underlying distinction is unpacked in DMARC alignment explained.

Do I still need DMARC if all my mail goes through Office 365?

Yes. SPF and DKIM prove that mail genuinely sent through your tenant is yours; neither tells a receiving server what to do about mail that is not. Only DMARC does that, and only DMARC gets you the reports that show who else is sending as your domain — see What is DMARC?. If you send bulk mail to Gmail or Yahoo addresses, a published DMARC record is also part of their sender requirements, and p=none meets that minimum.

Encryption and authentication are two different jobs

Outlook's Encrypt button is easy to mistake for a DMARC control. Encryption and authentication solve different problems.

Both gaps matter: encrypting a message does not stop anyone spoofing your domain, and a p=reject policy does not encrypt anything. If you need both, configure both.

Does sending a secure or encrypted email in Outlook fix my DMARC?

No. Encryption applies to a message as you send it; DMARC is evaluated by the receiving server against your DNS records and the From domain. Encrypting everything you send changes nothing in your reports and nothing about what an attacker can send in your name.