Microsoft 365 SPF and DKIM setup

What you are setting up

Microsoft 365 (Exchange Online) sends your mail from Microsoft's servers. SPF lists those servers as allowed to send for your domain, and DKIM signs each message so the signature aligns with your From: domain. The wrinkle: Microsoft signs mail from your tenant's own onmicrosoft.com domain automatically, but for a custom domain its documentation is explicit that no DKIM signing happens until you turn it on. Until then your DMARC pass rests on SPF alone, which breaks the moment a message is forwarded, and any onmicrosoft.com signature you do see on a message does not align with your domain. 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. Two things have to be true before you start: you need an admin role that can manage the Email authentication settings in that portal, and the domain has to be added and verified in Microsoft 365 already, or it will not appear in the DKIM list at all. With those in place, 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 May 2025. New custom domains get a target ending in -v1.dkim.mail.microsoft, with a partition character Microsoft assigns; domains set up earlier keep the older selector1-yourdomain-com._domainkey.yourtenant.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 before the 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. A signature with d=yourtenant.onmicrosoft.com does not match a From: address at your real domain, so DMARC gets nothing from DKIM even though the signature itself verified, and the moment SPF fails too (a forward, a relay, a third-party tool with its own return-path) the message fails outright. 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.