Rotating DKIM keys without dropping mail

A DKIM private key is a credential. Anyone holding it can sign mail that verifies as yours, indefinitely, and there is no revocation list to consult: the only way to invalidate a compromised key is to remove its public half from DNS. That makes periodic rotation worth doing, and immediate rotation essential if a key may have been exposed.

Start by generating a new key pair under a new selector name. Never reuse a selector for a different key, since messages in flight signed with the old key would suddenly fail verification against the new public half. Because selectors let several keys coexist under one domain, the rest of the rotation can happen with no interruption at all, provided you do it in the right order.

The sequence

1. Publish the new public key in DNS and wait for it to propagate everywhere.
2. Switch the signing service to the new selector. Mail now goes out signed with the new key.
3. Leave the old record published for at least as long as mail might sit in a queue. A week is a comfortable margin.
4. Replace the old record's p= value with an empty string to revoke it, or delete the record.

Why the overlap has to be that long

Mail does not all arrive promptly. A receiving server that is temporarily unavailable will queue your message and retry on a backoff schedule, commonly for up to five days before giving up. A greylisting receiver deliberately defers first contact. A message that leaves your server on Monday may not be verified until Friday, and it will be verified against whatever is in DNS at that moment, not what was there when it was signed.

So the question is not how long propagation takes, which is minutes to hours. It is how long a message signed with the old key might plausibly still be undelivered. A week covers almost every real case.

Revoking versus deleting

old._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p="   <- explicit revocation
                                  (or remove the record entirely)

An empty p= value is an explicit statement that the key is revoked, and a verifier treats any signature using it as failing. Deleting the record means the lookup returns nothing, which is a slightly weaker signal but has the same practical effect. Publishing the empty value is marginally better hygiene, particularly if you want the record to stand as a deliberate marker rather than look like an accidental deletion.

How often

Six to twelve months is the usual cadence for routine rotation, and it is a reasonable default. The value is less about cryptographic necessity, since a 2048-bit RSA key is not going to be factored on that timescale, and more about limiting how long a quietly stolen key stays useful. If nobody ever rotates, a key copied from a backup three years ago still signs valid mail today.

When to rotate immediately

• A server holding the private key was compromised, or a backup containing it was exposed.
• An administrator with access to the key has left the organisation.
• The key is 1024-bit and you are moving to 2048.
• A vendor that held a key on your behalf is being decommissioned, or you are ending the relationship.
• The key was ever transmitted over an insecure channel, pasted into a ticket, or committed to a repository.

That last one is more common than it should be. Treat a private key that has touched a chat message or a git history as compromised, even in a private repository.

When the provider holds the key

Many hosted senders ask you to publish a CNAME rather than a TXT record, pointing your selector at a name they control. That hands them key management, including rotation, which is usually an advantage: they can roll keys on their own schedule without asking you to touch DNS. The trade is that you cannot rotate on demand, and you are trusting their key handling. For a reputable provider that is a reasonable trade, but it does mean an incident on their side is not something you can remediate yourself.

Confirming it worked

After switching, send a message through the affected service and check that the DKIM-Signature header carries the new selector in s=, and that Authentication-Results reports dkim=pass. Then look up both selectors with the DKIM tool: the new one should return your key, and after the overlap the old one should return nothing or an empty p=.

Your next DMARC aggregate report is the real confirmation. It shows DKIM results per signing domain across all your mail, so a selector that has stopped verifying somewhere you did not think to test shows up there before anyone complains.