Microsoft 365 DKIM Not Working? Fix CNAME Setup (2026)

You turned on DKIM in the Microsoft 365 admin portals, but messages from your domain still show DKIM as failing or not present. With Microsoft 365, this almost always comes down to missing or incorrect CNAME records for selector1 and selector2._domainkey, or DKIM not being fully enabled after the DNS records were created.

If signatures fail, check the DKIM selector troubleshooting guide.

Learn the bigger picture in our Email Authentication Explained guide and compare SPF vs DKIM vs DMARC to understand how these protocols work together.

One-Minute Fix

In the Microsoft 365 Defender or Exchange admin center, open the DKIM settings for your custom domain, make sure DKIM is turned on, and create both selector1 and selector2 CNAME records exactly as shown in the portal. Each selector._domainkey hostname must point to the corresponding selector-domain._domainkey.onmicrosoft.com target, and DKIM must be enabled after DNS propagation completes.

Correct Microsoft 365 DKIM records

DNS

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

Microsoft 365 does not expect TXT records for DKIM on your custom domain. Instead, each selector must be a CNAME that points to the matching _domainkey hostname under your onmicrosoft.com domain. Both selector1 and selector2 should be created so that Microsoft can rotate keys cleanly.

Re-check

Wrong vs correct setup

Wrong setup

DNS

selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
selector1._domainkey.example.com CNAME selector1-example._domainkey.onmicrosoft.com

Here only one selector is configured and the first attempt used a TXT record instead of a CNAME. Mixed or duplicate records under the same host confuse resolvers, and with only one selector configured, Microsoft 365 DKIM can still fail or behave unpredictably.

Correct setup

DNS

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

This pattern matches Microsoft’s guidance: both selector1 and selector2 CNAME records are present, each pointing at the correct onmicrosoft.com target. After DNS propagation and enabling DKIM in the admin center, outbound mail from this domain should pass DKIM using one of these selectors.

Why this happens

Microsoft 365’s DKIM implementation is slightly different from many other providers because it uses CNAMEs, not TXT records, on your custom domain. DKIM keeps failing when only one selector is created, when the CNAME target points at the wrong onmicrosoft.com hostname, when DKIM was never actually enabled after DNS was configured, when the domain in the CNAME target does not match the sending domain, or when you test before those CNAMEs have propagated across DNS.

Why this is a problem

Microsoft 365 will continue to send mail even when DKIM is not correctly configured, but receivers see messages that lack a reliable DKIM signal. DMARC policies that depend on DKIM alignment can fail, and business-critical mail such as invoices, meeting invites, and account notifications becomes more likely to land in spam or low-priority folders.

How this affects deliverability

For business domains hosted on Microsoft 365, consistent DKIM is a major part of your reputation story. When DKIM does not work, your messages look more like generic bulk mail from shared infrastructure. That makes it harder for mailbox providers to distinguish trusted line-of-business mail from unwanted traffic, and it can reduce inbox placement over time.

Common causes

The required CNAME records for selector1._domainkey and selector2._domainkey were never added in DNS.
Only one selector CNAME was created, leaving the second selector missing.
The CNAME targets point to the wrong onmicrosoft.com hostname or a different tenant.
DKIM was not actually enabled in the Microsoft 365 Defender or Exchange admin center after DNS was configured.
DNS propagation has not completed yet, so external resolvers still do not see the new CNAME records.

What we checked

We looked up the selector1._domainkey and selector2._domainkey hostnames for your domain and verified whether they return CNAME records pointing at the expected _domainkey hostnames under your onmicrosoft.com domain. If either selector is missing, misdirected, or returns no usable record, Microsoft 365 DKIM will not validate correctly.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

Why does Microsoft 365 use CNAME instead of TXT for DKIM?

Microsoft hosts the actual DKIM keys under the onmicrosoft.com domain and uses CNAMEs on your custom domain to point there. This lets them rotate and manage keys centrally while you only have to maintain the CNAME pointers.

Do I need both selector1 and selector2 records?

Yes. Microsoft 365 recommends configuring both selectors so it can rotate keys without interrupting DKIM. Missing one of the selectors can cause failures or complicate future rotations.

Where do I enable DKIM in Microsoft 365?

You enable DKIM in the Microsoft 365 Defender or Exchange admin center, under the DKIM settings for your custom domain. After the CNAME records are in place and visible, return to that screen and turn DKIM on.

Why is DKIM still failing after I added the CNAME records?

The most common reasons are that the CNAME targets are slightly wrong, that only one selector was created, that DKIM was never enabled in the admin center, or that DNS propagation is still in progress. You can send a test message to an external mailbox, view the message headers, and confirm whether DKIM=pass appears for your domain.

Next steps

Add both selector1._domainkey and selector2._domainkey CNAME records exactly as shown in the Microsoft 365 admin portals.
Wait for DNS propagation and use external DNS tools to confirm both selectors resolve to the correct onmicrosoft.com targets.
In the Microsoft 365 Defender or Exchange admin center, enable DKIM for your custom domain.
Send a test email from a mailbox hosted on Microsoft 365 to an external recipient.
Inspect the message headers and verify that DKIM=pass appears for your domain and that DMARC shows a passing or aligned result.
Review the full troubleshooting guidance in the DKIM Hub.
Explore sender authorization issues in the SPF Hub.
Review alignment and policy issues in the DMARC Hub.