Table of Contents
- Did Microsoft 365 Quietly Update Its DKIM CNAME Records — and Is It Breaking Your Email Deliverability?
- Microsoft 365 DKIM Misconfiguration: What Administrators Need to Know
- What Happened
- Why DKIM Matters for Your Clients
- How to Diagnose and Fix It
- Key Actions for Administrators
- Is This an Isolated Incident?
Did Microsoft 365 Quietly Update Its DKIM CNAME Records — and Is It Breaking Your Email Deliverability?
Microsoft 365 DKIM Misconfiguration: What Administrators Need to Know
A growing concern has surfaced among Microsoft 365 administrators: an invalid DKIM entry appearing under dkim.mail.microsoft, triggered by what appears to be an undocumented change to Microsoft’s CNAME record requirements. If you manage Exchange Online environments for multiple clients, this issue may already be affecting your email deliverability without any obvious warning.
What Happened
On February 18, 2026, IT service provider Maximilian S. reported that Microsoft 365 began displaying a DKIM error within the domain control panel across several client tenants. The invalid entry under dkim.mail.microsoft was generating DNS-related error messages — not because of anything the administrator changed, but because Microsoft appears to have quietly revised its required CNAME records for DKIM signing.
This kind of silent infrastructure change is not unprecedented. Microsoft 365 uses two CNAME-based selectors — selector1 and selector2 — to authenticate outbound email via DKIM. When those records point to outdated or revised targets, DKIM validation fails at the receiving end, and emails risk being flagged as spam or rejected entirely.
Why DKIM Matters for Your Clients
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outbound email, allowing receiving mail servers to verify the message hasn’t been tampered with in transit. Without a valid DKIM configuration, your clients’ emails fail authentication checks, which directly harms sender reputation and inbox placement rates.
When Microsoft signs emails with onmicrosoft.com instead of a custom domain, it typically means DKIM hasn’t been fully enabled — or that the underlying CNAME records are no longer aligned with Microsoft’s current infrastructure. The error “CNAME record doesn’t exist for this config” is the most common symptom administrators see in the Microsoft 365 Defender portal.
How to Diagnose and Fix It
Start in the Microsoft 365 Defender portal under Email & Collaboration → Policies & Rules → Threat Policies → DKIM. Check whether the DKIM status for each custom domain reads “Signing” or shows an error.
Then verify your CNAME records at your DNS registrar match exactly what Microsoft currently requires. Even a single misplaced character — or a duplicated domain name in the hostname (e.g., selector1._domainkey.yourdomain.com.yourdomain.com) — will cause the configuration to fail. Use MXToolbox or the Microsoft 365 Message Header Analyzer to confirm your selectors are resolving correctly.
If the records look correct but the error persists, a DKIM reset via PowerShell often resolves the issue:
Connect-ExchangeOnline Set-DkimSigningConfig -Identity yourdomain.com -Enabled $false Start-Sleep -Seconds 30 Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true Allow up to one hour for the changes to propagate, then recheck the Defender portal.
Key Actions for Administrators
- Audit all managed tenants — check DKIM status in the Defender portal for every custom domain
- Revalidate CNAME records against Microsoft’s current required values, not cached or previously documented ones
- Disable proxy on Cloudflare for DKIM CNAME records, as proxied records break DKIM resolution
- Rotate DKIM keys using Rotate-DkimSigningConfig if key sync issues are suspected
- Monitor email headers post-fix to confirm dkim=pass appears in authentication results
Is This an Isolated Incident?
Given that Maximilian manages multiple client tenants and observed the same error across all of them, this is almost certainly not an isolated case. Microsoft’s automatic DKIM key rotation mechanism is known to occasionally fall out of sync between private signing keys and public DNS records — producing errors like “DKIM body hash did not verify” or “bad signature” across affected environments.
If you are managing Microsoft 365 tenants and have recently seen DKIM errors you didn’t introduce yourself, it is worth verifying whether Microsoft’s current CNAME targets have changed from what you originally configured. Sharing your findings with the administrator community helps others identify and resolve the same problem faster.