Retiring a DKIM selector has two distinct effects: the sender can stop using its private key for new messages, and DNS can stop making the public verification key available. Those actions need not happen at the same moment. During an ordinary planned rotation, separating them can preserve verification for mail already signed and still in transit.
The exception is a security incident. If the old private key may be compromised, keeping its public key available also keeps the corresponding verification path usable. Decide the balance between containment and delayed-mail compatibility explicitly rather than applying routine rotation overlap automatically.
Record what the old selector still supports
Inventory the signing domain, selector, key custodian, sending systems and last known use. Include queued application mail, batch jobs and provider fallback routes. A single successful message from the new signer does not establish that every old signer stopped.
Determine whether the public key is directly published or reached through a provider-managed CNAME. If the target is removed when an account closes, leaving the alias in customer DNS is not enough to preserve verification. Ask for the actual retention behavior and confirm the relevant dependency before committing to account closure.
Plan the cutover with separate names
RFC 6376 §3.1 selector design permits multiple concurrent public keys under one signing domain. A supported rotation can publish the new selector, confirm that its key is retrievable, switch new signing, then retain the old verification material for the approved overlap. Do not replace old key material under the same lookup name and assume previously signed mail will follow the new key.
Use current algorithm and key-size guidance for the new key. RFC 8301 §3.1 prohibits rsa-sha1 signing and verification. RFC 8301 §3.2 requires signers to use RSA keys of at least 1024 bits, with at least 2048 bits recommended. Provider support and current security requirements still need review; merely changing the selector label does not strengthen a key.
Work through a delayed-message case
Illustrative sequence: message A is signed with old1 before cutover and waits in a queue. Message B is signed with new2 after cutover and arrives immediately. Both can verify while their corresponding public keys remain available, assuming covered content and all other applicable verification checks pass. If no usable old1 key can be retrieved when A is evaluated, A can fail with no key under RFC 6376 §6.1.2 even though B passes.
Choose the overlap using known queue behavior, signature expiration where present, business requirements and risk. No single retention duration guarantees verification for every future recheck of archived mail. Preserve original trusted authentication results when historical evidence matters. This scenario describes expected protocol behavior, not an observed service queue.
Verify retirement readiness
Confirm that each active route now signs with the intended new selector and that received messages pass with the required alignment. Review low-frequency jobs rather than relying solely on a short observation window. Record any route that cannot be exercised and obtain its owner's configuration evidence or a specific follow-up plan.
Check DNS caching assumptions. Under RFC 1034 §3.6, previously cached answers can persist for their earlier TTLs; lowering a TTL at retirement does not erase those caches. RFC 8767 §4 also permits use of stale records when authoritative refresh fails, so TTL expiry is not a guaranteed global revocation deadline. A successful authoritative refresh, including an authoritative NXDOMAIN, is different from refresh failure. Conversely, retaining a public key does not extend a signature's expiration or override receiver policy. Keep these mechanisms distinct in the retirement plan.
Remove authority deliberately
After the approved compatibility window, retire the public record or delegation according to the supported design. An empty p value signifies revocation under RFC 6376 §3.6.1; removing the key prevents its retrieval once relevant cached answers no longer supply it. Record the chosen method and why. Secure disposal of the private key and removal of provider access are separate tasks.
For a compromised key, document why immediate revocation or a shorter overlap is necessary and which legitimate messages may be affected. Do not restore compromised verification material merely to improve a dashboard score. The completed change should show when signing with the old key stopped, when old-key verification support ended and what evidence justified both decisions.
Record the next decision
A hypothetical retirement record should separate last old-key signing, new-route verification, outstanding queue or low-frequency-job evidence, provider target retention, cache assumptions and the authorized retirement decision. If a scheduled billing job has not been checked, mark its dependency unresolved rather than inferring retirement readiness from recent employee mail. For suspected compromise, use the incident decision rather than the routine overlap checklist. No rotation or DNS removal was performed.