Microsoft 365 DKIM Setup: Two CNAMEs, the New Format, Tested

To set up DKIM for a custom domain in Microsoft 365, open the Defender portal at Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, get the two CNAME values for the domain, publish both selector1._domainkey and selector2._domainkey at your DNS host, then switch on Sign messages for this domain with DKIM signatures. Copy the CNAME targets exactly, because the format changed for domains added since May 2025.

The steps below follow Microsoft's How to use DKIM for email in your custom domain, read on 6 October 2026. Rotation is a separate job, covered in DKIM key length and rotation.

Why you have to do this at all

Microsoft 365 signs mail from your onmicrosoft.com domain automatically, but not mail from your own domain. Microsoft's page says that for custom domains, "Currently, no DKIM signing occurs for outbound mail from custom domains". It adds that DKIM "passes DMARC validation only if the domain that DKIM signed the message and the domain in the From address align."

So until you finish this setup, mail from you@yourcompany.com has no DKIM signature your DMARC record can use. Its DMARC result depends on SPF alone, and SPF breaks when mail is forwarded. Microsoft's own requirements for high-volume senders to Outlook.com, and Gmail's, both expect DKIM in place.

The two CNAME records, and the format change

Microsoft 365 uses two CNAME records that point at keys Microsoft hosts, not a TXT record you paste. Only one selector signs at a time; the other is held for key rotation. Both must exist.

For custom domains added since May 2025, Microsoft documents this format:

Hostname: selector1._domainkey
Points to: selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

Hostname: selector2._domainkey
Points to: selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

Placeholder	Meaning	Example for contoso.com in tenant contoso.onmicrosoft.com
CustomDomainWithDashes	Your domain with dots replaced by dashes	contoso-com
InitialDomainPrefix	The part of your onmicrosoft.com domain before .onmicrosoft.com	contoso
DynamicPartitionCharacter	A character Microsoft assigns, "for example, r or n"	n

That gives a target such as selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft.

Microsoft says "Existing custom domains and initial domains continue to use the old DKIM format", which points at your onmicrosoft.com domain instead:

selector1-contoso-com._domainkey.contoso.onmicrosoft.com

You can see the old format on Microsoft's own domain. On 6 October 2026, dig CNAME selector1._domainkey.microsoft.com returned selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com, and github.com, which Microsoft owns, returned selector1-github-com._domainkey.microsoft.onmicrosoft.com.

Microsoft also warns that "The old and new formats can't coexist for the same selector", and that the partition character is assigned by Microsoft and "isn't configurable". Do not build the values yourself. Take them from the portal or PowerShell.

Setup in the Defender portal

The portal route makes you trigger an error first, which is how it generates the keys and shows you the CNAME values. The domain needs to show Status: NoDKIMKeys and Toggle: Disabled on the DKIM tab before you start.

1. Go to security.microsoft.com/authentication (or Email & collaboration > Policies & rules > Threat policies > Email authentication settings) and open the DKIM tab.
2. In the row for your domain, try to slide the toggle to Enabled. A Client error dialog opens containing the CNAME values. Select OK.
3. The status is now CnameMissing. Click the row to open the details flyout, and copy the two values under Publish CNAMEs.
4. At your DNS host, create both CNAME records.
5. Return to the flyout and switch on Sign messages for this domain with DKIM signatures. If the records are found, the status changes to Signing DKIM signatures for this domain.

Microsoft says it "takes a few minutes (or possibly longer)" for the new CNAMEs to be detected. If the toggle refuses, wait and try again before changing anything.

Setup with Exchange Online PowerShell

PowerShell does the same thing in three commands, and lets you choose a 2048-bit key up front. After you connect to Exchange Online PowerShell:

# Create the keys without enabling signing. KeySize defaults to 1024.
New-DkimSigningConfig -DomainName contoso.com -Enabled $false -KeySize 2048

# Read the exact CNAME targets to publish.
Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

# After both CNAMEs are published and detected:
Set-DkimSigningConfig -Identity contoso.com -Enabled $true

Microsoft's documentation lists 1024 as the default for -KeySize, with 2048 as the other option. Gmail's sender guidelines accept 1024 and recommend 2048, so there is no reason not to choose 2048 at creation.

The mistakes behind CnameMissing

If the status stays at CnameMissing, one of five things is almost always wrong. These come from the troubleshooting section of Microsoft's page:

Mistake	Fix
Host name includes the domain, so the record lands at selector1._domainkey.contoso.com.contoso.com	Enter only selector1._domainkey if your DNS host adds the zone
Only selector1 created	Create selector2 too. Without it, key rotation fails later
A TXT record with v=DKIM1; p=... instead of a CNAME	Delete it and create the CNAME. Microsoft says TXT is "not supported" for Microsoft 365
Target built by hand: dots kept, .onmicrosoft.com included, or partition character missing	Copy the values from Get-DkimSigningConfig
Very low TTL, causing intermittent dkim=temperror	Microsoft recommends at least 3600 seconds

Check the records yourself with dig +short CNAME selector1._domainkey.yourdomain.com (and the same for selector2), or with the DKIM checker using selector selector1 or selector2. In our lookup of microsoft.com on 6 October 2026, both CNAMEs resolved but only selector2 returned a public key, which fits Microsoft's description of one active selector at a time. Do not read a missing key on one selector as a fault on its own.

Check a real message

Send from a Microsoft 365 mailbox to an outside address and read the headers. Microsoft says to wait a few minutes after any DKIM change before testing, and not to use AOL, which "might skip the DKIM check if the SPF check passes."

In the received message, the DKIM-Signature header should show d= as your domain and s=selector1 or s=selector2. The Authentication-Results header should include dkim=pass for that domain. Microsoft notes that mail between addresses in the same organisation is not signed, so a test to a colleague will show dkim=none (message not signed) even when setup is correct. Our guide to reading email headers explains the rest of the block.

Subdomains and third-party senders

Each domain and subdomain that sends from Microsoft 365 needs its own DKIM configuration, and services outside Microsoft need theirs too. Microsoft's page says "Each subdomain you use to send email from Microsoft 365 requires its own DKIM configuration." For bulk mailing services and other systems you do not control, it recommends sending from a subdomain such as marketing.contoso.com, so their problems do not affect your main domain's reputation.

Those services sign with their own keys, published under their own selectors in your DNS. For DMARC to pass, the d= in their signature must match your From domain, as in Microsoft's example of From: sender@marketing.contoso.com with d=marketing.contoso.com. A service signing only as itself will show dkim=pass and still fail DMARC alignment.

Microsoft also advises against publishing DKIM records for parked domains that never send mail. Once every sender is signing as your domain, you can start moving DMARC from p=none to p=reject.

Practical checklist

1. Open the DKIM tab at security.microsoft.com/authentication, or use PowerShell.
2. Generate the keys (2048-bit if you use PowerShell) and copy both CNAME targets exactly.
3. Publish selector1._domainkey and selector2._domainkey as CNAMEs, with no doubled domain and a TTL of at least an hour.
4. Enable signing once Microsoft detects the records.
5. Test with an outside recipient and confirm dkim=pass with your domain in d=.
6. Repeat for every subdomain and third-party sender, then tighten DMARC.

The deliverability audit checks MX, SPF, DKIM, DMARC and blocklist status for a domain in one pass, which is a quick way to confirm nothing else is missing.