Microsoft 365 Email Authentication: SPF, DKIM & DMARC

Set up SPF, DKIM and DMARC for Microsoft 365: one outlook.com SPF record, the selector1/selector2 CNAMEs in the Defender portal, and a safe DMARC rollout.
4 min read
Updated 2026-11-04
Brand Specific
microsoft-365spfdkimdmarc

Exchange Online routes and signs your mail, but the DNS side of authentication is still yours. Domains without correct SPF, DKIM and DMARC fail the bulk-sender requirements Gmail, Yahoo and Outlook.com have enforced since 2024 — often silently, showing up only as mail quietly landing in spam.

This guide covers the records and the current console path (DKIM moved from the Exchange Admin Center to the Microsoft Defender portal). Read the email authentication overview first if the protocols are new to you.

What you need

  • A Microsoft 365 tenant with admin access to the Microsoft Defender portal at security.microsoft.com.
  • Your custom domain added and verified in the tenant. Initial *.onmicrosoft.com domains are signed by Microsoft and need no DKIM work.
  • DNS write access. On Cloudflare, check the Cloudflare DNS guide. Also list non-Microsoft senders (CRM, marketing, ticketing) — none of the records below covers them.

Step 1: Publish one SPF record

Create a single TXT record at the root of your custom domain:

v=spf1 include:spf.protection.outlook.com -all

Two rules dominate this step:

  • One record only. If an old provider's SPF TXT survives a migration, SPF fails permanently. Delete it and merge what you still need: v=spf1 include:spf.protection.outlook.com include:mailgun.org ip4:203.0.113.10 ~all.
  • Mind the ten-lookup limit. RFC 7208 caps evaluation at ten DNS lookups including nested includes. Re-check the count with the SPF Checker; if you are close to the limit, see the SPF flattening guide.

Keep ~all during validation and move to -all once DMARC reports show complete coverage.

Step 2: Enable DKIM in the Defender portal

Microsoft generates and rotates the key pairs; you prove ownership with two CNAMEs.

  1. At security.microsoft.com, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings and select the DKIM tab. The direct link is security.microsoft.com/authentication?viewid=DKIM.
  2. Slide your custom domain's toggle to Enabled. A client error dialog appears — expected: it contains the CNAME values. Dismiss it and open the domain's details flyout, where Publish CNAMEs shows the same values cleanly.
  3. Create the two CNAMEs at your DNS host:
selector1._domainkey  CNAME  selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey  CNAME  selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Domains added since May 2025 use a new target format ending in .dkim.mail.microsoft — copy the exact values from the flyout, not from any article. Note the hyphenated form: your domain appears as yourdomain-com in the target.

  1. Wait for the status to leave CnameMissing, then enable the toggle. Detection takes minutes to hours.

New tenants use 2048-bit keys. If yours still uses 1024-bit, rotate via Rotate DKIM keys in the flyout (up to 96 hours, current key keeps signing). Verify with the DKIM Checker using selector selector1.

Step 3: Publish DMARC in your own DNS

DMARC is a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

p=none blocks nothing and collects aggregate reports, read with the DMARC Report Analyzer. Only when every legitimate sender passes do you move through p=quarantine; pct=25 to p=reject. Generate the record with the DMARC Generator.

Verify the whole stack

Send from Exchange Online to an external Gmail or Outlook.com address and inspect headers — Show original in Gmail, or the header analyzer anywhere else:

spf=pass (sender IP is 203.0.113.10)
dkim=pass (signature was verified) header.d=yourdomain.com
dmarc=pass action=none header.from=yourdomain.com

header.d= must be your domain, never onmicrosoft.com — that is the alignment check. For a full sweep, run the Email Health Check or the Email Deliverability Test.

Common mistakes

  • Two SPF records after migration. The old provider's TXT was never deleted, so SPF returns a permanent error. One v=spf1 record per domain.
  • Guessing the CNAME target. The format changed over time and includes a Microsoft-assigned character segment. Copy from the flyout or run Get-DkimSigningConfig in Exchange Online PowerShell.
  • Trying to DKIM-enable the initial domain. Only custom domains appear on the DKIM tab and need CNAMEs.
  • Third-party senders left unaligned. A CRM relaying through your tenant can break alignment unless routed via a connector; independent services (SendGrid, Mailgun) need their own records — see the SendGrid and Mailgun guides.
  • DMARC reject on day one. Enforcement before monitoring rejects legitimate mail from every sender you forgot.

Frequently asked questions

Why two DKIM CNAME records?

Microsoft keeps two selectors so keys rotate without a signing gap: while one rotates, the other signs. Publish both or DKIM breaks at the next rotation.

Can I use TXT records instead of CNAMEs?

Not for Microsoft-managed keys — the CNAMEs point at Microsoft's key infrastructure so rotation is automatic. TXT-based DKIM is typical only for third-party senders on your domain.

My DKIM status is stuck on CnameMissing. What now?

Almost always a host-name problem: the provider appended your domain, or the hyphenated yourdomain-com form was mistyped. Confirm what is live with the DKIM Checker and compare character by character.

Was this guide helpful?