How do you fix the Microsoft 365 DKIM CNAME record error?

You go to turn on DKIM for a custom domain in Microsoft 365 and it refuses: an error dialog full of record values, and a status of CnameMissing that won't go away. The cause is almost always in DNS, not in Microsoft 365. This guide starts from what you see, lists the causes in the order we'd check them, and gives the fix for each. If you haven't set DKIM up yet, start with our DKIM setup guide for Microsoft 365 and Google Workspace.

What does the Microsoft 365 DKIM CNAME error look like?

The error means Microsoft 365 looked up your two DKIM CNAME records and didn't find the values it expects. Where you see it depends on where you tried to enable signing.

In the Defender portal (Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, or https://security.microsoft.com/authentication), Microsoft documents that sliding the toggle opens a Client error dialog. Microsoft says the error "contains the required values to use in the two CNAME records you create at the domain registrar for the domain along with a lot of other text." You don't need to copy it: the same values are easier to read in the domain's details flyout, or in PowerShell (see below). Back on the DKIM tab, the domain's Status changes to CnameMissing and the toggle stays Disabled.

The status values you can see come from Microsoft Learn:

In Exchange Online PowerShell, Set-DkimSigningConfig -Identity example.com -Enabled $true fails with an error that contains the values to use. Microsoft's advice there is blunt: "Check for typos in the values at the domain registrar (easy to do with the dashes, periods, and underlines!), wait a while longer, and then run the command again."

What causes CnameMissing, most likely first?

Work down this list. Most domains are fixed by one of the first three.

1. The records are new and haven't been detected yet. Microsoft says detection takes "a few minutes (or possibly longer)", and that DNS propagation can take from a few minutes to 48 hours depending on the provider and TTL.
2. The host name has the domain twice. Many DNS hosts append your domain automatically. Enter selector1._domainkey.example.com there and the record really lives at selector1._domainkey.example.com.example.com. Microsoft names GoDaddy as one host that does this.
3. The target was typed or built by hand. Common slips: dots kept instead of dashes (example.com must become example-com), the whole onmicrosoft.com name used instead of just its prefix, or the partition letter left out.
4. The record is in the wrong DNS zone. You edited the zone at your registrar, but your name servers point somewhere else, such as Cloudflare or your web host. Microsoft's table for a status still stuck after 48 hours says the records "are incorrect or in the wrong zone."
5. A TXT record (or another record) sits at the same name. Microsoft calls a TXT key at selector1._domainkey a mistake that keeps the status at CnameMissing. DNS also forbids mixing: RFC 1034 says "If a CNAME RR is present at a node, no other data should be present", so most hosts won't save the CNAME until you delete the old record.
6. Only one selector was created. Microsoft requires both. Without selector2, key rotation fails, and Microsoft says the portal may warn about an incomplete configuration.
7. A trailing dot problem. Some hosts need a trailing dot on the target to treat it as a full name. Others add it, and an extra one corrupts the value.
8. Cloudflare proxy is on. Microsoft tells Cloudflare users to set DKIM CNAMEs to DNS only (grey cloud), because a proxied CNAME returns Cloudflare's addresses instead of the target.

Old and new target formats

Microsoft changed the target format for new custom domains in May 2025:

<prefix> is the custom part of your initial onmicrosoft.com domain, and <x> is a letter Microsoft assigns, such as n or r. Microsoft says "the old and new formats can't coexist for the same selector." A record copied from an old blog post or another tenant will resolve and still be wrong. Use what your tenant shows.

How do you check the records Microsoft expects?

Ask Microsoft 365, then ask DNS, and compare.

1. Get the expected values. In Exchange Online PowerShell, run:

   Get-DkimSigningConfig -Identity example.com |
     Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
   

   If the domain isn't listed at all, create the configuration first with New-DkimSigningConfig -DomainName example.com -Enabled $false. Its default key size is 1024 bits; add -KeySize 2048 for a 2048-bit key.

2. Query public DNS. On Windows, nslookup -type=CNAME selector1._domainkey.example.com. On macOS or Linux:

   dig CNAME selector1._domainkey.example.com +short
   dig CNAME selector2._domainkey.example.com +short
   

   A correct answer (example) is a single line such as selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft.

3. Compare character by character. The DNS answer must match Selector1CNAME and Selector2CNAME, apart from a final dot.

4. Read what's wrong from the answer:

Our DKIM Checker shows the same thing from outside your network. Enter your domain and selector1, then selector2.

How do you fix it and turn DKIM signing on?

Once DNS returns the right answer for both selectors:

1. Set both CNAMEs to the exact values, with a TTL of at least 3600 seconds. Microsoft lists TTLs as low as 60 or 300 seconds as a cause of intermittent dkim=temperror results at receivers.
2. Wait until both names resolve at public resolvers, not just at your DNS host's own preview.
3. Return to the domain's flyout on the DKIM tab and select Sign messages for this domain with DKIM signatures, or run Set-DkimSigningConfig -Identity example.com -Enabled $true. Microsoft notes: "It may take several minutes to synchronize the status change."
4. Confirm the status is Signing DKIM signatures for this domain (portal) or Valid (PowerShell).
5. Send a test message to a mailbox at another provider and check dkim=pass with header.d=example.com in the Email Header Analyzer.

If the toggle flips straight back to Disabled while the records are correct, Microsoft lists that as rare and says to contact Microsoft Support with the output of Get-DkimSigningConfig -Identity example.com.

How do common DNS hosts handle the host field?

These entries follow the DNS provider summary table in Microsoft's DKIM article at the time of writing (October 2026). Host control panels change, so check your host's current help page if a field looks different. When in doubt, create the record, then query it with dig before you go back to Microsoft 365.

Why does DKIM still fail after the status says Valid?

A Valid status means Microsoft can sign. It doesn't guarantee every message passes DKIM and DMARC. Microsoft's own troubleshooting table lists three follow-on problems:

• DKIM passes but DMARC fails. The d= domain doesn't align with the From domain, usually because mail comes from a subdomain or another domain with no DKIM configuration of its own. Each sending domain and subdomain needs its own pair of CNAMEs.
• DKIM works for one domain but not another. Same cause: every domain in the tenant has its own records.
• DKIM fails after forwarding. Something modified the message on the way. See why DKIM body hash verification fails.

Before you enforce DMARC, check that your custom domain, not onmicrosoft.com, is the signing domain. Our DMARC setup guide for Microsoft 365 covers the rest.

Next steps

1. Run Get-DkimSigningConfig and list every domain still at NoDKIMKeys or CnameMissing.
2. For each one, query both selectors with the DKIM Checker and fix the record using the table above.
3. Enable signing, confirm Valid, and send a test to an outside mailbox.
4. Rotate any 1024-bit key to 2048 bits with Rotate-DkimSigningConfig -KeySize 2048, as covered in DKIM key rotation.
5. Check the provider-specific record format on our Microsoft 365 DKIM page.

If you're also putting filtering in front of Microsoft 365, our Microsoft 365 platform page explains how iBlockSpam's guided setup fits alongside DKIM. Browse our other SPF, DKIM and DMARC guides.