Reference

DKIM key rotation: rotate keys without breaking mail

Rotate a DKIM key without failed signatures: the RFC 6376 new-selector order, revoking with an empty p=, and steps for Google, Microsoft 365, SES and more.

By Updated Last verified

On this page
  1. Why selectors make rotation safe
  2. The overlap-safe sequence
  3. Rotation by provider
  4. Google Workspace
  5. Microsoft 365
  6. Amazon SES
  7. Mailgun
  8. Postmark
  9. SendGrid
  10. How often to rotate
  11. Check the result
  12. Sources

DKIM (DomainKeys Identified Mail) key rotation replaces the key your mail is signed with. To do it without failed signatures, publish the new public key under a new selector, switch signing to the new private key, and keep the old public key published while mail signed with it may still be in transit; at the end, remove the old key record (RFC 6376 section 3.1 (opens in a new tab)) or revoke the key by publishing its record with an empty p= (section 3.6.1 (opens in a new tab)). The provider section below covers the steps in Google Workspace, Microsoft 365, Amazon SES, Mailgun, Postmark and SendGrid.

Why selectors make rotation safe

DKIM (opens in a new tab) lets a domain claim some responsibility for a message by associating its name with the message. Each signature names its key with the s= tag, the selector, which subdivides the namespace of the signing domain in the d= tag (RFC 6376 section 3.5 (opens in a new tab)). Keys live under _domainkey, so a signature with d=example.com and s=202610 sends the receiver to 202610._domainkey.example.com (section 3.6.2.1 (opens in a new tab)).

Selectors exist so one domain can publish several public keys at the same time (section 3.1 (opens in a new tab)). That is what lets you replace a key on a routine basis without a gap. The standard's example moves from a selector named january2005 to one named february2005: both public keys are published for a transition period while mail may still be in transit before it is verified, the servers start signing with the new private key at the start of that period, and the old public key is removed at the end.

Don't put a new key under the old selector. Reusing a selector makes a message that failed because its key is no longer valid impossible to tell apart from one that is actually forged, so the RFC advises assigning new keys to new selectors. Its examples name selectors after months (january2005, february2005) and suggest combining dates with locations; this page uses 202604 for an old key and 202610 for a new one.

DemiSignal's DKIM record generator applies the same rule: use a new selector when you rotate, so the old and new key can be published side by side. To find the selector you use today, see the DKIM selector guide.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

The overlap-safe sequence

For a key you publish yourself as a TXT record (your own mail server, or a service that gives you a new record):

  1. Make a new key pair under a new selector. Use 2048 bits: signers must use RSA keys of at least 1024 bits and should use at least 2048 (RFC 8301 section 3.2 (opens in a new tab)). The DKIM record generator makes the pair in your browser, 2048-bit by default, and gives you the TXT record to publish and the private key for your mail server.
  2. Publish the new public key. Add a TXT record at 202610._domainkey.example.com whose value is v=DKIM1; k=rsa; p= followed by the new public key.
  3. Switch signing to the new private key. When rotating to a new key pair, signing should start with the new private key right away (RFC 6376 section 5.2 (opens in a new tab)).
  4. Keep the old public key published. Section 5.2 also advises keeping the old public key for a reasonable validation interval before removing it, and not signing with a key whose public record you expect to revoke or remove before receivers can check the signature: verifiers can choose to defer validation, perhaps until the recipient reads the message. On the receiving side, section 6 (opens in a new tab) advises verifying in a timely manner; in many configurations the most timely place is when the receiving border server accepts the message.
  5. Retire the old key. Remove the old record, or revoke it by publishing the record with an empty p= value (section 3.6.1 (opens in a new tab)). Revoking states that you know the selector but its signatures must not pass, for example after a private key has been compromised.

A revoked record for the old selector looks like this:

202604._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p="

A verifier that finds an empty p= must treat the signature as failed and return PERMFAIL (key revoked), and there is no defined difference in meaning between a revoked key and a removed record (section 6.1.2 (opens in a new tab)). Section 3.1 (opens in a new tab) allows either: remove the record after the transition, or keep it revoked for a further period.

Rotation by provider

In the services below, CNAME records point your selectors at keys the service manages; with a TXT record, you publish each new key yourself.

Service Who makes the key What you do
Google Workspace (opens in a new tab) Google, when you click Generate New Record Publish a TXT record under a new prefix, then start authentication
Microsoft 365 (opens in a new tab) Microsoft, when you start a rotation Keep both selector CNAMEs; the new key signs after 96 hours
Amazon SES Easy DKIM (opens in a new tab) SES Publish the three CNAME records SES gives you
Amazon SES BYODKIM (opens in a new tab) You Publish a TXT record under a new selector, then give SES the new private key
Mailgun (opens in a new tab) Mailgun, every 120 days by default with Automatic Sender Security Publish two CNAME records once
Postmark (opens in a new tab) Postmark, when you click Generate New Publish a new TXT record, then verify it
SendGrid (opens in a new tab) SendGrid, when necessary Publish the automated security CNAME records

Google Workspace

Google's DKIM article documents setup: you generate a DKIM key and add it to your domain. For a rotation, use a new prefix, because RFC 6376 advises assigning new keys to new selectors (section 3.1 (opens in a new tab)).

  1. In the Google Admin console, go to Menu > Apps > Google Workspace > Gmail, click Authenticate email and select the domain.
  2. Click Generate New Record, and Google generates the key. Choose 2048 if your domain provider supports 2048-bit keys; a domain that used a 1024-bit key can switch to 2048.
  3. Enter a new prefix. The default prefix is google; if your domain already uses a DKIM key with that prefix, Google asks you to enter a different one. If you're not sure which DKIM keys other services use, check the DNS records at your domain host.
  4. Add the public key to your domain as a DKIM TXT record at your domain host. Don't click Start Authentication yet. After you add a key, it can take up to 48 hours for DKIM authentication to start working.
  5. Once the record is published, return to Authenticate email, select the domain and click Start authentication. When DKIM is working, the status at the top of the page changes to Authenticating email with DKIM.
  6. Send a message to someone who uses Gmail or Google Workspace and look for the DKIM result in its Authentication-Results header.

Keep the old record published for a validation interval before you remove it, as RFC 6376 section 5.2 (opens in a new tab) advises. For the full record set, see Google Workspace SPF, DKIM and DMARC.

Microsoft 365

Microsoft 365 generates two key pairs for each custom domain, behind two CNAME records with the host names selector1._domainkey and selector2._domainkey. Only one selector is active. The other is used only after a future key rotation, once the original selector is deactivated. Microsoft 365 manages the DKIM keys and handles key rotation automatically, with the CNAME records delegating key management to Microsoft. Microsoft's rotation section describes a manual key rotation that you start. There's currently no automatic DKIM key rotation for the *.onmicrosoft.com domain. A TXT record that you manage yourself isn't supported.

To rotate in the Defender portal, open the Email authentication settings page, select the DKIM tab, select the domain and choose Rotate DKIM keys at the bottom of the flyout. In Exchange Online PowerShell:

Rotate-DkimSigningConfig -Identity example.com -KeySize 2048

Leave out -KeySize to keep the current bit depth. A change from 1024 to 2048 bits applies to the next active selector at the first rotation.

The switch isn't immediate. The new private key starts signing after four days (96 hours); until then the existing key signs. You can't start another rotation while one is in progress, and without the selector2 CNAME record you can't rotate at all. To see which key signed a message, check the s= value in its DKIM-Signature header. Setup steps are in Microsoft 365 SPF, DKIM and DMARC.

Amazon SES

With Easy DKIM, SES generates the key pair and signs every message from the identity, with a 2048-bit key by default (opens in a new tab). You publish three CNAME records. SES publishes the public keys as TXT records in the hosted zone named in the SigningHostedZone field of the SES API (opens in a new tab), which also reports the last time a key pair was generated for the identity. SES limits how often you can change the key length to protect mail in transit: change keys too quickly and the former key may already be invalid when receivers check it.

With BYODKIM (bring your own DKIM), the key pair is yours, and you can rotate it as often as you want. Publish the new public key as a TXT record under a new, unique selector, then update the domain identity with the new private key and that selector. For an existing domain, the API operation is PutEmailIdentityDkimSigningAttributes.

Mailgun

With Automatic Sender Security, you add two CNAME records and Mailgun hosts the keys, so it can rotate them without any action from you. It generates two 2048-bit selector records and rotates them every 120 days by default; you can change the period, down to a minimum of 5 days. The two records let Mailgun introduce a new key while the old one stays active.

You can also rotate manually on your own schedule. Mailgun signs with up to 3 DKIM keys and, when several are active, picks the key for each message round robin. Each new key needs a selector unique to the sending domain. Send yourself test messages to confirm the new key signs, then delete the old key.

Postmark

In Postmark, go to the Sender Signatures tab, click DNS Settings next to the domain and click Generate New under the existing DKIM key. Publish the new key and selector as a new TXT record, then click Verify. Once it shows as verified, new messages are signed with the new key and Postmark revokes the original key from signing. You can wait a few days before deleting the original TXT record, so messages signed with the previous key can still arrive.

SendGrid

With automated security, SendGrid generates three CNAME records and manages your DKIM records. It uses the selectors s1 and s2 by default, activates one at a time for signing and rotates them when necessary.

How often to rotate

Providers state different intervals:

Check the result

DemiSignal's DKIM check reads public DNS only and finds the keys a domain publishes under common and provider selectors, with each key's type and size. It also covers revoked keys: a record with an empty p= revokes a key, and mail signed with it fails DKIM. The check tries the selectors common services use and the ones your SPF and MX records point to; a service that uses its own selector name will not be found this way. Its selector is in the s= tag of the DKIM-Signature header of an email it sent.

The full check reads the SPF, DKIM and DMARC records of the domain you enter, with no account needed, and flags DKIM keys that are weak, revoked or of an unknown type. If signatures fail after a rotation, DKIM fail explains how to read the reason and fix the record or key that does not match.

Sources

Tools for this

Frequently asked questions

How do I rotate a DKIM key without breaking mail?

Publish the new public key under a new selector, switch signing to the new private key, keep the old public key published for a validation interval, then remove the old record or revoke the key with an empty p= value.

Can I put the new DKIM key under the same selector?

RFC 6376 advises against it. Reusing a selector makes a message that failed because its key is no longer valid impossible to tell apart from a forged one, so assign new keys to new selectors.

How does DKIM key rotation work in Microsoft 365?

Microsoft manages the keys behind your two selector CNAME records. You start a rotation in the Defender portal or with Rotate-DkimSigningConfig, and the new private key starts signing after four days (96 hours).

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account