DKIM Key Rotation
Periodically replacing the private key behind a DKIM selector.
Selectors let a new key go live without touching the old one.
Definition
Key rotation is the practice of periodically replacing the private key behind a DKIM selector with a new one, so a leaked or aging key can’t be used to forge signed mail from your domain indefinitely. Because each DKIM selector signs independently, publishing a new key under a new selector never invalidates mail signed under an older one.
We verify billions of email addresses, and authentication health is one of the first things we read on any sending domain. A DKIM key is a permanent-feeling piece of infrastructure right up until the day it isn’t, and key rotation is the discipline that keeps a single aging or leaked key from becoming an open door into your domain’s reputation. Here is what key rotation actually is, why it can be done safely, what happens during one, and how often to do it.
What key rotation is
Key rotation is the practice of generating a new DKIM key pair and putting it into service in place of an older one, on purpose, before the old key becomes a problem rather than after. The private half signs outgoing mail and never leaves your sending infrastructure. The public half is what changes hands, published openly in DNS for any receiver to fetch and verify against.
The reason rotation matters is entirely about exposure over time. A key that has been in continuous use for years has simply had more chances to leak — through a compromised server, a stale backup, a departed vendor’s credentials — than one that gets swapped out on a schedule. If a private key is ever exposed, whoever holds it can produce a DKIM signature that passes for your domain, which is precisely the authenticated look a phishing campaign needs to slide past filters and past DMARC. Rotation is how you cap how long that risk can sit unaddressed.
Why DKIM selectors make rotation safe
The mechanism that makes any of this workable without breaking mail is the DKIM selector. Every signature names the exact selector used to produce it, and that selector points to one specific DNS TXT record holding one specific public key. A domain isn’t limited to one selector. It can publish as many as it needs, each independent of the others.
That independence is what lets rotation happen without any backward damage. A message signed under selector1._domainkey.yourdomain.com last year is still verified against that exact record, whether or not you have since moved on to selector2. Nothing about publishing a new selector or retiring an old one reaches back and touches how already-sent mail is checked. It is the same reason a single domain can run separate selectors for its DKIM-signing marketing platform, CRM, and transactional sender at once, without any of them interfering with each other.
How a rotation actually works
A rotation is a short overlap, not an instant swap, and the order of operations is what keeps it from breaking anything.
- Generate a new key pair under a fresh selector name and publish the new public key as a DNS
TXTrecord, alongside the existing one, not in place of it. - Wait for DNS propagation. Both the old and new selectors are now valid and resolvable at the same time, which is the whole point.
- Switch your sending infrastructure to sign new outgoing mail with the new selector, and confirm it is actually passing DKIM before moving on.
- Retire the old selector’s DNS record only after a safe overlap window, once you are confident nothing is still signing with it.
Cutting the old record too early, before propagation has caught up everywhere or before every sending system has actually switched over, is the mistake that turns a routine rotation into a deliverability incident: mail signed with a selector that no longer resolves simply fails DKIM.
How often to rotate
There is no protocol-mandated expiry on a DKIM key. It will keep working correctly for as long as you leave it alone, which is exactly why rotation has to be a deliberate habit rather than a reaction to something breaking. Most teams settle on a routine cadence somewhere between six and twelve months, generating a new selector on a calendar rather than waiting for a reason.
The one case that overrides any schedule is a suspected compromise. If there is any reason to believe a private key has been exposed, rotate immediately rather than waiting for the next cycle: publish the new selector, cut over as fast as propagation allows, and pull the old record the moment the overlap window closes instead of leaving it live out of caution. Plenty of email providers and ESPs will rotate keys for you automatically on their own schedule. If yours doesn’t, it is worth putting a recurring reminder on the calendar rather than letting the same key quietly age for years.
Common questions
Key rotation, answered
A DKIM key that never changes is a key that’s had years to leak. Here’s how rotation works, and how often you actually need to do it.
How often should you rotate a DKIM key?
Most teams land somewhere between every six and twelve months for routine rotation. There is no protocol requirement forcing a cadence. The interval is a risk decision that trades operational overhead against how long a key sits around as a potential liability if it is ever quietly exposed.
Plenty of well-run domains rotate annually and never have an incident. What matters more than the exact number is having a cadence at all, on a calendar, rather than a key that has been untouched since the day DKIM was first configured.
Does rotating a DKIM key break mail you already sent?
No. A message’s DKIM-Signature header names the exact selector used to sign it, and that selector’s public key stays published in DNS until you choose to remove it. A receiver re-verifying an old message still fetches the old key and still gets a valid pass.
Rotation only changes what selector new outgoing mail signs under going forward. Nothing about a rotation reaches backward and invalidates a signature that already left your servers.
What happens if you never rotate your DKIM key?
Nothing happens immediately, which is exactly why it gets neglected. DKIM keeps working correctly on a key that is years old. There is no expiry built into the protocol. The risk is not a functional failure. It is exposure sitting around unaddressed.
A private key that has been in continuous use for years has had more opportunities to leak through a compromised server, a careless backup, or a departed vendor than one rotated on a schedule. If it ever does leak, an old, never-rotated key gives an attacker a much longer runway to forge DMARC-aligned mail before anyone notices.
How do you actually rotate a DKIM key?
Generate a new key pair under a fresh selector name, publish the new public key as a DNS TXT record alongside the existing one, and wait for DNS propagation before doing anything else. Both selectors are now live and valid at the same time.
Once the new record has propagated, switch your sending infrastructure to sign with the new selector, confirm outgoing mail is passing DKIM under it, and only then retire the old selector after a safe overlap window. Cutting the old record too early, before propagation finishes everywhere, is the mistake that actually breaks mail.
What should you do if a DKIM key is compromised?
Rotate immediately rather than waiting for the next scheduled cycle. A compromised private key lets whoever holds it produce signatures that pass DKIM for your domain, which is exactly the authenticated look phishing mail needs to slip past filters and past a DMARC check.
Publish the new selector, cut over signing as fast as propagation allows, and pull the old selector’s record the moment the overlap window closes rather than leaving it live out of caution. With a suspected compromise, the old key is the liability, not the safety net.
Is key rotation the same as changing your DKIM selector?
They are two names for the same move, looked at from different angles. You cannot rotate a key without a new selector to publish it under, since a selector is simply DKIM’s label for “which DNS record holds the key for this signature.”
“Rotation” describes the goal, replacing an aging key. “New selector” describes the mechanism that makes it possible without a gap in coverage. Every real rotation involves a new selector. Not every new selector is a rotation, since teams also add selectors to give a new sending platform its own key.
Does rotating a DKIM key affect SPF or DMARC?
Not directly. SPF checks which servers are authorized to send, which has nothing to do with DKIM keys or selectors, so a rotation leaves it untouched. DMARC sits on top of both and just needs at least one of SPF or DKIM to pass with alignment.
A DKIM rotation only threatens DMARC indirectly, if the cutover is botched and outgoing mail briefly signs with a selector that is not yet resolvable in DNS. That gap is what a post-rotation check on the DMARC, DKIM, and SPF checker is meant to catch before it costs you deliverability.
Can a botched key rotation hurt deliverability?
Yes, if the old selector is retired before every sending system has actually switched over, or before DNS has fully propagated the new record. Mail signed with a selector that no longer resolves fails DKIM outright, and if DMARC is set to quarantine or reject, that mail can land in spam or get bounced.
The fix is simply sequencing: publish new, wait, cut over, verify, retire old, in that order, never faster. Confirming outbound mail is still authenticating cleanly after the switch is worth a few minutes with the email verification tooling rather than assuming the cutover went smoothly.