If you have set up DKIM for a Microsoft 365 domain recently, you may have hit a frustrating snag: you publish both CNAME records exactly as Microsoft tells you to, you wait for propagation, and then selector1 resolves perfectly — but selector2 stubbornly returns NXDOMAIN. Enabling DKIM in the Defender portal fails with a “CNAME record does not exist” error referencing the second selector.

This isn’t a DNS problem on your side. It’s a provisioning gap on Microsoft’s side, and there’s a one-line fix.

The setup

The DKIM CNAMEs Microsoft 365 asks you to publish look like this:

selector1._domainkey  CNAME  selector1-<domain>._domainkey.<tenant>.<region>.dkim.mail.microsoft
selector2._domainkey  CNAME  selector2-<domain>._domainkey.<tenant>.<region>.dkim.mail.microsoft

Microsoft has been rolling tenants onto a newer DKIM zone (*.p-v1.dkim.mail.microsoft, hosted on Azure DNS) instead of the legacy *.onmicrosoft.com zone. The CNAME pattern is the same — only the target zone changed. And that newer zone is where we have been seeing the selector2 lag.

The symptom

After publishing both CNAMEs correctly at your DNS provider, queries return:

Resolve-DnsName -Name "selector1._domainkey.yourdomain.com" -Type TXT -Server 8.8.8.8
# -> Returns v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG...

Resolve-DnsName -Name "selector2._domainkey.yourdomain.com" -Type TXT -Server 8.8.8.8
# -> DNS name does not exist

The CNAME chain follows through to the Microsoft side, but the target TXT record for selector2 simply is not there yet. Microsoft has generated and published the key for selector1 but not for selector2.

Confirming it is Microsoft’s side

Recursive resolvers cache NXDOMAIN responses for hours, so a missing record at Google or Cloudflare does not necessarily mean it is missing at the source. To rule out caching, query Microsoft’s authoritative nameservers directly.

First, find the authoritative servers for the zone:

Resolve-DnsName -Name "p-v1.dkim.mail.microsoft" -Type NS -Server 8.8.8.8

You will get back four Azure DNS servers (e.g. ns1-83.azure-dns.com, ns2-83.azure-dns.net, etc.). Then query one of them directly:

$ns = (Resolve-DnsName -Name "ns1-83.azure-dns.com" -Type A)[0].IPAddress
Resolve-DnsName -Name "selector2-<domain>._domainkey.<tenant>.p-v1.dkim.mail.microsoft" -Type TXT -Server $ns

If that also returns NXDOMAIN, it is not a caching issue — the key genuinely has not been provisioned in Microsoft’s zone.

The fix: force a key rotation

Microsoft’s DKIM service generates selector1 immediately when a tenant adopts a domain, but selector2 is treated as the rotation slot and is sometimes only populated on the first rotation event. You do not have to wait for it. You can force the issue from Exchange Online PowerShell:

Connect-ExchangeOnline
Rotate-DkimSigningConfig -Identity yourdomain.com

This tells Microsoft’s provisioning system to generate a fresh key pair, which causes both selector1 and selector2 to be (re)published in the zone. Within a few minutes, selector2 will resolve at Microsoft’s authoritative servers, and the CNAME chain from your DNS provider will start returning the key.

If DKIM signing is not enabled yet, you can pair the rotate with the enable:

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName yourdomain.com -Enabled $true
Rotate-DkimSigningConfig -Identity yourdomain.com

The PowerShell New-DkimSigningConfig cmdlet is also more lenient than the Defender portal GUI: the portal pre-checks that both selectors resolve before letting you flip the toggle, while the cmdlet will typically accept the configuration as long as selector1 is valid.

Verifying

After running the rotate, query both selectors against Microsoft’s authoritative DNS to confirm two distinct keys are present:

$ns = (Resolve-DnsName -Name "ns1-83.azure-dns.com" -Type A)[0].IPAddress
Resolve-DnsName -Name "selector1-<domain>._domainkey.<tenant>.p-v1.dkim.mail.microsoft" -Type TXT -Server $ns
Resolve-DnsName -Name "selector2-<domain>._domainkey.<tenant>.p-v1.dkim.mail.microsoft" -Type TXT -Server $ns

Then send a test message from an Exchange Online mailbox to a Gmail address and inspect the original headers. You are looking for:

dkim=pass header.d=yourdomain.com
spf=pass
dmarc=pass

Don’t forget DMARC and SPF alignment

DKIM is one third of the equation. Make sure you also have:

• SPF with include:spf.protection.outlook.com and a single v=spf1 record at the apex (only one SPF record allowed per domain).
• DMARC at _dmarc.yourdomain.com, starting with p=none and a rua reporting address. Run in monitor mode for two to four weeks while you review aggregate reports, then progress to p=quarantine and eventually p=reject.

If you have other senders relaying mail for the domain (security gateways, helpdesk apps, marketing platforms), make sure they are either authorized in SPF and signing with DKIM aligned to your domain, or you will see DMARC failures once you tighten the policy past p=none. For the long version of how SPF, DKIM, and DMARC fit together, see our earlier piece on how email got authenticated.

Bottom line

If you are staring at a selector2._domainkey NXDOMAIN and you have already double-checked the CNAME at your DNS provider, the answer is almost always the same: it is not your DNS — it is Microsoft’s provisioning queue. Rotate-DkimSigningConfig is the lever you want.

If this is one of those projects you would rather not own, drop us a line or call 970-282-8838 and we will get your domain authenticated for you.