DKIM guide: sign your emails

What DKIM is for

DKIM (DomainKeys Identified Mail, RFC 6376) signs every outgoing email with a private key, kept by your sending service. The matching public key is published in your DNS. The server that receives the email reads it and checks the signature: it proves that the email really comes from a server authorised by the domain and that it has not been altered on the way.

Unlike SPF, the DKIM signature survives an email being forwarded by an intermediate server. It is often what allows your emails to pass DMARC.

Enabling DKIM in Microsoft 365

Microsoft 365 holds the keys and rotates them itself: in your DNS, you only publish two aliases (CNAME), selector1 and selector2, which point to Microsoft.

1. In the Microsoft Defender portal, open Email & collaboration, Policies & rules, Threat policies, then Email authentication settings, DKIM tab. Direct link: security.microsoft.com/authentication.
2. Open your domain's row. If no keys exist yet, create them. The Publish CNAMEs section of the pane shows the two values to publish.
3. At your DNS host, create the two CNAME records, copying these values exactly:

   selector1._domainkey.exemple.nc.  CNAME  selector1-exemple-nc._domainkey.<your-tenant>.<x>-v1.dkim.mail.microsoft.
   selector2._domainkey.exemple.nc.  CNAME  selector2-exemple-nc._domainkey.<your-tenant>.<x>-v1.dkim.mail.microsoft.

   Domains set up before May 2025 use the older form selector1-exemple-nc._domainkey.<your-tenant>.onmicrosoft.com. Never rebuild these values by hand: copy the ones shown in the portal.
4. A few minutes later, once the CNAME records have been detected, go back to the domain's pane and turn on "Sign messages for this domain with DKIM signatures".

In Exchange Online PowerShell, the same steps are:

# 1. Create the keys, if the domain does not have any yet
New-DkimSigningConfig -DomainName exemple.nc -Enabled $false -KeySize 2048
# 2. Read the two CNAME values to publish
Get-DkimSigningConfig -Identity exemple.nc | Format-List Selector1CNAME, Selector2CNAME
# 3. Enable signing, once the CNAME records are published
Set-DkimSigningConfig -Identity exemple.nc -Enabled $true

Without the -KeySize 2048 parameter, Microsoft creates a 1024-bit key. To move an existing key to 2048 bits: Rotate-DkimSigningConfig -Identity exemple.nc -KeySize 2048. The new key starts signing after four days.

Microsoft documentation: set up DKIM for Microsoft 365 (opens in a new tab).

Enabling DKIM with another provider

1. In the interface of your sending service (email host, newsletter platform, CRM), look for the "domain authentication" or "DKIM" section.
2. Generate a 2048-bit key. The service tells you the name to create (<selector>._domainkey) and the value: a TXT record containing the key, or a CNAME pointing to its own servers.
3. Publish the record at your DNS host, then enable signing in the service.
4. Repeat for each service that sends with your domain: each one signs with its own key, under its own selector.

Key length

A 2048-bit RSA key is the standard today. A 1024-bit key is considered too short, and below that it can be cracked. Ed25519 is a modern, strong alternative, but not all recipients check it yet: it is used in addition to an RSA key. In Domain Check, a 2048-bit or Ed25519 key scores 100, a key of 1024 to 2047 bits 70, and a shorter key 20.

Key rotation

Changing keys regularly limits the damage of a compromised key. The safe method: publish the new key under a new selector, switch signing over to it, wait a few days for emails in transit to be delivered, then empty the old key (p=) before deleting it. Microsoft 365 alternates between selector1 and selector2 by itself.