Do I still need SPF if DKIM is enabled?

Yes. SPF and DKIM check different things, SPF authorizes sending IPs, DKIM verifies the message signature. DMARC needs at least one of them to pass and align, and having both gives you redundancy when mail is forwarded.

How long does it take for DKIM to start working after I enable it?

Once the two CNAMEs have propagated (typically minutes to a few hours depending on your DNS TTLs), you can enable signing immediately. New messages are signed right away; there is no separate warm-up period.

Why does my mail still show d=onmicrosoft.com instead of my domain?

That means DKIM signing for your custom domain isn't enabled yet, Microsoft is falling back to signing with the tenant's default domain. Add the CNAMEs and toggle signing on for your custom domain to fix the alignment.

How to Enable DKIM in Microsoft 365

VigilDog Team · September 22, 2026 · 6 min read

Microsoft 365 signs mail from your onmicrosoft.com address automatically, but the moment you send from a real custom domain, DKIM is off until you turn it on. Configuring DKIM in Microsoft 365 means publishing two CNAME records and flipping one switch, but the order matters, and a half-finished setup can quietly hurt deliverability. Here is the whole process, the records verbatim, and how to confirm it actually works.

What DKIM does, and why Microsoft 365 leaves it off

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. The receiving server looks up your public key in DNS, verifies the signature, and confirms two things: the message really came from your domain, and its key headers and body were not altered in transit. Alongside SPF, it is one of the two authentication checks that DMARC evaluates.

For your default *tenant*.onmicrosoft.com domain, Microsoft 365 generates and publishes the keys for you, nothing to do. But for a custom domain like contoso.com, Microsoft cannot create DNS records in a zone it does not control. So DKIM signing stays disabled until you add the records and enable it yourself. If you skip this, your mail is signed with the onmicrosoft.com domain instead of your own, which means DKIM won't *align* with your From address and DMARC will treat it as a fail on the DKIM side.

Publish the two CNAME records

Microsoft 365 uses two selectors, selector1 and selector2, so it can rotate keys without downtime (more on that below). Both are CNAMEs that point back into your onmicrosoft.com initial domain, where Microsoft hosts the actual public keys. For a domain contoso.com with the tenant initial domain contoso.onmicrosoft.com, the records are:

Add these at your DNS provider exactly as shown, substituting your own domain (with dots replaced by dashes in the target) and your tenant's onmicrosoft.com name. If your custom domain has a hyphen already, it stays as-is. Do not set a TTL trick or proxy these through a CDN, they must resolve as plain CNAMEs.

Host: selector1._domainkey.contoso.com → Points to: selector1-contoso-com._domainkey.contoso.onmicrosoft.com
Host: selector2._domainkey.contoso.com → Points to: selector2-contoso-com._domainkey.contoso.onmicrosoft.com

Turn on signing in the Defender portal

Once DNS has propagated, enable signing. In the Microsoft Defender portal (security.microsoft.com), go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select your custom domain and switch "Sign messages for this domain with DKIM signatures" to Enabled. If the records haven't propagated yet, the toggle throws a CNAME-not-found error, wait and retry rather than forcing it.

Prefer the command line? Connect to Exchange Online PowerShell and run Enable-DkimSigningConfig -Identity contoso.com -Enabled $true. Check state anytime with Get-DkimSigningConfig -Identity contoso.com | Format-List Enabled,Selector1CNAME,Status. The first time you enable a domain, Microsoft provisions the keys behind those selectors, which is why the CNAMEs must exist first.

How SPF, DKIM and DMARC verify an email

Why there are two selectors: key rotation

The two-selector design is not redundancy for its own sake, it is how Microsoft rotates your signing key without a gap in coverage. At any moment one selector is active and signing mail; the other holds the next key. When a rotation happens (Rotate-DkimSigningConfig -Identity contoso.com -KeySize 2048), signing moves to the standby selector and a fresh key is staged in the one just retired. Because both CNAMEs are always published, receivers can always validate whichever selector signed the message.

Microsoft 365 issues 2048-bit keys on newer tenants; if yours was provisioned years ago on a 1024-bit key, a manual rotation to 2048 is worth doing. Leave both CNAMEs in place permanently, deleting the "inactive" one breaks validation the next time it becomes active.

Verify it, and keep verifying it

Confirm DNS first: dig CNAME selector1._domainkey.contoso.com +short should return the selector1-...onmicrosoft.com target. Then send a message to an external inbox and inspect the raw headers for an Authentication-Results line showing dkim=pass with header.d=contoso.comthe d= value must be your domain, not onmicrosoft.com. That is the difference between DKIM merely passing and DKIM *aligning* for DMARC.

The failure modes here are almost always DNS drift: a registrar migration drops the CNAMEs, someone flattens them into the wrong zone, or a key rotation exposes a record that was quietly removed. Our free DMARC checker will show you at a glance whether SPF, DKIM, and DMARC are all lined up, and the full walkthrough in fix SPF, DKIM, and DMARC covers the alignment details end to end.

DKIM is one of those settings that works perfectly on day one and silently breaks six months later when nobody is looking. Continuous email deliverability monitoring watches those records for you and alerts before a signature failure turns into a spam-folder problem, especially valuable once you start tightening DMARC toward a reject policy.