Microsoft 365 DKIM: "CNAME record does not exist for this config" and how to fix it

You open Defender, go to the DKIM settings for your domain, flip the toggle, and get CNAME record does not exist for this config. The records look right in your DNS panel, so what is going on?

What Microsoft is looking for

Microsoft 365 signs with two selectors, and each one must be a CNAME in your zone:

selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.example.com  CNAME  selector2-example-com._domainkey.<tenant>.onmicrosoft.com

The target uses your domain with dots turned into dashes, and <tenant> is the initial .onmicrosoft.com name of your tenant, not your custom domain. Copy both values from the Defender page instead of typing them. One wrong character and the toggle will keep failing.

The usual causes, in the order I check them

1. The DNS host appended your domain. Many panels add the zone name automatically. If you entered selector1._domainkey.example.com in the Name field, the record may really be selector1._domainkey.example.com.example.com. Enter only selector1._domainkey.
2. The target got mangled. Some panels strip the trailing dot, or add one, or lowercase things badly. Compare what is published against what Defender shows.
3. Only one selector exists. Both selectors have to resolve before you can enable signing.
4. Proxying or flattening. In Cloudflare, DKIM CNAMEs must be DNS only (grey cloud). A proxied record answers with Cloudflare addresses instead of the CNAME target.
5. Propagation. A new record can take a while, and a negative answer can be cached for the zone's negative TTL. If everything else is correct, wait and retry.

Check it from outside

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

Each query should print the .onmicrosoft.com target. An empty answer means the record is not where you think it is. Then turn signing on in Defender and send a message to an external mailbox. In the headers you want dkim=pass header.d=example.com. If it says header.d=yourtenant.onmicrosoft.com, signing is on but not aligned with your From domain, which will matter once DMARC is enforcing.

Why this keeps coming back

DKIM is not something you set up once. Key rotation, a DNS migration, or someone cleaning up "weird" CNAMEs can quietly break signing months later, and nothing alerts you until mail starts landing in spam. Re-run the two dig commands and read a real message's headers whenever DNS changes, and on a schedule even when it does not.