Microsoft 365 SPF and DKIM setup

What you are setting up

Microsoft 365 (Exchange Online) sends your mail from Microsoft's servers. SPF authorizes those servers, and DKIM signs each message so the signature aligns with your From: domain. The wrinkle that is unique to Microsoft 365 is what happens if you skip DKIM: Microsoft still signs your outbound mail, but with its own onmicrosoft.comdomain, which does not align. So “I didn't set up DKIM” does not mean unsigned mail, it means misaligned mail that fails DMARC. Getting custom DKIM on is the whole game.

Publish SPF

Add this TXT record at the root of your domain:

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

Microsoft recommends ending with -all (hard fail) for Microsoft 365 domains, on the reasoning that you should also have DKIM and DMARC in place. As always, publish only one SPF record: if you already have one, merge the include:spf.protection.outlook.com into it and watch the ten-lookup ceiling. Our SPF builder handles the merge.

Turn on DKIM

DKIM is enabled in the Microsoft Defender portal (security.microsoft.com), not the old Exchange admin center. Go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM and select your domain.

Microsoft 365 uses two CNAME records rather than a TXT key. The two selectors (selector1 and selector2) exist so Microsoft can rotate keys for you: one is always active, the other waits to take over at the next rotation. The records look like this:

Type:  CNAME
Host:  selector1._domainkey
Value: (copy the exact target shown in the portal)

Type:  CNAME
Host:  selector2._domainkey
Value: (copy the exact target shown in the portal)

Copy the target values from the portal; do not hand-build them. The format changed in 2025. New custom domains get a target ending in .dkim.mail.microsoft; domains set up earlier keep the older ...onmicrosoft.com form. Both are correct, and a guide that hardcodes one shape will send you wrong. The portal (or the Get-DkimSigningConfig PowerShell cmdlet) always shows you the right values for your tenant.

The flow has a deliberately confusing step. On the DKIM page, switch the toggle toward Enabled beforethe CNAMEs exist and you get an error dialog: that error is by design, and it is how Microsoft surfaces the two CNAME values for you to copy. Publish the CNAMEs at your DNS host, wait for them to resolve, then come back and flip the toggle for real. It only succeeds once Microsoft can see the records, moving the status from “no DKIM keys” through “CNAME missing” to signing.

New keys default to 1024-bit; you can move to 2048-bit later by rotating the key. The important thing is that signing is on with your domain.

Add DMARC

DMARC is a standard _dmarc TXT record at your DNS host. Start in monitor-only mode and ramp up once your reports are clean:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Two Microsoft-specific notes. First, your onmicrosoft.com tenant domain can also send mail, so park a record on it too (add v=DMARC1; p=reject;via Microsoft 365 admin center > Settings > Domains, since Microsoft owns that zone). Second, Microsoft 365 sends aggregate (rua) reports but not forensic (ruf) reports, so do not wait on failure samples that will never arrive. Build the record with our DMARC builder and progress past p=none when you are ready.

The Microsoft 365 gotcha

The classic Microsoft 365 failure is passing authentication but failing DMARC on alignment. If custom DKIM is not enabled, Microsoft signs with d=yourtenant.onmicrosoft.com, which does not match a From:address at your real domain, so DMARC fails even though DKIM technically “passed.” The fix is always the same: enable custom-domain DKIM so the signing domain is yours. The same trap catches third-party tools that relay through Microsoft 365 with their own return-path; those need their own aligned DKIM.

Confirm it worked

• Send a test and read the headers. Mail an external address you can inspect, open the original, and confirm the DKIM signature shows d=yourdomain.com (not onmicrosoft.com) and dmarc=pass. Our header analyzer spells it out.
• Re-check the records. A free DMARC audit confirms the SPF record and both DKIM CNAMEs resolve.
• Watch the reports. Microsoft 365 should appear as a passing, aligned source in your DMARC aggregate reports within a day or two. trustyourinbox flags it as a known sender so a misaligned onmicrosoft.com signature stands out immediately.