Skip to main content

Rotating DKIM Keys Without Downtime

Roll a DKIM key safely: publish the new selector first, switch signing, wait out in-flight mail and DNS caches, then retire the old selector — with the checks at each step.

A DKIM rotation done in the wrong order produces a window in which signed mail cannot be verified, DMARC fails, and messages are quarantined or rejected. This guide covers the overlap-based sequence that avoids that window entirely, and the check to run at each step before moving on.

Root Cause: Verification Happens Later Than Signing

A DKIM signature is created at send time and verified at receipt, and those two moments can be separated by hours. A message signed at 09:00 might be queued at an intermediate relay and verified at 11:00, by which point your DNS may have changed.

Verification uses the selector named in the message's own DKIM-Signature header, so the receiver looks up whichever selector signed it. If that selector's public key has been removed from DNS, verification fails — not because the signature was invalid, but because the key needed to check it no longer exists.

Two effects extend the window beyond the obvious. DNS caching means a resolver may serve a removed record for its remaining TTL, or may already have cached the absence of a record that you have just published. And queued mail at intermediate relays can be delivered long after it was signed, with retries stretching to a day or more for a temporarily unreachable receiver.

A rotation therefore needs a period in which both keys resolve, long enough to cover the slowest message still in flight.

The verification gap created by removing a key too early A message signed with the old selector is delayed at a relay and verified after the old key was withdrawn, so verification fails. Signed at 09:00, Verified at 11:00 09:00 — signed selector: s1 queued at a relay delayed two hours 10:30 — s1 removed rotation "completed" 11:00 — receiver looks up s1, finds nothing, DKIM fails, DMARC fails, and the message is quarantined.
The failure has nothing to do with the signature's validity — the key required to check it was withdrawn while the message was still in transit.

The Exact Sequence

Five steps, with a verification gate before each transition.

1. Publish the new selector. Add s2._domainkey alongside the existing s1._domainkey. Nothing signs with it yet; this step only makes the key resolvable.

# Confirm the new key resolves everywhere before doing anything else.
# Query several public resolvers, not just your own — propagation is uneven.
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "== $r"; dig +short @$r s2._domainkey.mail.example.com TXT
done

2. Wait for propagation. At least the previous record's TTL, and longer where a provider caches aggressively. An hour is usually ample; the cost of waiting is zero and the cost of not waiting is failed verification.

3. Switch signing to the new selector. Change the ESP configuration so new mail is signed with s2. From this moment both selectors are in use: old mail in flight carries s1, new mail carries s2, and both resolve.

4. Wait out the in-flight window. This is the step people shorten and should not. Nothing signed with s1 may still be awaiting delivery, which in practice means waiting at least as long as your ESP's maximum retry window — commonly 24 to 72 hours.

5. Remove the old selector. Delete s1._domainkey only after the window has elapsed and after confirming no recent mail was signed with it.

# Before removing s1, confirm current mail is actually signing with s2.
# The d= and s= tags in a recently received message's header are the evidence.
dig +short s1._domainkey.mail.example.com TXT   # still present, about to go
dig +short s2._domainkey.mail.example.com TXT   # must be present

Verifying Each Step With Real Mail

DNS queries confirm the keys resolve; only a received message confirms what is actually signing. Send a test to an address you control at each transition and read the authentication results.

Authentication-Results: mx.example.net;
  dkim=pass header.i=@mail.example.com header.s=s2;
  spf=pass smtp.mailfrom=mail.example.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

The header.s= tag names the selector that signed the message, which is the fact you need at step 3 — configuration changes at an ESP do not always take effect immediately, and a dashboard showing the new selector is not the same as mail being signed with it.

The dkim=pass alongside dmarc=pass at step 5 is the confirmation that removing the old selector changed nothing. If DMARC reports alignment against SPF only, the DKIM signature is not aligned and removing a key is not your immediate problem.

Rotation sequence with gates Publish, propagate, switch signing, wait out in-flight mail, then remove — each transition gated by a check. Overlap, Then Retire 1 — publish s2 nothing signs yet gate: dig on 3 resolvers 2 — propagate at least the old TTL gate: resolves everywhere 3 — sign with s2 both keys in use gate: header.s=s2 4 — wait 24-72h in-flight mail drains gate: retry window past 5 — drop s1 Step 4 is the one that gets shortened under time pressure, and it is the only step that protects mail already sent. Leaving the old selector published indefinitely is safe; removing it early is not.
Every step is reversible until the last one, which is why the final wait is the only genuinely irreversible decision in the sequence.

Variant: Rotating When the ESP Owns the Key

Where the provider generates and hosts the key — publishing a CNAME that points at their record rather than a TXT you control — the sequence is the same but two steps change hands.

The provider rotates the underlying key behind the CNAME, which means the rotation can happen without any change on your side and without notice. That is convenient and it removes your ability to sequence it. What you retain is the ability to verify: monitoring header.s= on received mail and the DKIM pass rate in Postmaster Tools will show a provider-side rotation that went wrong.

Where you sign with your own key on your own selector, you own the whole sequence — which is more work and is worth it for a domain whose reputation matters, because it also means an ESP migration does not force a key change.

Choosing the Key Length and the Selector Name

Two decisions are made once at rotation time and then live with you until the next one.

Key length is a trade between security and DNS practicality. A 1024-bit key is now considered weak and several receivers treat it as such; 2048 bits is the current baseline. The complication is that a 2048-bit public key exceeds the 255-character limit for a single DNS TXT string, so the record must be published as multiple concatenated strings. Most providers handle this correctly, but some older DNS panels silently truncate instead — which produces a record that resolves and fails verification, the most confusing possible failure. Verify the published record's length against the key you generated rather than assuming it round-tripped.

Selector naming should encode when the key was created, not what it is for. A selector named s1 tells you nothing at rotation time; one named 2026-07 tells you immediately how old the key is and which of two published selectors is the newer. Avoid names tied to a provider — sendgrid1 becomes actively misleading after a migration, and the selector cannot be renamed without another rotation.

A date-based scheme also removes the awkward moment in a rotation where both selectors are live and someone has to remember which is which. 2026-01 and 2026-07 are self-describing in a way that s1 and s2 are not, and the ordering is obvious to whoever runs the next rotation six months later.

Publishing a 2048-bit key in DNS A 2048-bit public key exceeds one TXT string and must be concatenated; a panel that truncates instead produces a record that resolves but never verifies. A 2048-Bit Key Does Not Fit One TXT String published correctly "p=MIIBIjAN…" "…IDAQAB" Two strings, concatenated by the resolver into one complete key. silently truncated "p=MIIBIjAN…" second half dropped The record resolves, so every check that looks for presence passes — and DKIM fails.
Checking that the record exists is not enough for a 2048-bit key; the published length has to match the key you generated.

Pipeline Integration

Treat the DNS records as code in the same repository as your other infrastructure, so each step of the rotation is a reviewed commit with a timestamp. That history is what makes the in-flight window auditable: "s1 removed 72 hours after signing switched" is verifiable from the log rather than from memory.

Add DKIM pass rate to the alerting described under reputation monitoring. A rotation that goes wrong shows up there within a day, and a drop from 100% to roughly 50% is the specific signature of two signing paths where one no longer resolves.

Validation and Deployment Checklist

Frequently Asked Questions

How often should DKIM keys be rotated?

Every six to twelve months is a common policy, and the rotation matters less than the key length: a 2048-bit key rotated annually is stronger than a 1024-bit key rotated monthly. The strongest argument for a routine rotation is that it exercises the process, so the first time you need to rotate urgently is not the first time you have done it.

Can both selectors sign the same message?

Yes — a message can carry multiple DKIM signatures, and receivers accept it if any one verifies. Dual signing removes the in-flight risk entirely, since every message is verifiable under both keys. Not every ESP supports it, but where it is available it is the safest rotation of all.

What if we removed the old selector too early?

Republish it immediately. The record's content is the public key, which is not secret, so restoring it is safe provided you still have it — which is a strong argument for keeping the key material in version control rather than only in a DNS dashboard. Mail that already failed cannot be recovered, but the ongoing failures stop as soon as the record resolves again.

Does rotating the key affect domain reputation?

Not directly, provided verification never fails. Reputation attaches to the signing domain rather than to the key, so a clean rotation is invisible to receivers. A botched one damages reputation through the failed verifications, not through the rotation itself.

← Back to Email Authentication: SPF, DKIM, and DMARC