How to set up SPF and DKIM for Microsoft 365

If you've set up DKIM for Google Workspace or for any transactional ESP, you know the drill: generate a key, copy a TXT record, paste it into DNS, flip a switch. Microsoft 365 does none of this the way you expect. DKIM is delivered as two CNAME records that point back at Microsoft's infrastructure, not a TXT you publish yourself. The toggle to turn it on doesn't work until both CNAMEs resolve. And the portal path to find the values changes every 18 months. Here's the current order.

SPF for Microsoft 365 — the default record

Every M365 tenant needs one SPF record on the domain root. The Microsoft-recommended default is:

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

Publish it as a TXT record at the apex (@ or yourdomain.com). Do not publish a second SPF record — multiple SPF records on the same host cause an immediate permerror, which receivers treat as "no SPF at all".

Adding third-party senders to SPF

If you also send through SendGrid, Mailchimp, HubSpot or any other service, add them to the same record using additional include: statements:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.mailjet.com -all

Each include: counts toward the 10-DNS-lookup limit. Microsoft's own include is worth one lookup. SendGrid is three, Mailchimp is one, HubSpot is one. Count them up and stay under ten or you'll trip permerror without warning.

Custom domain + hybrid Exchange setup

Running on-prem Exchange alongside M365? You need to include both senders. The pattern is the M365 include plus an ip4: block for your on-prem edge server:

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

Replace 203.0.113.10 with your actual Exchange edge IP (or range). Test by sending a message from both environments and checking the Authentication-Results header on the receiving side.

DKIM for M365 — the two CNAME records

Here is where M365 diverges. Instead of generating a TXT DKIM record you publish yourself, Microsoft provisions the keys on their infrastructure and wants you to point two CNAMEs at them. The host names are predictable:

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

Why two? M365 rotates keys automatically by swapping which selector is actively signing. You always publish both so the rotation is transparent.

Where to find the exact CNAME values

Don't guess the values — copy them from the portal.

1. Go to security.microsoft.com (Microsoft Defender portal).
2. Sidebar: Email & collaboration → Policies & rules → Email authentication settings.
3. Click the DKIM tab.
4. You'll see the list of domains in the tenant. Click the domain you want to configure.
5. A flyout shows CNAMEs to publish with the exact selector1 and selector2 targets. Copy both.

Publish both CNAMEs in DNS

In your DNS provider, create two CNAME records:

• Host selector1._domainkey → target from the portal.
• Host selector2._domainkey → target from the portal.

Save. Before you touch the Defender portal again, verify both resolve:

dig CNAME selector1._domainkey.yourdomain.com @8.8.8.8 +short
dig CNAME selector2._domainkey.yourdomain.com @8.8.8.8 +short

Both must return the selectorN-yourdomain-com._domainkey. <tenant>.onmicrosoft.com target. If either is empty, wait. Do not toggle anything in the portal yet.

Enable DKIM — only after both CNAMEs resolve

Back in Defender → DKIM → pick your domain. The detail flyout has a toggle labelled Enable. Switch it on. If the CNAMEs resolve, the toggle flips successfully and Microsoft begins signing outgoing mail from that domain within minutes. If they don't yet, you get an error: "CNAME record does not exist for this config. Please publish the following two CNAME records first."

Why the Enable toggle fails

Three causes, in order of frequency:

• DNS propagation. You published the CNAMEs ten minutes ago. Microsoft's resolvers haven't seen them yet. Wait 30–60 minutes.
• Cached negative lookup. Microsoft cached the "not found" result for up to a few hours. Same fix — wait.
• Wrong host name. You published selector1 pointing at the apex or at the wrong tenant domain. Double-check the target matches the portal exactly, including the full .onmicrosoft.com tenant suffix.

Verifying — dig, test send, Authentication-Results

Send a message from the M365 mailbox to an external address (Gmail, a personal address you control). Open the original source. You want to see:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=selector1
       spf=pass (google.com: domain of user@yourdomain.com designates 40.92.x.x as permitted sender)

The dkim=pass with header.i=@yourdomain.com (not the tenant's onmicrosoft.com) is the signal that everything aligned correctly. If header.i shows the tenant domain, the signing is working but your domain is using M365's default key, not your own — you missed step 6.

DMARC for M365 — same pattern as any domain

DMARC doesn't change for M365. Publish a TXT at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

Start at p=none so you can read reports without any blocking. Run this for two weeks, fix any alignment failures from third-party senders, then move to p=quarantine and eventually p=reject. The adkim=s and aspf=s enforce strict alignment — in M365 this is almost always fine because the signing domain matches your From domain as long as DKIM was enabled correctly.

Rotation — M365 handles it automatically

Unlike Google Workspace, Microsoft rotates DKIM keys for you. The two CNAMEs you published point to selectors whose underlying keys M365 updates on its own schedule. You don't regenerate anything, ever. This is the one thing M365 does better than every other mail provider — and you don't even have to think about it.

Frequently asked questions