Microsoft 365

Microsoft 365 DKIM Setup: Why It Sticks at CnameMissing

By Adam W., founder of DMARCit · Updated 2026-10-19

CnameMissing means Microsoft 365 has generated DKIM keys for your custom domain and can't find the two CNAME records that point to them. Until it does, mail from that domain carries a DKIM signature for your tenant's onmicrosoft.com domain instead. That signature verifies at the receiver and does nothing for DMARC, because it doesn't align with the From address your recipients see. Microsoft's own troubleshooting table lists six DNS mistakes behind a broken setup. Three leave the status at CnameMissing and a fourth leaves the record undetected. The other two get past the portal and fail later, which makes them the expensive ones.

What CnameMissing actually means

A custom domain moves through three states on the DKIM tab of the Email authentication settings page in the Defender portal (Email & collaboration > Policies & rules > Threat policies > Email authentication settings, or security.microsoft.com/authentication directly):

• NoDKIMKeys. Nothing generated yet. The domain's flyout says “No DKIM keys saved for this domain” and offers Create DKIM keys.
• CnameMissing. Keys exist, Microsoft has given you the two CNAME values, and it hasn't detected them in your DNS. The toggle still reads Disabled. In the portal you get here by trying the toggle: a Client error dialog opens with the CNAME values in it. In PowerShell you get here with New-DkimSigningConfig -Enabled $false.
• Valid. Records detected and signing on. The portal flyout reads “Signing DKIM signatures for this domain.”

So CnameMissing right after you create the keys is normal. Microsoft says detection takes a few minutes or possibly longer, and that DNS propagation can take up to 48 hours depending on your DNS host and TTL. Its troubleshooting table draws the line there: still CnameMissing after 48 hours means the records are wrong or sitting in the wrong DNS zone. Microsoft calls CNAME detection the main factor in when a custom domain starts signing, which is why every fix below is a DNS fix (Microsoft's DKIM setup guide).

What the two records should look like

Microsoft generates two key pairs for each custom domain and publishes each public key behind a selector. Only one selector signs at a time; the other waits for the next key rotation. You publish one CNAME per selector in your own DNS. The hostnames are the same in every tenant. The targets are not. For custom domains added since May 2025, the format is:

Hostname: selector1._domainkey
Points to: selector1-<domain-with-dashes>._domainkey.<initial-domain-prefix>.<partition-character>-v1.dkim.mail.microsoft

Hostname: selector2._domainkey
Points to: selector2-<domain-with-dashes>._domainkey.<initial-domain-prefix>.<partition-character>-v1.dkim.mail.microsoft

For contoso.com in a tenant whose initial domain is contoso.onmicrosoft.com, Microsoft's illustration is selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft. Three parts of that target are where hand-built records go wrong:

• The domain swaps its dots for dashes: contoso.com becomes contoso-com, and marketing.contoso.com becomes marketing-contoso-com.
• The prefix is only the custom part of your onmicrosoft.com domain: contoso, not contoso.onmicrosoft.com.
• The partition character (the n in n-v1) is assigned by Microsoft when you add the domain and enable DKIM. You can't configure it, and it can differ between domains in the same tenant: Microsoft's own two-domain example has one domain on n-v1 and the other on r-v1.

Domains set up before the May 2025 change keep the older format, with targets that end in your onmicrosoft.com domain, such as selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Microsoft says the two formats can't coexist for the same selector. That is the best argument against building targets from any article, this one included. Copy the values Microsoft gives you for that domain:

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

Microsoft labels every value in its own article as an illustration (syntax for DKIM CNAME records). The ones on this page are illustrations too.

The six DNS mistakes behind a stuck setup

These come from the troubleshooting section of Microsoft's DKIM guide. The table is the quick read; the detail follows.

1. The domain appended twice

Most DNS hosts append your zone to whatever you type in the name field. Type selector1._domainkey.contoso.com into a contoso.com zone at one of them and the record that actually exists is selector1._domainkey.contoso.com.contoso.com. Microsoft names GoDaddy as the example, and its provider table says Cloudflare, Azure DNS, Namecheap, and Google's DNS append the zone too. Enter only selector1._domainkey. The other version of this mistake drops the _domainkey label entirely.

2. Only one of the two records

This one gets past the portal. Microsoft's symptom is that signing enables successfully and key rotation fails later, or the portal warns about an incomplete configuration. Rotation moves signing to the other selector, and without the selector2 record you can't rotate. Microsoft is explicit: create both records even though only one selector is active at a time.

3. A TXT record with a public key in it

Other mail platforms often publish DKIM as a TXT record holding the public key (v=DKIM1; k=rsa; p=...), so the habit is easy to carry over. Microsoft 365 doesn't support it. The CNAME delegates the key to Microsoft so it can manage and rotate keys; a TXT record would make you the key manager, which Microsoft 365 doesn't allow. The status stays CnameMissing and a lookup of selector1._domainkey returns a TXT record. Delete the TXT before you add the CNAME: RFC 1034, Section 3.6.2 says a name that holds a CNAME should hold no other data.

4. A TTL of 60 or 300 seconds

This one never shows in the portal. Microsoft says a very low TTL on the DKIM CNAMEs causes frequent lookups that can time out, which receivers record as dkim=temperror or a key-lookup dkim=fail. Its minimum is 3600 seconds (one hour) on both records. If your aggregate reports show DKIM temperror results on mail from Microsoft 365, check this first.

5. A target built by hand

Microsoft's worked example is the subdomain sub.contoso.com in a tenant whose initial domain is contoso.onmicrosoft.com:

Microsoft also lists a missing partition character among the common errors. If Get-DkimSigningConfig and your DNS disagree by a single character, DNS is the one that is wrong.

6. The trailing dot, and the Cloudflare proxy

Some DNS hosts need a trailing dot on the target to mark it as fully qualified. Others add it for you, and typing one creates a double dot. Route 53 requires it; without it, Route 53 appends your hosted zone to the target. Azure DNS doesn't want one in the portal.

Cloudflare has its own trap. A proxied (orange cloud) CNAME answers with Cloudflare's addresses instead of the Microsoft target, and DKIM verification fails. Set both records to DNS only. Microsoft's summary of the hosts it documents:

Check DNS yourself before you blame the portal

Query public DNS for both names. On Windows:

nslookup -type=CNAME selector1._domainkey.contoso.com
nslookup -type=CNAME selector2._domainkey.contoso.com

On macOS or Linux:

dig CNAME selector1._domainkey.contoso.com +short
dig CNAME selector2._domainkey.contoso.com +short

A good answer names the exact target from Get-DkimSigningConfig. No answer means the record isn't where you think it is: look for the doubled domain, the wrong zone, or a TXT where the CNAME should be. An answer that differs from Microsoft's value by a character is mistake 5.

Once both resolve, turn signing on. In the portal, open the domain's flyout on the DKIM tab and switch on “Sign messages for this domain with DKIM signatures.” In PowerShell:

Set-DkimSigningConfig -Identity contoso.com -Enabled $true

If Microsoft still can't see the records, the cmdlet fails with an error that repeats the CNAME values it expects. Microsoft's advice at that point is to check for typos, which it notes are easy to make with all the dashes, periods, and underscores, then wait and run it again. Success is Enabled: True and Status: Valid.

Prove it with a real message

A Valid status says Microsoft found your records. It doesn't show you a signed message. Send one from the domain to a mailbox outside your organization, such as an Outlook.com or Gmail address, and open the headers. You want two things:

• A DKIM-Signature header with d= set to your domain. Microsoft's example shows d=contoso.com; s=selector1.
• An Authentication-Results header from the receiver showing dkim=pass for your domain.

Two testing mistakes produce false alarms. Sending to someone in the same domain, or to another domain your organization controls, leaves the DKIM signature off entirely; the header reads dkim=none (message not signed), which tells you nothing about outside recipients. And Microsoft advises against testing with AOL, which might skip the DKIM check when SPF passes.

If d= shows your onmicrosoft.com domain instead of your own, custom signing isn't active for that domain yet. That is the fallback the New-DkimSigningConfig reference describes for custom domains without DKIM enabled. Microsoft's header walkthrough is in verify DKIM signing of outbound mail.

Why this decides whether DMARC enforcement is safe

DMARC passes when SPF or DKIM passes with a domain aligned to the From address. Relaxed alignment, the default, means the two share an Organizational Domain (RFC 9989, Section 3.2.10.1).

Before custom signing is on, Microsoft 365 adds a DKIM signature for your onmicrosoft.com domain to custom-domain mail; the New-DkimSigningConfig reference says so directly. The signature is valid. It just isn't yours. In Microsoft's alignment table, From user@contoso.com with contoso.onmicrosoft.com fails relaxed and strict alignment alike.

That leaves SPF as the only aligned identifier. For mail Microsoft 365 delivers directly, that usually holds: Microsoft's table of aggregate-report patterns lists SPF aligned=pass as normal Microsoft 365 mail flow. The trouble starts when the message takes a second hop.

• Forwarding. SPF is checked against the server that connects to the receiver, and after a forward that server is the forwarder's. Microsoft's troubleshooting guide says forwarded messages commonly fail DMARC for exactly this reason. If the forwarder is Exchange Online, it rewrites the envelope sender (Sender Rewriting Scheme) so SPF can pass for the forwarder's domain, and Microsoft says plainly that SRS doesn't fix DMARC, because that domain isn't yours. The reliable path it names is a DKIM signature for the From domain that arrives intact.
• Aliases and relays. RFC 9989 uses alumni forwarders and role addresses as its example: mail relayed through them will most likely fail SPF unless the relay rewrites the envelope sender, while DKIM signatures generally stay valid. It turns that into a requirement: a domain that publishes p=reject MUST NOT rely solely on SPF for a DMARC pass and MUST apply valid DKIM signatures (Section 7.4).

There is a cost on Microsoft's side too. When your policy is p=quarantine or p=reject and a receiving server fails your outbound mail on DMARC, Microsoft 365 routes it through its high-risk delivery pool, and Microsoft says there's no override.

In aggregate reports the gap has a recognizable shape: rows from Microsoft 365 where auth_results shows a passing DKIM result for your onmicrosoft.com domain while policy_evaluated shows dkim=fail. Those rows pass DMARC on SPF today and fail it at the first forward. The walkthrough on how to read a DMARC aggregate report explains those two blocks.

So the order is fixed. Custom DKIM goes on every domain that sends from Microsoft 365 first. DMARC at p=none with a reporting address comes next, and enforcement waits until the reports are clean. The SPF and DMARC records for a tenant are in the Microsoft 365 DMARC setup guide, and the last step is in p=quarantine vs p=reject.

Key size and rotation

New-DkimSigningConfig defaults to a 1024-bit key; 2048 is the other option. RFC 8301, Section 3.2 sets the floor for signers at 1024 bits and says they SHOULD use at least 2048. Microsoft's portal steps don't include a key-size choice, so check what you have:

Get-DkimSigningConfig -Identity contoso.com | Format-List Selector1KeySize,Selector2KeySize,RotateOnDate,SelectorBeforeRotateOnDate,SelectorAfterRotateOnDate

For a domain you haven't configured yet, create it at 2048 from the start:

New-DkimSigningConfig -DomainName contoso.com -Enabled $false -KeySize 2048

For a domain already signing at 1024, rotate:

Rotate-DkimSigningConfig -Identity contoso.com -KeySize 2048

Three things to know before you run it:

• It isn't immediate. The new key starts signing after four days (96 hours). Until then the current key keeps signing, and you can't start another rotation while one is in progress.
• The new size lands on the inactive selector only. After the first rotation completes, run the command again with -KeySize 2048 so the other selector gets a 2048-bit key as well (Rotate-DkimSigningConfig reference).
• Rotation needs signing enabled and a status of Valid or CnameMissing, and it needs the selector2 record from mistake 2. Rotation is where a missing selector2 finally costs you.

Microsoft also notes there is currently no automatic DKIM key rotation for the onmicrosoft.com domain (rotate DKIM keys). For the selector model in general, see What is DKIM?

What Microsoft 365 DKIM does not cover

• Third-party senders. Your CRM, newsletter platform, e-signature service, and billing system send from their own servers, and Microsoft 365's keys never touch that mail. Each one needs its own DKIM setup that signs with your domain, done in that service's settings. Without it, the service's mail passes DKIM for the service's domain and fails DMARC for yours. Microsoft recommends putting services you don't control on a subdomain, such as marketing.contoso.com, so their problems stay off your main domain's reputation (DKIM signing at other email services). The diagnosis is in DMARC alignment failure.
• Your other domains and subdomains. Each accepted domain, and each subdomain you send from in Microsoft 365, needs its own pair of CNAMEs and its own signing config. DKIM working on contoso.com says nothing about contoso.net. Get-AcceptedDomain lists the domains to cover.
• Parked domains. For domains that never send mail, Microsoft's advice runs the other way: publish no DKIM records, so nothing forged under that domain can validate. Cover them with SPF and DMARC instead; the parked-domain records are in the Microsoft 365 DMARC guide.
• Mail that leaves through on-premises servers. Exchange Online signs the mail Exchange Online sends. In a hybrid setup, mail that goes out through your own servers needs its own signing path; the Exchange (on-premises) DMARC guide covers the options.

Microsoft 365 DKIM FAQ

Sources

1. Microsoft Learn: Set up DKIM to sign mail from your cloud domainPortal path and status values, both CNAME formats and the May 2025 change, the six DNS mistakes and the DNS host table, verification steps, the 96-hour rotation, the 2048-bit upgrade note, subdomain, third-party and parked-domain guidance.
2. Microsoft Learn: New-DkimSigningConfigThe 1024-bit default key size, and that custom domains without DKIM enabled get the onmicrosoft.com domain’s signature.
3. Microsoft Learn: Rotate-DkimSigningConfigA 2048-bit upgrade applies to the inactive selector, and the command has to be run again after rotation.
4. Microsoft Learn: Set up DMARC to validate the From address domainThe alignment table (contoso.onmicrosoft.com does not align with contoso.com), SPF aligned as normal Microsoft 365 mail flow, and the high-risk delivery pool for outbound mail that fails DMARC.
5. Microsoft Learn: Sender Rewriting Scheme (SRS) in Microsoft 365SRS does not make forwarded mail pass DMARC; an intact DKIM signature for the From domain does.
6. Microsoft Learn: Troubleshoot email authentication in Microsoft 365Forwarded messages commonly fail DMARC because forwarding breaks SPF.
7. RFC 9989: DMARC, Section 3.2.10.1 (relaxed alignment)Relaxed alignment means the From domain and the authenticated domain share an Organizational Domain.
8. RFC 9989: DMARC, Section 7.4 (interoperability considerations)Domains that publish p=reject MUST NOT rely solely on SPF and MUST apply valid DKIM signatures.
9. RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM, Section 3.2Signers MUST use RSA keys of at least 1024 bits and SHOULD use at least 2048 bits.
10. RFC 1034: Domain Names, Section 3.6.2A name that holds a CNAME record should hold no other data.