How to rotate DKIM keys

DKIM keys age. The longer a private key sits on a server — surviving staff changes, backups, migrations and the occasional incident — the less certain you can be that it is still private. Rotation replaces the key pair on your terms, and done in the right order it causes no failures at all: not one message, not one receiver. This guide is that order.

Why rotate at all

• Limit exposure. If a private key leaks quietly, rotation puts a hard end date on its usefulness. Without rotation, a leaked key signs convincing mail as your domain indefinitely — and it will pass authentication.
• Upgrade strength. Rotation is the moment you move a legacy 1024-bit key to 2048-bit (see why that matters), or add an Ed25519 selector alongside RSA.
• Respond to events. A departing administrator who had shell access to the signer, a compromised server, a provider breach notice — all of these should trigger an immediate rotation rather than waiting for the calendar.

A sensible cadence for most organisations is every 6–12 months, plus event-driven rotations. Hosted providers that manage keys behind CNAMEs (Microsoft 365, Fastmail, Proton and others) rotate for you — one good reason to prefer the CNAME setup when it is offered.

The one rule that makes rotation safe

Never replace the key under an existing selector. Publish the new key under a new selector, and keep the old record up until in-flight mail has cleared.

The reason is timing. A message signed at 09:59 with the old key may be verified at 10:05, or — after a greylist, a retry queue, or a slow forwarder — two days later. Verification uses the selector named in the message, so as long as the old record stays published, old signatures keep verifying. Swap the key in place under the same selector and every message signed before the DNS change but verified after it fails. Selectors exist precisely to make this overlap painless — see DKIM selectors explained.

Step by step

1. Generate the new key pair

Create a fresh 2048-bit key. Our record generator does this in your browser — the private key never leaves the page — and formats the TXT record for you. Choose a new selector; date-based names such as s202607 keep the history legible and guarantee no collision with the old name.

2. Publish the new record — alongside the old one

Add the TXT record at newselector._domainkey.yourdomain.com. Do not touch the old record. Two (or more) published selectors is a completely normal state.

3. Verify the new record before anything signs with it

Check it with the DKIM checker: the record should parse cleanly and report the expected key length. Catching a copy-paste error now costs nothing; catching it after the switch costs failed mail. Remember DNS propagation — verify after your record’s TTL has passed, and from more than one network if you can.

4. Switch signing to the new selector and key

Update your signer — OpenDKIM or rspamd configuration, appliance settings, or your sending platform’s console — to use the new private key and the new selector name. From this moment, new mail goes out under the new key.

5. Confirm with a real message

Send a test to a mailbox at a major receiver and read the headers: DKIM-Signature should carry s=newselector, and Authentication-Results should say dkim=pass. If you publish DMARC with rua= reporting, the next days of aggregate reports will confirm the change across all receivers — a rotation is an excellent moment to be reading them.

6. Wait

Leave the old record published while messages signed with it can still plausibly arrive. Retry queues commonly persist for 4–5 days; slow forwarders add more. Seven days is a comfortable minimum; two weeks costs nothing and covers the long tail. There is no penalty for the overlap.

7. Revoke the old key

Replace the old record’s value with an empty public key:

v=DKIM1; k=rsa; p=

The empty p= tag is the standard’s explicit revocation signal — clearer than deleting the record, because it tells verifiers (and future auditors) that the key was withdrawn deliberately. After another comfortable interval you can delete the record entirely and, finally, destroy the old private key material wherever it lived: signer configuration, backups, password managers, provisioning repositories.

Rotating when the provider holds the key

If your DKIM is delegated by CNAME into a provider’s DNS, rotation is their job and normally invisible to you. Two situations still involve you: providers like Google Workspace that have you paste a TXT record will have you repeat that flow to rotate (generate new key in the console → publish → activate); and if you ever remove a sending platform, treat its selectors like your own retirements — revoke or remove them rather than leaving live keys pointing at a service you no longer control.

What can go wrong, and how you would notice

• Switched signing before the record propagated → immediate dkim=fail/no-key errors on new mail. Roll signing back to the old selector, wait, verify, switch again.
• Revoked the old key too early → failures on old mail still in transit (visible in DMARC reports as a brief spike). Re-publish the old record until the tail clears.
• Published the new key under the old selector — the in-place swap. Same symptom as revoking early. Fix by restoring the old key at the old selector and starting the sequence properly with a new name.
• Both records at one name. If you accidentally add rather than replace during revocation, you get two TXT records at one selector and intermittent failures. The checker flags this.

Rotation checklist

1. Generate new 2048-bit key pair (new selector, date-based name).
2. Publish new TXT record alongside the old one.
3. Verify the new record with the DKIM checker after TTL.
4. Switch the signer to the new selector and private key.
5. Test message → dkim=pass with s=newselector.
6. Wait at least 7 days (watch DMARC aggregate reports).
7. Revoke the old key (p= empty), later delete the record.
8. Destroy old private key material everywhere it exists.
9. Diary the next rotation.

A rotation done this way is boring — which is the point. Generate the new key when you are ready: the record generator will have the record formatted before your DNS panel has finished loading.

Related guides

• DKIM selectors explained — why each rotation needs a new selector.
• DKIM key length — upgrading key strength during a rotation.
• DKIM troubleshooting — spotting a rotation that has gone wrong.
• Email DNS validator (dns.studio) — check SPF and DMARC alongside DKIM.