Enabling DKIM on Microsoft 365: the step-by-step guide

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName example.com -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity example.com |
  Format-List Selector1CNAME, Selector2CNAME

The two CNAMEs: selector1 and selector2

The values follow a predictable pattern. For example.com in the contoso tenant, the two records to publish are:

selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.example.com  CNAME  selector2-example-com._domainkey.contoso.onmicrosoft.com

The example-com segment is the custom domain with its dots turned into dashes; contoso.onmicrosoft.com is the tenant's initial domain. The console displays these values verbatim — there is no reason to rebuild them by hand, but knowing the pattern makes a typo visible at first glance.

Two design choices deserve a word. First, why a CNAME rather than a TXT: the public key is not published in the domain's zone; it stays hosted at Microsoft, at the far end of the alias. That indirection is precisely what will later allow key rotation without any DNS intervention. Second, why two selectors: selector1 and selector2 take turns — one signs while the other waits for the next rotation. The exact role a selector plays in a DKIM signature, and how to observe it in message headers, is dissected in the DKIM selector explained.

This design sets Microsoft 365 apart from the generic process, in which the administrator generates the key pair and publishes the public key as a TXT record — the approach described in how to generate a DKIM key. Here, the private key never leaves Microsoft's infrastructure: less freedom, but also fewer opportunities to compromise it.

DNS publication and its classic traps

On paper, publishing two CNAMEs takes three minutes. In practice, four traps come up again and again.

The CNAME entered as a TXT. The most common mistake: used to other platforms, the administrator pastes the value into a TXT record. Microsoft 365, however, works exclusively through aliases — verification will keep failing until the record type is CNAME. Google Workspace, by contrast, publishes the public key directly as a TXT: two different mechanics for the same standard, compared in enabling DKIM on Google Workspace.

The duplicated suffix. Many DNS interfaces append the domain automatically to whatever name is typed. Entering selector1._domainkey.example.com in the name field then produces selector1._domainkey.example.com.example.com — a record perfectly published and perfectly useless. A quick dig query or an online lookup removes the doubt immediately.

Activating too early. As long as the CNAMEs do not resolve publicly, the portal refuses to enable signing with an error along the lines of "CNAME record does not exist". That is not a configuration failure; it is DNS propagation running its course — from a few minutes to a few hours depending on TTLs and the DNS host, with Microsoft cautiously announcing up to 48 hours. Trying again later is the whole fix.

Multiple domains. Every accepted domain in the tenant has its own configuration: its own pair of CNAMEs, its own toggle, its own rotation. Enabling DKIM on example.com covers neither separately declared subdomains nor the tenant's other domains. The onmicrosoft.com domain itself needs nothing: Microsoft signs it natively.

One last scoping note: Exchange Online's signature covers mail that leaves Exchange Online. Third-party platforms sending in the domain's name — marketing routing, invoicing, application notifications — sign with their own selectors, each configured on its own side.

Verifying the signature: headers and an external check

Once the toggle is flipped (or Set-DkimSigningConfig -Identity example.com -Enabled $true has run), the proof sits in the headers. A test message sent to an external mailbox — Gmail or Outlook.com will do — should exhibit two things. First, the signature itself:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1; ...

The d= now carries the custom domain, and the s= one of the two selectors. Then the receiver's verdict, in Authentication-Results:

Authentication-Results: ...; dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

dkim=pass with header.d=example.com: the signature is valid and aligned. If a DMARC record is already published, the dmarc=pass follows mechanically.

On the console side, Get-DkimSigningConfig should show Enabled : True, and the Defender portal its toggle in the active position. For an outside view without digging through headers, an online check of the domain reports the observable DNS state — published records, selector resolution — and reads it against the DMARC policy in place. Over the following days, the aggregate reports confirm the switch: the volumes sent by Exchange Online move to aligned DKIM.

Rotating selectors without touching the DNS zone

A DKIM key is not meant to last forever: good practice calls for periodic rotation, and that is exactly why Microsoft imposes two selectors. Rotation is triggered by a button in the portal ("Rotate DKIM keys") or in PowerShell:

Rotate-DkimSigningConfig -Identity example.com -KeySize 2048

The mechanics are elegant. Microsoft generates a new key pair and publishes the new public key behind the inactive selector — on Microsoft's side, at the far end of the CNAME. Once propagation is acquired, signing switches to the new selector; the old one becomes, in turn, the standby for the next rotation. At no point is the domain's DNS zone modified: the two CNAMEs published on day one stay valid for life. That is the whole point of the alias indirection.

Rotation is also the occasion to modernize an aging setup: tenants configured years ago sometimes still sign with 1024-bit keys; a rotation with -KeySize 2048 brings the key up to the current standard without a second of interruption. A yearly rotation, pinned to an existing security review, is a reasonable rhythm — the operation being painless, there is no reason to skip it.

What aligned DKIM unlocks for DMARC

Enabling DKIM on the custom domain is not an end in itself: it is the piece that makes DMARC genuinely dependable on a Microsoft 365 tenant.

First, because DKIM survives where SPF breaks. A mailbox-to-mailbox forward, a mailing list, a relay: in all those scenarios, the sending IP changes and SPF loses alignment. The DKIM signature, by contrast, travels inside the message and remains verifiable on arrival as long as the signed content is untouched. A domain whose Exchange Online mail is signed and aligned keeps a dmarc=pass across most forwarding paths — the indispensable condition for considering a strict policy without losing legitimate mail.

Second, because the reports become readable. With aligned DKIM, the legitimate volumes sent by Exchange Online stand out sharply from unauthenticated sources; whatever still fails then deserves a real investigation — a forgotten platform, or an impersonation attempt. On that sound basis the policy can climb from p=none to p=quarantine and on to p=reject, with annotated templates for every stage in the DMARC record examples ready to adapt.

Finally, DKIM alignment is the prerequisite for more visible outcomes: the requirements the major mailbox providers place on bulk senders, and eventually logo display through BIMI, which presupposes an enforced DMARC policy.

In summary

Microsoft 365 signs by default with the technical onmicrosoft.com domain: a valid but unaligned DKIM, hence mute for DMARC. Useful activation fits in three moves — create the signing configuration (Defender portal or New-DkimSigningConfig), publish the two selector1/selector2._domainkey CNAMEs pointing at contoso.onmicrosoft.com, then switch signing on once propagation is done. The traps are well known: a CNAME entered as a TXT, a suffix duplicated by the DNS interface, an activation attempted too early, and multiple domains each demanding their own pair. Verification is read in the headers (dkim=pass header.d=example.com), rotation happens without touching the zone, and the payoff is immediate: DKIM alignment that survives forwarding and opens the road to p=reject.

To situate the starting point, a free DMARC analysis of the domain shows in seconds the state of the published records and what remains to fix. And to follow the effect of the activation inside the aggregate reports — week after week, source by source — creating an account opens the dashboard that turns that raw data into an action plan toward an enforced policy.