Microsoft 365 DKIM error: CNAME record does not exist for this config

You publish the two DKIM CNAME records for a domain in Microsoft 365, check that they resolve, and turn DKIM signing on. Exchange refuses:

CNAME record does not exist for this config. Please publish the following two CNAME records first.
Domain Name : example.com
Host Name : selector1._domainkey
Points to address or value: selector1-example-com._domainkey.yourtenant.y-v1.dkim.mail.microsoft

If the records really are missing or wrong, this message is right. If they resolve correctly from public DNS, it is usually wrong for now: Exchange checks with its own resolver, and that resolver has not seen the new records yet.

What does CNAME record does not exist for this config mean?

It means Exchange looked up selector1._domainkey and selector2._domainkey on your domain and did not find CNAMEs pointing where it expects. Microsoft will not turn on DKIM signing until both selectors resolve to the targets it generated for your domain, so the request is refused rather than enabled half-working.

First, check the records are actually right

Often this error is accurate, so rule that out before waiting. The targets are specific to your domain and your tenant, and building them from an old example is the usual mistake.

• Copy both targets from Microsoft, not from a guide. The Defender portal shows them, and in Exchange Online PowerShell Get-DkimSigningConfig returns them as Selector1CNAME and Selector2CNAME.
• Publish both. Exchange refuses if either selector is missing.
• Use the host names selector1._domainkey and selector2._domainkey. Some DNS providers append the domain themselves, so entering the full name produces selector1._domainkey.example.com.example.com.
• On Cloudflare, set the records to DNS only. A proxied CNAME does not return the target Microsoft is looking for.

Older guides show targets ending in onmicrosoft.com. The targets we were given end in dkim.mail.microsoft, as in the example above. The format depends on when the domain was set up, which is the reason to copy them rather than build them by hand. The DNS records checker shows what both selectors resolve to from outside.

What we measured: the records were right and Exchange still refused

Our provisioning reads both targets from Exchange, writes them exactly, waits until both selectors resolve from public DNS, and only then asks Exchange to enable DKIM. Even in that order, the enable is refused with this message for the first few attempts on a new domain.

Retrying every three minutes, we saw it clear on the third attempt, so within about ten minutes of the records resolving publicly. Nothing was changed between the refusals and the success. The records were the same; Exchange had caught up.

How to fix it, in order

1. Get both targets from Microsoft for this domain.
2. Compare them, character for character, with what your DNS returns for selector1._domainkey and selector2._domainkey.
3. If anything differs, fix the record and wait for it to resolve publicly.
4. If both match, wait a few minutes and try enabling DKIM again. Do not edit records that are already correct.
5. If it still refuses after an hour with matching records, check the TTL on any old records you replaced, since Exchange may be holding the old answer until it expires.

The fourth step is the one people get wrong. Deleting and recreating correct records to refresh them restarts the wait and can briefly leave the selectors resolving to nothing.

Does a domain need DKIM before it sends cold email?

Yes. Without DKIM the domain cannot pass DMARC on DKIM alignment, and Gmail, Yahoo and Microsoft all now expect bulk senders to authenticate. Do not start warm-up on a domain still stuck on this error. SPF, DKIM and DMARC for cold email covers all three records and what each one protects.