Most domains publish one DKIM key when they first set up email authentication and never look at it again. That key can sit unchanged for five or six years, signing every outbound message the whole time. Nobody notices until the private key leaks from an old server backup, a former employee's laptop, or a compromised app password — and by then the exposure has been open for years, not days.
DKIM key rotation is the practice of generating a new key pair and switching your domain over to it on a regular schedule, rather than leaving the original key in place forever. Rotating limits how long a leaked or weakened key stays useful to an attacker, and it lets you move up to a stronger key size as defaults change.
What Is DKIM Key Rotation and Why Does It Matter?
DKIM key rotation replaces the private key your mail server uses to sign messages, along with the matching public key published in DNS, on a planned cadence rather than a reactive one. The mechanism matters because DKIM has no built-in expiration: the DKIM spec, RFC 6376, defines how a signature is verified but sets no rule for how long a key may stay in service. That decision is left entirely to the domain owner.
Without rotation, a single leaked private key can sign forged mail as your domain indefinitely, and receiving servers have no way to know the key is compromised until you revoke it. Rotation turns an open-ended risk into a bounded one.
How Often Should You Actually Rotate DKIM Keys?
For most business domains, rotate DKIM keys every 6 to 12 months as routine hygiene, and immediately outside that schedule after any event that could have exposed the private key. The right interval depends on how the key is stored and who has access to it.
| Situation | Recommended cadence | Why |
|---|---|---|
| Key stored on a managed mail platform, few admins | Every 12 months | Lower exposure surface, annual review still catches drift |
| Key stored on a self-managed mail server | Every 6 months | More people and processes touch the server over time |
| After any staff offboarding with server or DNS access | Immediately | You cannot prove the departing person didn't copy the key |
| After a server migration, restore, or backup exposure | Immediately | Old backups routinely contain the private key in plain text |
A shorter interval than six months rarely buys you much extra safety and adds operational risk from more frequent DNS changes. A longer interval than a year means the key has been sitting in one place, unreviewed, for longer than most staff tenures.
What Happens If You Never Rotate Your DKIM Key?
Nothing happens visibly, which is exactly the problem. Mail keeps signing and verifying correctly for years with an unrotated key, so there is no error, no bounce, and no alert to force the conversation. The risk is entirely invisible until the key is misused.
The practical failure mode is a leaked key being used to sign spam or phishing mail that passes DKIM for your domain, which then drags down your DMARC alignment rate and, over time, your sender reputation with mailbox providers. By the time that shows up as a deliverability problem, the leak could be months old.
How Do You Roll Over a DKIM Key Without Breaking Signing?
A DKIM rollover fails when the new key goes live in DNS before it is safe, or the old key gets deleted before every mail queue has moved off it. The fix is to run both keys at once during the transition using two DNS selectors.
- Generate a new key pair and publish the public half under a new selector, for example
dkim2._domainkey.yourdomain.com, leaving the existing selector untouched. - Wait for DNS propagation to complete everywhere, typically 24 to 48 hours, and confirm the new selector resolves from outside your own network.
- Point your mail server's outbound signing configuration at the new selector so new mail signs with the new key.
- Leave the old selector's public key published, unchanged, for at least one full TTL cycle plus a buffer — two weeks is a safe default — so any mail still in flight or replayed from a queue still verifies.
- Remove the old selector's DNS record only after that buffer passes and you have confirmed no signature failures are tied to it.
Skipping the overlap window is the single most common cause of a rollover breaking mail: any message still in a retry queue signed with the old key fails DKIM the moment that key's DNS record disappears.
Does a Bigger DKIM Key Replace the Need to Rotate?
No. Key size and rotation solve two different problems, and upgrading to a 2048-bit key does not remove the need to rotate it later. A larger key makes the signature harder to break by brute force computation; it does nothing to limit how long a leaked or copied private key stays usable if someone already has it.
Think of key size as how hard the lock is to pick, and rotation as how often you change the lock regardless of whether anyone picked it. A domain running a fresh 2048-bit key from three years ago is still exposed to the same leaked-credential risk as one running an old 1024-bit key, because neither has been replaced since it was issued. Teams that upgrade key size once and treat the job as finished are solving half the problem and calling it done.
Tracking selector changes by hand across more than one or two domains is where this breaks down in practice — a missed propagation check or a record removed a day too early is invisible until DMARC reports start showing alignment failures a week later. EmailControl checks your published SPF, DKIM, and DMARC records on a schedule and folds DKIM validity into your domain's health score, so a rollover that leaves a selector unpublished or misconfigured shows up as a score drop before it shows up as bounced mail. The FAQ page covers exactly what each check looks for.
The most common objection to rotating on a schedule is that it feels like unnecessary work for a key that hasn't caused a problem yet. That reasoning is true right up until it isn't, and DKIM gives you no warning signal in between — no expiry date, no deprecation notice, nothing. The actual work is five DNS changes and a two-week wait, done once or twice a year. Compare that to the cleanup after a leaked key has been signing spam under your domain for an unknown number of months, and the rotation is the cheaper option by a wide margin.
Where Do You Start With DKIM Rotation Today?
Check your current DKIM record's age and selector name first — if you don't remember the last time either changed, treat that as your answer. Set a recurring reminder for your chosen cadence from the table above, and monitor the record while you roll it over so a stalled propagation or an early deletion shows up immediately instead of a week later. Add your domain to EmailControl for free and it will check your SPF, DKIM, and DMARC records on a schedule and email you the moment any of the three stops validating.