Rotating a DKIM key without breaking mail in flight

DKIM keys should be rotated periodically, and immediately if a signing host is ever compromised. The operation is simple and the order is not negotiable, because messages you sent an hour ago are still being delivered and still need to verify.

Why selectors exist

A DKIM signature names the selector it used: s=s1; d=example.com. The verifier looks up s1._domainkey.example.com and finds the public key there.

That indirection is what makes rotation possible. A domain can publish several keys at once under different selectors, and each message points at the one that signed it. Without selectors, changing a key would invalidate every message in flight.

The order

1. Generate the new pair and publish the public half under a new selector. If the current one is s1, publish s2. Do not touch s1.
2. Wait for DNS. Long enough for the TTL on the zone to expire everywhere — an hour is usually plenty, a day is safer if the TTL is long. Verify from more than one resolver.
3. Switch signing to the new selector. From this point new mail is signed with s2 and older mail still verifies against s1.
4. Wait again. Until nothing signed with s1 could still be in a queue. Mail deferred by a receiver can retry for days; a week is a reasonable margin.
5. Remove the old record.

Skipping step two means mail is signed with a key nobody can fetch yet, and every message in that window fails DKIM. Skipping step four means mail still sitting in a remote queue fails on delivery, days after you thought the rotation was finished.

Naming selectors

Use something you can order: s1, s2, or a date like 202610. Avoid naming them after the thing that signs, because the signing host changes and the selector then lies about what it is.

Two selectors live at once during a rotation. Three means a rotation was abandoned halfway, which is worth finding out about.

The record itself

A 2048-bit key does not fit in a single DNS string — the limit is 255 characters — so the value is split. The halves must concatenate with nothing between them. Some DNS interfaces insert a space or a newline, and a verifier that joins them literally gets a key that does not parse.

This is the single most common DKIM failure, and it presents as "the record is published but the signature fails". Check the assembled value with the DKIM checker, which fetches the key the way a receiver would rather than the way your DNS panel displays it.

Key length

2048 bits. 1024 is being refused outright by major providers rather than treated as unsigned, and 4096 produces a record long enough that splitting problems become more likely without buying anything a receiver cares about.

How often

Every six to twelve months as routine. Immediately on any suspicion that the private key was exposed — and in that case the order changes: publish the new selector, switch signing, and remove the old record as soon as you can accept that in-flight mail will fail. A compromised key signing forged mail as you is worse than a day of bounces.