Microsoft 365 SPF, DKIM and DMARC Setup

Microsoft 365 needs an SPF TXT record with include:spf.protection.outlook.com, two DKIM CNAME records at selector1._domainkey and selector2._domainkey, and a DMARC TXT record at _dmarc. Custom domains are not DKIM signed until you publish the CNAMEs and switch signing on. In our scan of the Tranco top 1,000 domains on 19 October 2026, 98 SPF records included the Microsoft 365 range.

The records at a glance

There is no SPF or DMARC switch inside Microsoft 365 for custom domains. You create both TXT records at your DNS host. DKIM is the one part that has to be done on both sides.

SPF for Microsoft 365

Microsoft's SPF guide gives one record per cloud:

Microsoft recommends -all, not ~all. Its reason is specific: DMARC counts both as failures, but a ~all failure on a message with no DKIM signature is effectively ignored by the DMARC policy. Microsoft also suggests a TTL of at least 3600 seconds on the SPF record to avoid lookup timeouts.

When we resolved spf.protection.outlook.com on 19 October 2026 it contained only ip4 and ip6 ranges, so it costs a single DNS lookup. That leaves 9 of the 10 that RFC 7208 allows for your other senders. Add them to the same record, for example v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all, which is Microsoft's own example. A domain can have only one SPF record. The SPF checker counts the lookups for you.

The *.onmicrosoft.com domain already has an SPF record that Microsoft maintains. You cannot edit it, and you do not need to.

DKIM: two CNAMEs per domain

Microsoft generates two key pairs for each custom domain. Only one selector signs at a time. The other waits for the next key rotation. Both CNAMEs must exist before you can turn signing on.

The two CNAME formats

This is where most Microsoft 365 setups go wrong. The host names never change: selector1._domainkey and selector2._domainkey. The targets come in two formats, and Microsoft's DKIM guide says they cannot coexist for the same selector.

Older format, still used by domains added before May 2025 and by initial domains:

selector1._domainkey  CNAME  selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey  CNAME  selector2-contoso-com._domainkey.contoso.onmicrosoft.com

Newer format, for custom domains added from May 2025:

selector1._domainkey  CNAME  selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft
selector2._domainkey  CNAME  selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

In the new format, contoso-com is your domain with dots turned into dashes, contoso is your initial onmicrosoft.com prefix, and the single letter before -v1 (here n, sometimes r) is assigned by Microsoft and cannot be chosen. Do not build these values by hand. Copy them from the portal, or run this in Exchange Online PowerShell:

Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Microsoft's own domain still uses the older form. On 19 October 2026, selector1._domainkey.microsoft.com pointed to selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

Where to do it in the Defender portal

1. Open the Defender portal at security.microsoft.com and go to Email and collaboration, then Policies and rules, then Threat policies, then Email authentication settings. The direct address is security.microsoft.com/authentication.
2. Select the DKIM tab.
3. Try to slide the toggle for your domain to Enabled. A "Client error" dialog appears. Click OK. The status is now CnameMissing.
4. Click the domain row to open its details. Copy the two values under Publish CNAMEs.
5. Create the two CNAME records at your DNS host.
6. Come back after a while and switch on Sign messages for this domain with DKIM signatures. The status should read "Signing DKIM signatures for this domain".

Microsoft says it takes "a few minutes (or possibly longer)" to detect the new CNAMEs.

Key length

Microsoft creates 1024-bit keys by default. To move to 2048, rotate with PowerShell: Rotate-DkimSigningConfig -Identity contoso.com -KeySize 2048. A rotation takes four days (96 hours) before the new key signs mail, and Microsoft notes the new size applies to the next active selector only, so it takes a second rotation to move both selectors to 2048. Because the records are CNAMEs, your DNS never holds the long key, which avoids the 255-character TXT split.

How Microsoft 365 aligns for DMARC

• DKIM alignment. After signing is on, the d= domain in the signature is your custom domain, so it aligns with the From address. Before that, custom domain mail has no aligned DKIM signature.
• SPF alignment. SPF aligns when the MAIL FROM (Return-Path) domain matches the From domain. For users sending from your custom domain, check the Return-Path header of a test message; if it shows your domain and the SPF include is in place, SPF aligns too.

Microsoft's DMARC guide adds a consequence worth knowing. If your policy is p=quarantine or p=reject and a message fails DMARC at the receiving end, Microsoft routes it through its high-risk delivery pool, with no override. That is one more reason to get DKIM on before you enforce.

DMARC record

Create a TXT record named _dmarc at your DNS host. Microsoft's guide suggests starting with p=none on a low-volume domain or subdomain, then tightening. A starting record:

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

Subdomains you have not defined inherit the parent's DMARC policy. If you send only from *.onmicrosoft.com, Microsoft says you still need a DMARC record for it, added in the Microsoft 365 admin center under the domain's settings. The DMARC generator builds a record for your own domain.

Checking the result

Send from a Microsoft 365 mailbox to an outside account and read the headers. You want spf=pass, dkim=pass with header.d= set to your domain, and dmarc=pass. The DKIM-Signature header shows s=selector1 or s=selector2.

Check from outside as well. Run the SPF checker, then the DKIM checker with your domain in place of example.com (try selector2 too), and the DMARC checker. Upload the first week of aggregate reports to the DMARC analyzer to find any sender still failing before you move to p=quarantine.

Frequently asked questions

Sources

• Microsoft Learn: Set up DKIM to sign mail from your cloud domain
• Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain
• Microsoft Learn: Set up DMARC to validate the From address domain for cloud senders
• RFC 7208: Sender Policy Framework (10 DNS lookup limit)