← All guides

Fix Microsoft 365 DKIM “CnameMissing” and “No DKIM keys saved”

Microsoft 365 won’t sign mail from your custom domain with DKIM until it can see two CNAME records, selector1._domainkey and selector2._domainkey, in your DNS. Check what your domain publishes below, then fix the record or finish the setup in your tenant.

Last verified 1 October 2026.

What the DKIM statuses mean

The DKIM tab of the Defender portal’s Email authentication settings page, and Get-DkimSigningConfig in Exchange Online PowerShell, show one of these for each domain:

`NoDKIMKeys` “No DKIM keys saved for this domain”	DKIM hasn’t been set up for this domain in your tenant yet: no keys have been created. This is a tenant step, not a DNS problem. Create the keys (steps below); Microsoft then gives you the two CNAME values to publish.
`CnameMissing`	The keys exist, but Microsoft 365 can’t find the two CNAME records it expects in your DNS, so it won’t turn signing on. Either they aren’t published yet, Microsoft hasn’t detected them yet, or they don’t match the values it generated. The checker below tells these apart.
`Valid` “Signing DKIM signatures for this domain”	The CNAMEs were detected. With signing turned on (`Enabled: True` in PowerShell), mail from the domain is DKIM-signed.

When the records can’t be found, turning on signing fails. In the portal a “Client error” dialog opens with the required values; in PowerShell, Set-DkimSigningConfig -Enabled $true returns an error containing the values to use, typically worded like this:

CNAME record does not exist for this config. Please publish the following two CNAME records first.

Until signing is on, mail from your custom domain isn’t DKIM-signed with your domain, so DKIM can’t help it pass DMARC. That matters for 550 5.7.509 and 550 5.7.515 bounces.

Source: Microsoft Learn, Set up DKIM to sign mail from your cloud domain (statuses, record formats, setup steps and troubleshooting; checked 1 October 2026). DKIM itself: RFC 6376.

Check your DKIM CNAMEs

Enter the custom domain shown on Defender’s DKIM tab. The lookups run in your browser against public DNS: both selector names, where their CNAMEs point, whether a key sits behind each target, and the publishing mistakes that cause CnameMissing.

What this can and can’t tell you: it reads the records the domain publishes right now, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails). A lookup that fails shows as “couldn’t check”, never as missing. It can tell whether each target is in one of the two shapes Microsoft documents and carries your domain’s dashed name, but not whether it’s the exact value your tenant generated: the tenant prefix and, in the newer format, the partition character aren’t visible from outside. It can’t see whether signing is turned on. For SPF, DMARC and an A–F grade, use the DMARC checker.

The two records Microsoft 365 expects

Both records are CNAMEs. The hostnames are the same for every Microsoft 365 organisation; the targets depend on your domain and tenant, and come in two formats.

Newer format: custom domains added from May 2025

selector1._domainkey  CNAME  selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft
selector2._domainkey  CNAME  selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

Older format: custom domains set up before then

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

`contoso-com`	Your custom domain or subdomain with dots replaced by dashes: `marketing.contoso.com` becomes `marketing-contoso-com`.
`contoso` (after `._domainkey.`)	The prefix of your initial `*.onmicrosoft.com` domain, which can differ from your domain name. In the newer format it’s the prefix only, without `.onmicrosoft.com`.
`n` in `n-v1`	A partition character Microsoft assigns when you add the domain and enable DKIM (for example `r` or `n`). It’s the same for both selectors, can’t be chosen and can’t be predicted.
`dkim.mail.microsoft`	The parent zone. There’s no `.com` at the end.

Don’t build the values by hand. Copy them from the domain’s details flyout in Defender (the Publish CNAMEs section), or run:

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

Existing domains keep the older format; the two formats can’t both be used for the same selector. Microsoft signs with one selector at a time and switches to the other when keys rotate, so publish both, even though only one is in use. On working domains it’s common for only one of the two targets to have a key behind it at any moment.

Fix it: set up DKIM signing for the domain

The domain must already be added to Microsoft 365. Then:

In the Defender portal

Go to security.microsoft.com/authentication?viewid=DKIM (Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM).
If the status is NoDKIMKeys (“No DKIM keys saved for this domain”; the flyout shows Create DKIM keys): slide the domain’s toggle to Enabled. A Client error dialog with the CNAME values opens; select OK. The status becomes CnameMissing and the toggle stays Disabled, which is expected at this point.
Open the domain’s details flyout (click the row, not the toggle) and copy the two values under Publish CNAMEs.
At your DNS host, create two CNAME records: host selector1._domainkey and selector2._domainkey, pointing to the copied values. Turn off any CDN proxy for them, and use a TTL of an hour (3,600 seconds), as Microsoft recommends.
Check them with the checker above. Microsoft says detection takes a few minutes or possibly longer; DNS changes can take up to 48 hours to reach every resolver.
Back in the flyout, turn on Sign messages for this domain with DKIM signatures. The status should change to “Signing DKIM signatures for this domain”.

In Exchange Online PowerShell

# 1. See every domain's status and the CNAME values
Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

# 2. Domain not listed? Create its keys (signing stays off for now)
New-DkimSigningConfig -DomainName contoso.com -Enabled $false

# 3. Publish Selector1CNAME and Selector2CNAME at your DNS host, wait, then:
Set-DkimSigningConfig -Identity contoso.com -Enabled $true

If the CNAMEs aren’t detected yet, step 3 returns an error containing the values to use: check for typos (dashes, dots and underscores are easy to mix up), wait, and run it again. When it works, Get-DkimSigningConfig shows Enabled: True and Status: Valid. New-DkimSigningConfig creates 1024-bit keys unless you add -KeySize 2048.

The initial *.onmicrosoft.com domain needs none of this: Microsoft 365 signs its mail automatically.

Common mistakes behind CnameMissing

Domain typed into the hostname

Most DNS hosts add your domain to the name you enter. Typing selector1._domainkey.contoso.com creates selector1._domainkey.contoso.com.contoso.com. Enter only selector1._domainkey. The checker looks for this doubled name.

A TXT record instead of a CNAME

Microsoft 365 needs CNAMEs so it can manage and rotate the keys; a key pasted in as a TXT record isn’t supported and the status stays CnameMissing. Delete the TXT and create the CNAME. One caveat: some DNS hosts can flatten CNAMEs and answer lookups with the target’s TXT record, so public DNS shows a TXT with a valid key even though you created a CNAME. If your host’s record list shows a CNAME, turn flattening off for these two names so Microsoft 365 can see it.

Target typed with the wrong pieces

Dots instead of dashes in the domain part: selector1-sub.contoso.com._domainkey… instead of selector1-sub-contoso-com._domainkey….
.onmicrosoft.com in the new format: …contoso.onmicrosoft.com.n-v1.dkim.mail.microsoft instead of …contoso.n-v1.dkim.mail.microsoft.
.com added at the end: …dkim.mail.microsoft.com. The zone is dkim.mail.microsoft.
A guessed or copied partition character or tenant prefix, or the values from another domain in the same tenant: each domain has its own.

Trailing dot

Some hosts treat a target without a trailing dot as a name inside your zone. Route 53 needs the dot (…dkim.mail.microsoft.); without it the record points at …dkim.mail.microsoft.contoso.com. Others add the dot themselves. The checker spots a target with your domain stuck on the end.

CDN proxy on the record

With Cloudflare’s proxy on (orange cloud), lookups return Cloudflare’s IP addresses instead of the CNAME. Set both records to DNS only.

Only one selector, or the wrong zone

Publish both CNAMEs. And make sure you edit the DNS zone that’s actually live: if the domain’s nameservers point somewhere else, records added at your registrar have no effect. Each subdomain that sends mail needs its own pair.

FAQ

My CNAME records are correct. Why does Defender still say CnameMissing?

Microsoft says it takes a few minutes, or possibly longer, for Microsoft 365 to detect new CNAME records, and DNS changes can take up to 48 hours to reach every resolver. Wait, then turn on signing again in the domain’s details flyout. If the status hasn’t changed after 48 hours, compare your records character by character with the Selector1CNAME and Selector2CNAME values from Get-DkimSigningConfig, and check they’re in the DNS zone that is actually live for the domain.

Can I work out the CNAME values myself?

Not reliably. For custom domains added from May 2025, the target includes a partition character that Microsoft assigns per domain (for example r or n in r-v1.dkim.mail.microsoft), and the tenant part is your initial onmicrosoft.com prefix, which can differ from your domain name. Copy both values from the Defender portal or from Get-DkimSigningConfig.

Can I publish the DKIM key as a TXT record instead of a CNAME?

Not for Microsoft 365. Microsoft manages the keys behind the CNAME targets and rotates them, and its documentation lists a TXT record in place of the CNAME as unsupported: the status stays CnameMissing. Some DNS hosts can flatten CNAMEs and answer with the target’s TXT record; if yours does, turn flattening off for these two names so the CNAME is visible.

Why does one of the two selector targets not resolve?

Microsoft 365 signs with one selector at a time and uses the other for key rotation. On working Microsoft 365 domains it’s common for only one target to have a key published at any moment. Both CNAMEs must still exist. Neither target resolving is expected before DKIM keys exist for the domain in your tenant.

The CNAMEs check out. Is my mail DKIM-signed now?

Not necessarily. The CNAMEs are the DNS half. Signing also has to be turned on for the domain in your tenant: Defender should show “Signing DKIM signatures for this domain”, and Get-DkimSigningConfig should show Enabled: True and Status: Valid. To confirm, send a message to an outside mailbox and look for d=yourdomain in the DKIM-Signature header and dkim=pass in Authentication-Results. A message between two addresses in your own organisation isn’t signed, so test with an outside address.

Checking many domains?

If you manage sending domains for clients or brands, Email Security Signals runs DKIM, SPF and DMARC checks on a whole list and returns one row per domain with the DKIM selectors found (Microsoft 365’s selector1 and selector2 among them), the DMARC policy, SPF lookup count and an A–F grade, ready to export as CSV. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.

Check a list on the Apify Store →