A rotation is four steps with waits between them, and every wait exists because something is still holding the old state — a resolver cache, a message queue, or a signing process that has not been told yet.
The sequence
1. PUBLISH new selector's key in DNS
wait: TTL of the new record (it must be resolvable
everywhere before anything signs with it)
2. SWITCH signer to the new selector
old key still published, old signatures still verify
3. DRAIN wait: longest plausible delivery delay
queued and retrying mail still carries old signatures
4. REVOKE old selector -> p= (keep the record)Sizing each wait
| Wait | Governed by | Typical |
|---|---|---|
| Publish → switch | TTL on the new key record, plus propagation to your secondaries | 1 hour at a 300s TTL; 24 hours if the TTL is a day |
| Switch → revoke | How long a message can sit in a retry queue | 3–7 days |
The second wait is the one people underestimate. A receiver that defers your mail retries for days — many retry for up to five — and every one of those messages still carries a signature made with the old key. Revoke on day one and you invalidate your own mail retroactively, at exactly the receivers that were already having trouble with it.
Lower the TTL before, not during
A resolver holds a record for the TTL it was given when it fetched it. Lowering the TTL at the moment you publish does nothing for this rotation — it helps the next one. If the key record currently has a 24-hour TTL, lower it to 300 seconds a full day before you begin.
- This matters for the rollback as much as the rollout.
- Under a delegation, the TTL that governs is the vendor’s, at the far end, and you do not control it.
- Raise it again once the rotation has settled.
A new selector, never a new key at the same name
Replacing the key at an existing selector creates a window in which some resolvers have the old key and some the new, and messages signed with either fail at some fraction of receivers with no way to tell which. Issuing the new key under a new selector removes that window entirely: both keys are valid simultaneously, each at its own name, and nothing is ambiguous at any moment.