How to set up SPF, DKIM & DMARC for Microsoft 365

The short version: publish one SPF TXT record that includes Microsoft, add the two DKIM CNAME records Microsoft provides and enable signing in the Defender portal, then publish a starter DMARC record. Together these tell Gmail, Yahoo and Outlook your mail genuinely comes from your Microsoft 365 tenant, and DMARC tells inboxes what to do when something fails while sending you reports. It’s free, and it’s verifiable in about a minute once DNS propagates.

What each record does here (the non-technical version)

Three layered proofs. SPF is a public list of servers allowed to send as your domain — you add Microsoft to it. DKIM is a cryptographic seal Microsoft applies to every message, verified against keys you expose via two CNAMEs. DMARC is the policy that requires at least one of those to pass and match your From address, and states what happens otherwise. A quirk worth knowing up front: Microsoft 365 applies DKIM signing with a default, non-aligned key until you explicitly enable custom-domain DKIM, so the CNAME step is what actually makes DMARC pass. For the underlying mechanics see the complete SPF, DKIM & DMARC guide.

Step 1 — Publish the SPF record

Add a single TXT record at the root of your domain with Microsoft’s stable, well-known include:

Host/Name:  @   (your root domain) Type:       TXT Value:      v=spf1 include:spf.protection.outlook.com -all

If you send through other services as well, add their includes to this same record — you may only have one v=spf1 record, and the total must stay within ten DNS lookups. Microsoft recommends -all (hard fail) since Exchange Online’s IPs are well-defined, but ~all is a safe starting point while you confirm nothing else sends as your domain. Microsoft’s reference: Set up SPF for Microsoft 365. Confirm it with the SPF Checker.

Step 2 — Add the two DKIM CNAMEs and enable signing

Microsoft 365 DKIM works through two CNAME records (selector1 and selector2) that point back into Microsoft’s infrastructure, which lets Microsoft rotate keys for you without you touching DNS again. The host names are stable; the target values are specific to your tenant and initial domain, so copy them from the Defender portal (or from your domain’s DKIM page). They follow this pattern:

Host/Name:  selector1._domainkey Type:       CNAME Value:      selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com Host/Name:  selector2._domainkey Type:       CNAME Value:      selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Substitute your real domain (dashes replace dots) and your real onmicrosoft.com tenant — take the exact targets from your console rather than typing them by hand. Once both CNAMEs resolve, enable signing:

1. Go to the Microsoft Defender portal.
2. Navigate to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
3. Select your custom domain and toggle Sign messages for this domain with DKIM signatures to Enabled.

If the toggle refuses to enable, the CNAMEs haven’t propagated yet — wait and retry. Microsoft’s reference: Set up DKIM for Microsoft 365. Verify the published selector with the DKIM Checker (selector selector1).

Step 3 — Publish a starter DMARC record

Add DMARC in monitor-only mode so nothing changes about delivery while you observe:

Host/Name:  _dmarc Type:       TXT Value:      v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r

The p=none policy simply turns on the daily aggregate reports delivered to the rua mailbox, showing every service sending as your domain and whether each passes. Build the record with the DMARC Generator, validate it with the DMARC Checker, and point rua at a parser via DMARC monitoring since the raw XML is unreadable by hand.

Step 4 — Verify everything passes

After DNS propagates (usually within a few hours), confirm all three at once with the Email Health Check, or individually with the SPF Checker, DKIM Checker and DMARC Checker. The definitive test: send a message to a personal Gmail account, open Show original, and confirm SPF, DKIM and DMARC all read PASS with your own domain in the d= DKIM field.

Step 5 — Move DMARC toward enforcement

After two to four weeks of reports where every legitimate sender passes, ramp the policy so spoofers are blocked: p=none → p=quarantine (optionally pct=25 first) → p=reject, checking reports at each stage. This is the policy the major providers reward and the gateway to a BIMI logo. The full staged rollout is in the complete guide.

Common mistakes

• Leaving the DKIM toggle off. The CNAMEs alone don’t sign anything — Microsoft signs with a default, non-aligned key until you enable custom-domain DKIM in the Defender portal, so DMARC keeps failing on the DKIM side.
• Publishing DKIM as TXT instead of CNAME. Microsoft 365 DKIM is two CNAMEs, not a TXT key. A pasted TXT value won’t work.
• A second SPF record. If one already exists, merge the Microsoft include into it — two v=spf1 records is a permerror that voids SPF.
• Only enabling one selector. Add both selector1 and selector2 CNAMEs; Microsoft rotates between them, and a missing one breaks signing after a rotation.
• Third-party senders left unaligned. Anything sending as your domain outside Microsoft 365 needs its own DKIM/SPF or DMARC fails for that stream. See why SPF passes but DMARC fails.

Where the records go

All of these live at your domain’s DNS host, not inside Microsoft 365. On Cloudflare, follow how to add DNS records in Cloudflare and keep them DNS-only (grey cloud) — a proxied CNAME will break DKIM. The always-current exact values are the ones Microsoft shows in the Defender portal and in your domain’s DKIM page; treat those as the source of truth for your tenant.