Microsoft 365 signs mail from your custom domain with DKIM only after you publish two CNAME records and switch signing on. When it won't switch on, the portal shows one of these statuses for the domain:
| Status | Meaning |
|---|---|
No DKIM keys saved for this domain (NoDKIMKeys) |
Microsoft hasn't created keys for the domain yet |
| CnameMissing | keys exist, but Microsoft can't find your two CNAME records |
| Valid | records found; signing can be on |
Trying to enable signing too early gives a "Client error" dialog listing the two CNAME records to publish, and the toggle stays off.
Step 1: create the keys
In the Defender portal go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, select the domain and choose Create DKIM keys.
Or in Exchange Online PowerShell, with a 2048-bit key (the default is 1024):
New-DkimSigningConfig -DomainName example.com -Enabled $false -KeySize 2048
Step 2: get the exact CNAME values
Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
You publish two records, always named selector1._domainkey and
selector2._domainkey. Their targets depend on when the domain was added:
- Domains added since May 2025 use a new format, for example
selector1-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft. The letter before-v1is assigned by Microsoft. - Older domains use
selector1-example-com._domainkey.contoso.onmicrosoft.com.
Copy the values from the portal or PowerShell. Don't build them by hand: a wrong letter, a dot instead of a dash, or the wrong tenant prefix is the most common reason for CnameMissing.
Step 3: publish both records
At your DNS host, add two CNAME records:
selector1._domainkey CNAME <Selector1CNAME value>
selector2._domainkey CNAME <Selector2CNAME value>
The mistakes Microsoft lists most often:
- Domain added twice. Many DNS hosts (GoDaddy and Cloudflare among them)
append your domain to the name for you. Enter
selector1._domainkey, notselector1._domainkey.example.com, or you getselector1._domainkey.example.com.example.com. - Cloudflare proxy on. Set both records to DNS only (grey cloud).
- A TXT record instead of a CNAME.
- Only selector1 published. Both are needed; the second is used when keys rotate.
- A very low TTL. Use 3600 seconds or more.
Check what the internet sees:
dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.com
Each should return the exact target from step 2.
Step 4: enable signing
Microsoft takes a few minutes, sometimes longer, to see new records. Then:
Set-DkimSigningConfig -Identity example.com -Enabled $true
Get-DkimSigningConfig -Identity example.com | Format-List Enabled,Status
Enabled: True and Status: Valid means it's working. Send a message to a
Gmail address and choose Show original: it should show
DKIM: 'PASS' with domain example.com.
Still CnameMissing after 48 hours?
DNS changes can take up to 48 hours to reach everyone. If the status hasn't
changed by then, the records are wrong or in the wrong place: check the
names, check the targets character by character, and check you edited the
DNS zone that's actually live (dig +short NS example.com shows which
provider answers). Each subdomain that sends mail needs its own pair of
records.
If the records are right and the toggle still flips back to off, open a ticket with Microsoft support.
Rotating keys later
Microsoft doesn't rotate keys for you. To rotate (and move to 2048 bits):
Rotate-DkimSigningConfig -Identity example.com -KeySize 2048
The new key starts signing after four days, and you can't rotate again during that time.
Next: DMARC
DKIM on its own doesn't stop anyone spoofing your domain. Once DKIM and SPF pass, publish DMARC and move it to enforcement: see DMARC from none to reject. For other senders than Microsoft 365, see set up DKIM.
Check your domain
The DMARC checker shows whether your domain can be spoofed today. The free scan checks SPF, DMARC and the lookalike domains that could send email as you.