Microsoft 365 DKIM CNAME changes: new selector targets, dynamic partition characters, and CnameMissing troubleshooting

If you set up Microsoft 365 DKIM for a custom domain from muscle memory, there is a good chance the DNS targets you expect are now wrong.

Microsoft updated the DKIM CNAME format for new custom domains in May 2025. The selectors no longer always point to the older selector1-example-com._domainkey.<tenant>.onmicrosoft.com style targets. Newer domains can instead point into Microsoft's dkim.mail.microsoft namespace and include a dynamic partition character that is assigned per domain.

That one change explains a lot of recent CnameMissing confusion. Admins copy an older example, follow an outdated screenshot, or manually construct the target by replacing dots with dashes, and Microsoft 365 keeps saying the CNAME is missing even though a record definitely exists.

Microsoft's current DKIM setup guide documents the new format and explicitly says to use the exact selector values shown by Defender or Exchange Online PowerShell, not hand-built guesses. The official reference is How to use DKIM for email in your custom domain.

The short version

If you want the practical answer first, it is this:

1. do not guess Microsoft 365 DKIM CNAME targets from old examples
2. retrieve the exact Selector1CNAME and Selector2CNAME values for your domain
3. publish both selector CNAME records exactly as shown
4. if Defender says CnameMissing, compare your DNS against the current values, not against an older .onmicrosoft.com pattern

For many tenants, that is the whole fix.

What changed in Microsoft's DKIM CNAME format

Microsoft still uses the same hostnames inside your DNS zone:

• selector1._domainkey
• selector2._domainkey

What changed is the target those CNAMEs point to.

For older Microsoft 365 custom-domain setups, the target often looked like this:

selector1-example-com._domainkey.example.onmicrosoft.com
selector2-example-com._domainkey.example.onmicrosoft.com

For newer custom domains, Microsoft now documents a format like this:

selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft
selector2-example-com._domainkey.example.n-v1.dkim.mail.microsoft

There are three operationally important details in that newer pattern:

1. the target may live under dkim.mail.microsoft, not under your tenant's .onmicrosoft.com name
2. the target includes a single dynamic partition character such as n or r
3. the value is assigned by Microsoft and is not something you should invent yourself

Microsoft's documentation says existing custom domains and initial tenant domains can continue using the older format, while newer custom domains can receive the updated one. So the right mindset is not “what is the Microsoft 365 DKIM format?” It is “what is the DKIM format for this domain in this tenant?”

Why the dynamic partition character matters

The dynamic partition character is the piece that breaks most copy-paste assumptions.

If someone remembers the old structure and tries to upgrade it mentally, the guessed record often ends up close enough to look plausible but still wrong. Example:

guessed:  selector1-example-com._domainkey.example.v1.dkim.mail.microsoft
actual:   selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft

Or the record is published with the old .onmicrosoft.com target because that is what a previous domain used in the same tenant.

That is exactly the sort of mismatch that leaves the domain stuck at CnameMissing.

How to get the correct selector targets

Microsoft gives two supported ways to retrieve the exact values.

In the Defender portal

When you try to enable DKIM for a custom domain that does not yet have working CNAMEs, Defender moves the domain into a CnameMissing state and shows the required values in the details pane under Publish CNAMEs.

That status is not always bad news. It often just means Microsoft has generated the selector targets and is waiting for you to publish them correctly.

In Exchange Online PowerShell

The more precise way is to query the domain directly:

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

Use the Selector1CNAME and Selector2CNAME output exactly as returned.

This is the safest path when:

• old tutorials disagree with the portal
• the domain was added recently and might be using the new format
• you are troubleshooting a stubborn CnameMissing state
• you want to verify whether a subdomain got a different partition character than another domain in the same tenant

What CnameMissing actually means

In Microsoft 365, CnameMissing does not necessarily mean “there is no DNS record at all.”

Operationally, it usually means one of these:

• the required CNAMEs have not been published yet
• one selector exists but the other does not
• the hostname is wrong
• the target value is wrong
• the record type is wrong
• the record exists but Microsoft has not detected it yet

That is why this status frustrates people. It sounds binary, but in practice it often means “the published DNS does not exactly match what Microsoft expects.”

The mistakes that now cause CnameMissing most often

1. Publishing the old selector targets for a new custom domain

This is the new classic failure mode.

The admin uses an older guide showing:

selector1-example-com._domainkey.example.onmicrosoft.com

But the domain actually expects something like:

selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft

The DNS record exists, but it is the wrong destination, so Defender still reports CnameMissing.

2. Manually constructing the target and missing the partition character

The value between your tenant prefix and -v1.dkim.mail.microsoft is not decorative. If Microsoft assigned n, then omitting it or swapping in another character produces the wrong target.

Use the real output from Defender or PowerShell.

3. Keeping dots instead of replacing them with dashes

Microsoft's selector targets flatten the custom domain by replacing periods with dashes.

Correct for mail.example.com:

selector1-mail-example-com._domainkey.example.n-v1.dkim.mail.microsoft

Incorrect:

selector1-mail.example.com._domainkey.example.n-v1.dkim.mail.microsoft

This is easy to miss when the domain is a subdomain rather than a simple apex domain.

4. Publishing only selector1

Microsoft 365 expects both selector records, even though only one is actively signing at a time. The second selector is required for key rotation.

If you want the broader background on why this matters, DKIM selectors and key rotation playbook covers the operational reason both selectors exist.

5. Creating TXT records instead of CNAME records

This is another frequent mismatch when teams are used to providers that publish raw DKIM public keys as TXT records.

For Microsoft 365 custom-domain DKIM, Microsoft manages the keys and expects delegation by CNAME, not a manually published DKIM TXT key.

If DNS answers with a TXT record at selector1._domainkey.example.com, Microsoft 365 will not treat that as a valid DKIM setup for this feature.

6. Entering the hostname in the wrong DNS-provider format

Many DNS control panels want only the left-hand label, not the full FQDN.

So for the hostname field, the correct entry is often:

selector1._domainkey

not:

selector1._domainkey.example.com

If the provider automatically appends the zone name, the second version can become a doubled hostname and silently break the lookup.

7. Not waiting for detection after publishing the records

Even with correct DNS, Microsoft may take some time to detect the new CNAMEs. That delay is less interesting than the format change, but it still matters during troubleshooting.

So before rewriting the record from scratch, verify the current DNS answer first.

A practical CnameMissing troubleshooting flow

This is the fastest order in most real environments.

1. Ask Microsoft what it expects right now

Do not begin in your DNS console.

Start with Defender or PowerShell and capture the exact current values for:

• Selector1CNAME
• Selector2CNAME

If you skip this step, everything that follows is guesswork.

2. Check the record type and left-hand hostname

In your DNS zone for example.com, confirm you created:

selector1._domainkey   CNAME   <Selector1CNAME value from Microsoft>
selector2._domainkey   CNAME   <Selector2CNAME value from Microsoft>

Not TXT. Not A. Not the full hostname duplicated by the provider UI.

3. Compare the target values character by character

This is where the new format bites.

Check all of the following:

• dots in the custom domain became dashes
• the tenant prefix is correct
• the partition character is present and correct
• -v1.dkim.mail.microsoft is present when Microsoft says it should be
• there are no missing underscores or extra periods

This is not a “looks about right” check. It needs to be exact.

4. Confirm DNS resolution externally

Use a normal DNS lookup and confirm the public answer matches the exact target Microsoft gave you.

Example:

selector1._domainkey.example.com -> selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft
selector2._domainkey.example.com -> selector2-example-com._domainkey.example.n-v1.dkim.mail.microsoft

If the public DNS answer differs from the expected values, fix DNS first. If the public DNS answer is correct, wait and retry the enable action.

5. Re-run the Microsoft-side check

After DNS is correct and has had time to propagate, enable DKIM again or refresh the domain state.

Microsoft documents that a successfully detected setup should move from CnameMissing toward a valid signing state once the selectors are found.

Do not assume one domain's target pattern applies to another

This deserves its own warning.

In the same tenant, one older custom domain might still use the old .onmicrosoft.com target style while a newer domain uses the dkim.mail.microsoft style with a partition character. That means internal precedent is no longer enough.

“We did this last year for another domain” is not proof that the same target pattern is still correct today.

That is also why stale runbooks are dangerous here.

Subdomains need their own lookup, too

If you send as news.example.com or billing.example.com, do not assume the apex-domain selector pattern carries over by simple substitution.

Microsoft's documentation says each custom domain or subdomain used for sending needs its own DKIM configuration. In practice that means you should retrieve the selectors for the exact sending domain you are enabling.

If you need the bigger picture around tenant domain versus custom domain handling in Microsoft 365, Microsoft 365 custom domains and .onmicrosoft.com: what SPF, DKIM, and DMARC to publish is the companion read.

Bottom line

The new Microsoft 365 DKIM confusion is not really about DNS being hard. It is about assuming the selector target format is still static when Microsoft has made it per-domain and partly dynamic.

When CnameMissing shows up, the first question should no longer be “Did we create the record?” It should be “Did we publish the exact CNAME target Microsoft currently generated for this domain?”

If you answer that with current Get-DkimSigningConfig output instead of an older screenshot, most of these rollouts get much simpler very quickly.