DKIM key rotation: a safe, zero-downtime playbook
Why rotating DKIM keys matters, when to do it, and the exact two-selector cutover that keeps signatures valid through the change.
DKIM keys are like passwords: long-lived ones rot. The longer a key sits in DNS, the more chances it has to leak — from old backups, decommissioned servers, or that one developer laptop that never came back. Rotating annually is the conservative baseline; quarterly is what mature programs do.
Why rotate at all?
- Key compromise reduction. Even without a known leak, time-bounded keys limit the blast radius if one happens.
- Algorithm upgrades. Rotation is the natural moment to move from 1024-bit to 2048-bit RSA.
- Compliance. SOC 2, ISO 27001 and most enterprise security questionnaires expect a documented rotation schedule.
- Hygiene. Forces you to verify that your signer still has access to the private key — surprisingly often it doesn't.
Selector naming
A DKIM selector is a label that lets you publish multiple keys under the same domain. The DNS name is <selector>._domainkey.<domain>. Pick a scheme that encodes the rotation date so you can read history at a glance.
| Scheme | Example | Pros | Cons |
|---|---|---|---|
| Date-based | s2026q2 | Self-documenting | Predictable to attackers (low risk) |
| Sequential | s1, s2, s3 | Short, simple | No date context |
| Random | x7k2p | Unpredictable | Hard to reason about |
| Provider | google, mailgun | Per-sender clarity | Doesn't help with rotation |
The five-step rotation
Zero-downtime DKIM rotation
- 01
Generate the new key pair
Generate a fresh 2048-bit RSA key pair on the signer. Most providers expose a UI button; for self-hosted OpenDKIM, use opendkim-genkey.
opendkim-genkey -b 2048 -d example.com -s s2026q2 - 02
Publish the new public key in DNS
Add the new key as a TXT record at
<new-selector>._domainkey.example.com. Do not touch the old selector yet. Verify withdig.dig +short txt s2026q2._domainkey.example.com - 03
Wait at least 48 hours
DNS caches, secondary resolvers, and forwarded mail can lag. Two days is the safe floor; some teams wait a week.
- 04
Switch the signer to the new selector
Update your sending platform or MTA config to sign outgoing messages with the new selector. Send a test through WillItInbox and confirm the signature validates against the new key.
- 05
Retire the old key
After another 48-hour cushion (so any in-flight messages still validate), remove the old TXT record from DNS. Do not delete the private key from your signer until you've confirmed nothing is still using it.
What the published record looks like
| Host | Type | Value | TTL |
|---|---|---|---|
| s2026q2._domainkey.example.com | TXT | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAA...IDAQAB | 3600 |
Key size: 1024 vs 2048 vs 4096
| Bits | Status | Verification | Notes |
|---|---|---|---|
| 1024 | Legacy | Accepted everywhere | Considered weak; some receivers downscore |
| 2048 | Recommended | Accepted everywhere | Modern default |
| 4096 | Overkill | Some DNS resolvers truncate | Often requires multi-string TXT records; verify carefully |
Verifying the rotation
- Send a test message through WillItInbox. The DKIM check shows the signing selector and verification result.
- Inspect raw headers — look for
DKIM-Signature: ... s=s2026q2 ...confirming the new selector. - Read DMARC aggregate reports for the next two weeks. A spike in DKIM failures means a sender wasn't switched over.
Frequently asked questions
Keep reading