Microsoft 365 DKIM setup

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

If Microsoft 365 says a DKIM CNAME record does not exist, compare the public CNAME with the exact values issued for that custom domain. A target copied from another tenant, an old example or a guessed onmicrosoft.com name is not safe to publish.

Problem description

Microsoft 365 reports the following configuration error:

CNAME record does not exist for this config.

Run this automated test on my domain

Enter your domain. MailFixIt checks the relevant DNS records automatically and shows the evidence.

Required input: copy the selector1 and selector2 CNAME owners and targets from the Microsoft Defender portal or Get-DkimSigningConfig. MailFixIt does not generate targets from a tenant name.

Why the CNAME can look correct but fail

The owner was entered in the DNS panel with the domain appended twice.
The owner exists but points at a different target than the value issued for this domain.
Only one selector was added, or a record from another custom domain was reused.
The DNS host is different from the registrar where the record was edited.
Microsoft 365 has not refreshed its DNS view yet after a correct record was published.

Safe comparison workflow

In Microsoft 365, copy, rather than infer, the CNAME values for the exact custom domain or subdomain.
Run the comparison with each selector1._domainkey or selector2._domainkey owner and its issued CNAME target.
If the checker reports mismatch, preserve the existing record for rollback and correct only the intended CNAME owner or target.
If it reports duplicate owner, the provider may have appended the zone name twice; recreate it with the DNS host's documented relative/FQDN syntax.
When both records match, return to Microsoft 365, refresh status and enable DKIM signing. Send a new message to confirm the actual signature.

Do not guess the target

Microsoft 365 documents both an older format and a newer format with a dynamic partition value. The portal or PowerShell output for your tenant is the source of truth. A syntactically plausible CNAME is not necessarily the one Microsoft 365 expects.

What this check proves

The free check distinguishes a matching public CNAME, a mismatch, absence, a likely duplicated owner and a transient DNS result. It does not prove that Microsoft 365 has enabled signing, that a message has a valid DKIM signature or that every recipient will accept it.

Official reference: Microsoft: configure DKIM for custom domains.

Frequently asked questions

What Microsoft 365 DKIM CNAME records should I create?

Use the exact selector1 and selector2 CNAME values shown in the Microsoft Defender portal or returned by Get-DkimSigningConfig for the specific custom domain. Do not derive a target from examples or a guessed tenant name.

Can old and new Microsoft 365 DKIM CNAME formats both be valid?

Yes. Microsoft documents a newer dynamic-partition format for newer custom domains while existing domains can use the older format. The tenant-issued value is the authoritative value for the domain being configured.

Does a public CNAME prove Microsoft 365 is signing messages?

No. It proves only that the public DNS value matches the supplied target. Enable signing in Microsoft 365 and confirm a fresh message header separately.

Related email diagnostics

Outlook 550 5.7.515: Access denied, sending domain does not meet the required authentication levelDiagnose Outlook 550 5.7.515 email rejection safely. Check SPF, DKIM and DMARC DNS, interpret the receiver report, and identify the next configuration step. DNS record not detected after saving the provider-issued valueDiagnose a DNS record that is not detected after saving it. Compare the exact TXT, CNAME or MX value, identify a duplicated hostname, and avoid unsafe DNS changes.

Primary sources: Microsoft 365 DKIM configuration.