Microsoft 365 DKIM setup: selector1, selector2 and the CNAME records

Out of the box, Microsoft 365 signs outgoing mail with the tenant's onmicrosoft.com domain. That signature is valid, but it does not align with the client's own domain, so it does nothing for DMARC. Turning on DKIM for each custom domain fixes that. It takes about 15 minutes per domain.

Before you start

• An admin role that can manage email authentication (Security Administrator or Global Administrator).
• Access to the domain's DNS.
• The custom domain already added and verified in Microsoft 365.

Step 1: get the two CNAME values

In the Microsoft Defender portal, go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings and open the DKIM tab. Select the domain. If no keys exist yet, the portal offers to create them and then shows two CNAME records:

selector1._domainkey.example.com  CNAME  <value shown in the portal> selector2._domainkey.example.com  CNAME  <value shown in the portal>

Copy the targets exactly from the portal. Their format depends on when the tenant was set up: older tenants point at a host under onmicrosoft.com, newer ones at a Microsoft-managed host under dkim.mail.microsoft. Guessing the format is the most common reason this fails.

The same values are available in Exchange Online PowerShell with Get-DkimSigningConfig -Identity example.com | Format-List Selector1CNAME, Selector2CNAME.

Step 2: publish both records

Add both CNAMEs at the DNS host. Two details catch people out:

• Many DNS panels append the domain automatically, so the host field is just selector1._domainkey, not the full name.
• On Cloudflare, CNAME records for DKIM must be DNS only (grey cloud), not proxied.

Step 3: enable signing

Back on the DKIM tab, switch on Sign messages for this domain with DKIM signatures. If the portal reports that the CNAME records are not found, give DNS a little longer and retry. In PowerShell: Set-DkimSigningConfig -Identity example.com -Enabled $true.

Step 4: verify

1. Send a message from the domain to a Gmail or Outlook.com address.
2. Open the original message and find Authentication-Results. You want dkim=pass header.d=example.com, the custom domain, not onmicrosoft.com.
3. Check that dmarc=pass appears too.

A free Hookgap check also looks for selector1 and selector2 when it detects Microsoft 365 MX records, and reports DKIM as found.

Common problems

• "CNAME record does not exist": a typo in the host name, the domain added twice by the DNS panel, or the record still propagating.
• Only one selector published: signing may work today and break at the next key rotation. Publish both.
• Several domains in the tenant: each custom domain, including ones used only for aliases, needs its own pair of records and its own toggle.
• Other senders: this covers mail sent through Exchange Online only. CRMs, newsletters and invoicing tools need their own DKIM. Find them in DMARC aggregate reports.

What comes next

With aligned DKIM in place for Microsoft 365, the client is ready for a DMARC rollout: the complete guide has the plan. For encrypted delivery to the domain, see MTA-STS for Microsoft 365.