How do you rotate a DKIM key without breaking signed mail?
Replacing a DKIM key isn't as simple as swapping one DNS record for another: mail already in transit when you switch keeps the old signature, and receivers that haven't re-fetched DNS yet may still see the old selector. Publishing the new key under a new selector, running both in parallel for an overlap period, and only then retiring the old one is what keeps mail passing verification the whole way through.
By AdminKit team, Netbase JSC · Updated October 31, 2026
Why a key swap in place breaks mail
DKIM works by signing outgoing mail with a private key and publishing the matching public key in DNS, at a hostname built from a selector you choose: <selector>._domainkey.<yourdomain>. RFC 6376 defines the selector specifically so a domain can have more than one key published at once — which matters here, because overwriting a selector’s record the moment you generate a new key creates a window where mail signed just before the change can no longer verify. A receiver that queues a message for even a few minutes, or any mail already in transit, still carries a signature made with the retired private key; once DNS serves only the new public key, that signature has nothing to verify against.
AdminKit’s DKIM check validates one selector’s published record at a time, which is exactly the tool you want at each step below — not to detect a problem after the fact, but to confirm each stage of a rotation actually published what you intended before you move to the next one.
The dual-selector pattern
The fix is to never have a moment where only one key exists in DNS. Run the old and new keys under two different selector names in parallel, and move traffic between them deliberately:
- Generate the new key pair and choose a new selector name. Never reuse a selector name you’ve used before — RFC 6376 ties a selector to one specific key for the lifetime of any mail that might still need to verify against it, so republishing a different key under an old label breaks previously-sent mail retroactively rather than just today’s. A date-based name (
mail202611) or an incrementing one (selector-v2) avoids the collision. - Publish the new selector’s TXT record, but don’t switch signing yet. Confirm it resolves correctly with DKIM check before anything depends on it. Give the record time to actually be visible everywhere — see DNS propagation and TTL explained for why a record you just published isn’t instantly seen by every resolver.
- Switch your mail server to sign with the new selector. The old selector’s record stays published and unchanged throughout this step — this is the overlap period, and it’s what lets mail signed moments before the cutover still verify against the still-live old key while new mail verifies against the new one.
- Keep both selectors live for an overlap window. How long depends on how long your own infrastructure can realistically have mail still in flight from before the cutover — commonly cited guidance is at least a week, with slower or retry-heavy setups extending that further. There’s no protocol-mandated minimum; this is an operational judgment call based on your own delivery patterns.
- Revoke, don’t delete, the old selector once the overlap window has passed. RFC 6376 §3.6.1 defines an empty
p=tag as an explicit revocation: publishv=DKIM1; p=at the old selector’s hostname instead of removing the record outright. A revoked key fails verification cleanly and is easy to recognize as intentional; a deleted record just looks like a broken or never-configured selector if anyone investigates later.
# Before rotation
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0...oldkey..."
# During overlap — both live, signing has moved to the new selector
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0...oldkey..."
mail202611._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0...newkey..."
# After the overlap window — old key explicitly revoked
default._domainkey.example.com. TXT "v=DKIM1; p="
mail202611._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0...newkey..."When to rotate on a schedule, versus immediately
Routine rotation and emergency rotation follow the same dual-selector mechanics above, but on different timelines. M3AAWG’s dedicated best-practices document treats DKIM keys the same way as other long-lived credentials: rotating on a regular cadence reduces how long any single leaked key stays useful, independent of whether a leak is ever confirmed. If you have specific reason to believe a private key is compromised — a breached mail server, an exposed backup, departing access that included key material — skip the scheduled cadence and rotate immediately; the same steps apply, just without waiting for a planned date. Either way, confirm the new record with DKIM check before relying on it, and see DKIM selector and record mistakes that break signing for the syntax and publishing errors that most often undermine a rotation that otherwise followed the right sequence.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
Why rotate a DKIM key that isn't showing any problem?
A DKIM key that's never rotated is a long-lived credential: the longer the same private key signs mail, the longer a single leak (a compromised mail server, a misconfigured backup, a departing admin's old access) stays exploitable without anyone necessarily noticing. M3AAWG's dedicated best-practices document on this treats periodic rotation as routine hygiene, separate from reacting to a known incident — the same logic as rotating any other long-lived credential on a schedule rather than only after something goes wrong.
Can I just replace the TXT record at my existing selector in place?
You can, but it causes exactly the outage this guide is about avoiding. The moment you overwrite the record, any mail already sent (but not yet verified by a slower or queuing receiver) still carries a signature made with the old private key, while DNS now serves the new public key — verification fails for that mail. Publishing the new key under a brand-new selector name, instead of overwriting the old one, is what lets both keys be valid at once during the transition.
What does 'never reuse a selector name' actually mean in practice?
Pick a new selector label every time you rotate — something like a date-based name (mail202611) or an incrementing one (selector-v3) rather than reusing a generic label like 'default' or 'key1' again later. If you ever republish a different key under a selector name you've used before, DNS now returns a different public key than whatever is cached or than older archived mail was signed with, and that old mail's signature breaks retroactively — selectors are meant to be identifiers for one specific key, not a reusable slot.
How long should I keep the old selector's record published during rotation?
Long enough for the slowest legitimate mail signed before the cutover to still be verified by its receiver — commonly cited guidance is at least a week, with some sources suggesting up to 30 days for estates with slower or retry-heavy delivery. There's no single number that fits every mail setup; the deciding factor is how long your sending infrastructure can realistically still have outbound mail in flight that was signed before you switched.
How do I retire the old selector once the overlap period is over?
RFC 6376 defines an empty p= value in a DKIM TXT record as a deliberate revocation, not a removal — publish "v=DKIM1; p=" at the old selector rather than deleting the record outright. This makes any further use of that selector fail cleanly and explicitly rather than silently falling back to no record found, which is easier to diagnose if anything is still unexpectedly sending with the old key.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.
Talk to an expert
Huy Nguyen (David), Founder & CEO, Netbase JSC
Ask whether this fix applies to your setup, or get a second pair of eyes on your DNS and mail records.