Why does Microsoft 365 need two CNAME records for DKIM instead of one TXT record like Google?

Microsoft hosts the actual signing keys itself and points your domain at them via CNAME, rather than publishing the public key directly in your zone the way Google's single TXT record does. Both CNAMEs are required — one alone leaves DKIM unable to validate.

What's the difference between ~all and -all in an SPF record?

~all (softfail) tells receivers to accept mail from unlisted servers but mark it suspicious; -all (hard fail) tells them to reject it outright. Microsoft's own documentation defaults to -all, a stricter starting point than the ~all commonly seen in other providers' examples.

Do I need to enable DKIM separately for each domain in Microsoft 365?

Yes — DKIM signing is turned on per accepted domain in the Defender portal (or via PowerShell), even after the CNAME records for that domain are published.

SPF, DKIM and DMARC for Microsoft 365: Step by Step

This is the applied, do-this-in-order version for Microsoft 365 — if you want to understand what SPF, DKIM and DMARC actually do first, read those guides. This one covers only the Microsoft-specific records and portal steps.

SPF for Microsoft 365

Add a single TXT record at your domain's root:

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

Microsoft's own documentation defaults to -all (hard fail) rather than the ~all (soft fail) commonly seen elsewhere — a stricter starting point, worth knowing before you copy a record from a different provider's example.

DKIM for Microsoft 365 — Two CNAMEs, Not One TXT

Unlike Google's single TXT record, Microsoft 365 DKIM uses two CNAME records that Microsoft generates for you, each pointing to a Microsoft-hosted key:

selector1._domainkey.yourdomain.com.  CNAME  selector1-yourdomain-com._domainkey.<tenant>.onmicrosoft.com.
selector2._domainkey.yourdomain.com.  CNAME  selector2-yourdomain-com._domainkey.<tenant>.onmicrosoft.com.

Get the two CNAME values for selector1._domainkey and selector2._domainkey from the Microsoft Defender portal (Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM), or via the Set-DkimSigningConfig PowerShell cmdlet
Add both CNAME records exactly as given
Enable DKIM signing for the domain in the same Defender portal screen — like Google, publishing the records alone does not turn signing on

DMARC for Microsoft 365

Same as everywhere else: a TXT record at _dmarc.yourdomain.com, published directly in DNS rather than through a Microsoft-specific interface. Start with p=none — see our DMARC guide for the full rollout path.

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Verifying All Three

Once every record is published and DKIM signing is enabled, an email security check confirms SPF, DKIM and DMARC all resolve and align correctly.

Mistakes That Break This Setup

Adding only one of the two required CNAME records — both are needed, and a single missing one leaves DKIM unable to validate
Publishing the CNAME records but never flipping DKIM signing on in the Defender portal
Hybrid Exchange setups where some mail flows through on-premises servers not covered by the include:spf.protection.outlook.com mechanism, requiring their own IPs added to the SPF record

Verify Your Setup

Run an email security check →Next: Migrating DNS providers safely →

Try it on your domain

See the theory in practice — run a Email Security Check for your own domain.