How do I set up email authentication on Microsoft 365?
Scott Anderson · Last reviewed
Short answer
Publish one SPF record containing include:spf.protection.outlook.com, then enable DKIM in the Defender portal, which requires two CNAME records at selector1._domainkey and selector2._domainkey pointing back to Microsoft. Finally publish a DMARC record at _dmarc with a reporting address. DKIM is off by default for custom domains and must be switched on per domain.
Key facts
Microsoft 365 DKIM uses two CNAME records — selector1 and selector2 — so that Microsoft can rotate keys without you touching DNS again. Microsoft: configure DKIM ↗
The SPF include for Microsoft 365 is spf.protection.outlook.com. Microsoft: configure SPF ↗
DKIM signing for custom domains must be enabled explicitly; without it, mail is signed with the onmicrosoft.com domain, which doesn't align with your From: address. Microsoft: configure DKIM ↗
Microsoft 365 has a specific failure mode worth knowing about. Out of the box, your outgoing mail is DKIM-signed — but with your tenant's onmicrosoft.com domain rather than your real one. Signing therefore appears to be working, while DMARC alignment quietly fails, because the signature doesn't match the domain your recipient sees.
That's why so many 365 domains look configured, pass a superficial check, and still get filtered.
The records you need
SPF — TXT at your root domain
v=spf1 include:spf.protection.outlook.com -all
Add includes for every other sending tool in this same record. Microsoft's documentation suggests -all; ~all is a gentler starting point while you confirm the list is complete.
DKIM — CNAME at selector1._domainkey
selector1-<domain-key>._domainkey.<tenant>.onmicrosoft.com
The exact target is shown in the Defender portal. Both CNAMEs must exist before you can enable signing.
DKIM — CNAME at selector2._domainkey
selector2-<domain-key>._domainkey.<tenant>.onmicrosoft.com
The second one is how Microsoft rotates keys without your involvement.
DMARC — TXT at _dmarc
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1
Start at none with reporting, then tighten.
Enabling DKIM for your own domain
- 01
Open the Defender portal
security.microsoft.com → Policies & rules → Threat policies → Email authentication settings → DKIM.
- 02
Select your custom domain
Your onmicrosoft.com domain will already show as signing. That is not the one that matters.
- 03
Copy the two CNAME targets
Microsoft shows the exact hostnames and values. If it refuses to enable signing, it's almost always because the CNAMEs aren't published yet or have a typo.
- 04
Publish both CNAMEs at your DNS provider
CNAME records, not TXT. Publishing them as TXT is the single most common mistake here and produces a confusing half-working state.
- 05
Switch signing on
Back in the portal, toggle DKIM signing for the custom domain to enabled. Verify afterwards with a test message to an external provider.
What usually goes wrong on 365
- Signing with onmicrosoft.com only
- DKIM appears healthy, DMARC alignment fails. The fix is enabling DKIM for the custom domain specifically.
- CNAMEs published as TXT records
- The portal keeps refusing to enable signing and the error message is not especially forthcoming.
- Hybrid or relay setups left in SPF
- On-premises Exchange, a mail filter, or an old ISP relay still authorised long after it stopped being used.
- -all published too early
- Microsoft's docs favour a hard fail. Publishing it before you've inventoried every sender means the tools you forgot start failing immediately and definitively.
- Multiple domains, one configured
- Each accepted domain in the tenant needs its own DKIM setup. Aliases and secondary brands are routinely missed.
After it's working
Publish DMARC at p=none with a reporting address, read a few weeks of reports, then move through quarantine to reject. Microsoft's own enforcement, which began in May 2025 for high-volume senders to Outlook.com, requires DMARC to exist — but existing at p=none protects nobody.
Also worth a look while you're in the portal: any transport rules or connectors set up during migration that route mail through a third party. Each one is a sender that needs to be in your SPF record.
Frequently asked
Why two CNAMEs rather than one TXT record like Google?
So Microsoft can rotate your signing keys without asking you to change DNS. The CNAMEs point at Microsoft-controlled records; when they rotate the key behind them, your DNS stays untouched and signing continues. It's a better design, at the cost of one more record.
Do I need DKIM if Microsoft already signs my mail?
Yes, because by default it signs as your onmicrosoft.com domain, which doesn't align with the address your recipients actually see. Alignment is what DMARC checks, so unaligned signing gets you no credit at all.
Should SPF end in -all or ~all?
Microsoft's documentation suggests -all, and it is the stronger setting. Start at ~all while you're confirming every legitimate sender is listed, then tighten. Publishing -all with an incomplete list means the tool you forgot fails hard and immediately.
We're hybrid, with some mail on-premises. Does this change?
The principle is unchanged, but your SPF record must cover your on-premises egress addresses as well as Microsoft's, and DKIM signing needs consideration for mail that doesn't route through Exchange Online. Hybrid setups are where the ten-lookup SPF limit tends to bite.
Find out where your domain actually stands.
The checker reads your real records in a few seconds. The review works out whether they cover everything you send.