Rotations that lose mail

After this lesson you can

Name the four ways a rotation destroys signatures, and the check that catches each.

Assumes you have read The overlap window.

Every way a rotation loses mail is a step done out of order. Four of them account for nearly all real incidents.

The four

Mistake	Symptom	The check that catches it
Signing with the new key before its record resolves	Sudden DKIM failures at a subset of receivers, resolving on their own over the TTL	Query the new selector from a resolver you do not control before switching.
Revoking the old selector immediately after switching	Failures on mail sent days ago, concentrated at receivers that were deferring	Wait out the retry window. Revoking is never urgent unless the key leaked.
Replacing the key in place at the same selector	Intermittent failures for the length of the TTL, with no pattern by receiver	Use a new selector. There is no reason to reuse one.
Rotating one signer of several	One mail stream fails while others pass; usually noticed weeks later	Inventory every system signing as the domain before starting.

Verifying before you switch

The publish step is complete when the record answers from somewhere outside your own infrastructure, not when your DNS provider’s console shows it saved:

$ dig +short TXT mktg202609._domainkey.example.com @1.1.1.1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB..."

An empty answer here means do not proceed, whatever the console says.

If your zone has secondaries, check each of them. A record present on the primary and absent from one secondary produces exactly the symptom in the first row — failures at a fraction of receivers, apparently at random.

Verifying after

Send a message through the rotated path and read the delivered headers. The DKIM-Signature should name the new selector and Authentication-Results should report dkim=pass. Both, not either: the first proves the signer switched, the second proves the record works.

A rotation is not finished until the old selector is revoked

The half-finished rotation — new key live, old key still published and still valid — is the most common state to find a domain in, and it has the security properties of not having rotated. Put the revocation in the calendar at the moment you switch, dated for the end of the drain window.

Knowledge check

You rotate to a new selector, switch the signer, and revoke the old selector the same afternoon. What fails, and where?

Mail sent before the switch that is still being retried — it carries old-key signatures that now verify against an empty p=.
Nothing — the new key is live and signing correctly.
All mail, until the old selector’s TTL expires.
Mail to receivers that cache the old key, which will keep accepting it.

Correct — Mail sent before the switch that is still being retried — it carries old-key signatures that now verify against an empty p=. Revocation is retroactive in effect: it invalidates every signature made with that key, including ones already in flight. Queued mail can be several days old, so the drain window has to pass before revoking.

Not this — Nothing — the new key is live and signing correctly. The new key covers mail sent after the switch. The problem is mail sent before it, which is still in retry queues carrying the old signature.

Not this — All mail, until the old selector’s TTL expires. Mail signed with the new key verifies against the new record immediately. The failure is confined to messages bearing the old signature.

Not this — Mail to receivers that cache the old key, which will keep accepting it. A cached old key would make those signatures pass, not fail. Caching delays the revocation taking effect; it does not cause the failure.

Last reviewed 2026-09-15

Rotations that lose mail

The four

Verifying before you switch

Verifying after

Try it on a real domain