How to rotate DKIM keys in production without breaking signatures. Dual-selector strategy, 2048-bit key sizes, and the rotation cadence that actually works.
Why DKIM Keys Need to Rotate
DKIM (DomainKeys Identified Mail) signs outbound messages with a private key. The receiver retrieves the public key from DNS and verifies the signature. As long as the signature validates, the receiver knows the message was authorized by whoever controls the private key.
The integrity of that scheme depends on the private key staying private. Three things put it at risk over time.
Compromise. Servers get breached. Backups leak. Configuration management systems get exfiltrated. A DKIM private key that lived on a server for five years has been on that server through every change, every contractor, every incident response. The longer it sits, the higher the chance it has leaked.
Cryptographic decay. The 1024-bit RSA keys that dominated DKIM deployments through the 2010s are no longer considered cryptographically strong. Industry consensus has moved to 2048-bit minimums. Domains running 1024-bit keys today are using a signing strength that was downgraded by NIST and academic recommendation years ago.
Operational hygiene. Even without compromise or weakness, rotating keys is a forcing function for ensuring the rotation process actually works. The first time you rotate keys is the worst time to discover that your selector configuration is broken or that a third-party signer has lost track of where its keys are published.
The cost of rotation is low. The cost of not rotating, when the moment comes that you need to, is high. Most senders never rotate. The senders who do are the ones who have been through an incident.
How DKIM Selectors Work
A DKIM signature includes a s= parameter naming the selector. The selector is a label that identifies which of potentially many keys was used to sign the message.
For a message signed by mail.yourbrand.com:
DKIM-Signature: v=1; a=rsa-sha256; d=mail.yourbrand.com; s=selector1;
bh=...; h=From:To:Subject:Date; b=...The receiver retrieves the public key from:
selector1._domainkey.mail.yourbrand.com TXT "v=DKIM1; k=rsa; p=MIGfMA0..."The selector format is <name>._domainkey.<sending-domain>. The name is arbitrary—selector1, mail2024, s1, google are all valid. The convention is to use names that signal purpose or rotation date.
Critically: a domain can have multiple selectors live at the same time. Publishing selector1._domainkey.yourbrand.com and selector2._domainkey.yourbrand.com simultaneously is not just allowed, it is the foundation of safe key rotation.
The Dual-Selector Rotation Strategy
The pattern that actually works in production:
- Generate the new key pair offline.
- Publish the new public key in DNS under a new selector.
- Wait for DNS propagation (24-48 hours to be safe).
- Switch your signing infrastructure to use the new key/selector.
- Wait for in-flight mail with the old signature to drain (7-14 days).
- Remove the old selector from DNS.
The key insight: at every step, both selectors are valid. Mail signed before the switch verifies via the old selector. Mail signed after the switch verifies via the new selector. There is never a moment where in-flight mail fails authentication because of the rotation itself.
Compare this to a "stop and replace" approach delete the old key, generate a new one, publish it, restart the signer. Any message in flight during that window has a signature whose public key is no longer in DNS. It fails verification. DMARC fails (if SPF does not align). The message is treated as unauthenticated.
The dual-selector approach has no such gap. It is also the only approach that can be done during business hours without any user-visible impact.
Step 1: Generate the New Key
Generate offline, on a trusted machine. Most ESPs and signing services do this for you, but if you are running your own signer:
openssl genrsa -out dkim-2024-09.private 2048
openssl rsa -in dkim-2024-09.private -pubout -out dkim-2024-09.publicTwo notes:
- Always 2048 bits. 1024-bit keys are still functional but should not be deployed for new rotations. Larger keys (4096-bit) provide marginal additional security at the cost of longer DNS records, which can run into TXT-record-length issues on some DNS providers.
- Name the file by rotation date.
dkim-2024-09.privatetells you immediately when this key was generated. After three rotations, you will appreciate the naming.
Format the public key for DNS:
openssl rsa -in dkim-2024-09.private -pubout -outform DER 2>/dev/null | openssl base64 -AThe output is the p= value for your DNS record.
Step 2: Publish the New Selector
Choose a selector name. Date-based names work well:
2024sept._domainkey.yourbrand.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."The v=DKIM1 is required. The k=rsa is the default and can be omitted but is conventional. The p= value is the base64-encoded public key from Step 1.
Publish the record. Verify with dig:
If you see the record, DNS is good. If not, give it a few minutes for caches to clear and retry.
Step 3: Wait for DNS Propagation
DNS propagation is usually fast in 2024 (most TLDs and providers respect TTLs strictly), but mailbox providers cache aggressively. Waiting 24 hours after publishing the new record before switching the signer is conservative. 48 hours is safer.
The reason: a receiver that cached "no record exists at this name" 30 minutes before you published it may still hold that cache for the duration of the TTL. If you switch your signer immediately, those receivers will fail verification on every message until their cache expires.
Step 4: Switch the Signer
Update your signing configuration to use the new selector and private key. This is provider-specific:
- Self-hosted (OpenDKIM, Rspamd): Update the configuration file pointing to the new selector and key path. Reload the signer.
- SendGrid, Mailgun, Postmark, etc.: Add the new selector via the dashboard, switch the active key, verify with a test send.
After the switch, every new message signs with the new key. Old messages that have already left your infrastructure carry the old signature, but the old selector is still in DNS, so they verify normally.
Step 5: Drain Period
Mail that was sent just before the rotation can still be in transit greylisted, queued at the recipient's MX, sitting in a forwarder's outbound queue. It can also be sitting in mailing list archives, in mail clients that re-verify on display, or in security gateways doing retroactive analysis.
Wait at least 7 days, ideally 14, before considering the old selector removable. For high-volume senders, 14 days is the norm. For senders that interact heavily with mailing lists or archives that re-verify, 30 days is reasonable.
During this period, both selectors are live in DNS. There is no operational issue with this state. It is the correct state during transition.
Step 6: Remove the Old Selector
After the drain period, remove the old DNS record:
2023march._domainkey.yourbrand.com (deleted)Verify with dig:
Expected: empty result. If a result still appears, your DNS provider has caching or your record removal did not propagate. Investigate before considering the rotation complete.
The Five Mistakes Senders Make
These are the failure patterns I see in customer audits when DKIM rotation goes wrong.
1. Removing the old selector too soon. A sender rotates on Monday, removes the old selector on Wednesday. Mail still in flight with the old signature fails verification. DMARC fails for those messages. Some go to spam. Some are rejected outright. The sender does not understand why their bounce rate spiked for two days. The fix: never remove a selector less than 7 days after the rotation.
2. Signing with a key whose public counterpart is not yet published. A sender generates the new key and updates the signer first, then realizes they forgot the DNS step. For the entire window between signing change and DNS publication, every outbound message fails DKIM. The fix: DNS first. Always. The signer cannot use the new key until DNS has propagated.
3. Insufficient key entropy. Less common in 2024 but still occurs with self-hosted setups using outdated tooling or VMs without sufficient entropy at first boot. A weak key is mathematically vulnerable; an attacker with enough samples could potentially derive the private key from public signatures. The fix: use modern OpenSSL (1.1.1+ or 3.x), generate keys on machines with sufficient entropy, and rotate to 2048-bit minimum.
4. Forgetting mailing list archives. Some mailing lists archive messages and serve them via a web interface. Some security gateways re-verify signatures retroactively on stored messages. If you remove a selector that messages in those archives reference, they fail verification on every retrieval. This is mostly cosmetic the messages still display but it can trigger false-positive alerts in monitoring systems. The fix: extend the drain period for senders heavily involved with archived lists.
5. Never rotating because "it has been working fine." The most common pattern. The DKIM key was set up in 2018, has not been touched, and signs every message. The team responsible has rotated through three iterations of personnel. Nobody knows where the private key file is or who has access to it. The first rotation in this state is high-risk because the institutional knowledge required to perform it has decayed. The fix: rotate proactively, on a calendar schedule, even when there is no specific reason to. The first rotation establishes the muscle memory; subsequent rotations are routine.
Rotation Cadence
How often should you rotate?
Annual rotation is the minimum. Once per year, replace the key. This is the bare minimum for keeping institutional knowledge current and detecting any silent operational issues.
Six-month rotation is recommended. For domains sending significant volume or handling sensitive content (financial services, healthcare, government), twice yearly is the operational norm. The slight overhead of an additional rotation pays off in resilience.
Quarterly rotation for high-stakes domains. Banks, payment processors, and other high-value targets sometimes rotate quarterly. The operational cost is real each rotation requires DNS work, signer config changes, and a drain period but the security posture is correspondingly stronger.
Never set up a rotation system that requires manual work. Calendar-driven manual rotations get skipped. Automate the rotation through your DNS provider's API, your secrets manager, and your signer's configuration management. The first rotation is manual; every subsequent rotation should be a documented, automated process.
Working with Third-Party Signers
If your ESP signs on your behalf, the rotation process is partially out of your hands. The pattern remains the same dual selectors, drain period but the operational steps differ.
For most major ESPs, the process is:
- The ESP generates the new key in their infrastructure.
- The ESP provides you the public key (or the CNAME record pointing to their managed selector).
- You publish the public key (or CNAME) in your DNS.
- After verification, the ESP switches the active signing key.
- You continue to publish both keys for the drain period.
- After the drain, you can remove the old DNS record.
The risk in this model is that you do not control the timing of step 4. If the ESP switches before you have published the new record, mail fails. Coordinate the rotation with your ESP's support team for high-volume sends.
Frequently Asked Questions
Should I rotate keys after a security incident?
Can I have more than two selectors active at once?
What if my DNS provider does not support TXT records longer than 255 characters?
Are 4096-bit keys worth using?
How does rotation interact with BIMI?
What happens if I rotate during a campaign send?
Key Takeaways
- DKIM keys should be rotated at least annually, ideally every six months.
- Use the dual-selector strategy: publish the new key under a new selector, switch the signer, drain for 7-14 days, then remove the old selector.
- DNS first. Always. Never switch the signer to a key whose public counterpart has not yet propagated.
- 2048-bit keys are the modern standard. 1024-bit is functional but no longer considered cryptographically strong.
- Date-based selector names (2024sept, 2025q1) make the rotation history self-documenting.
- The rotation process should be automated. Manual calendar-driven rotations get skipped.
- Third-party signers add coordination complexity. Pre-arrange the timing with your ESP for high-volume domains.
The first DKIM key rotation is uncomfortable. The tenth is a checklist. Get to the tenth.
Related articles
Deliverability Incident Response: A Playbook for the First 4 Hours
When email reputation collapses, the first 4 hours determine the recovery timeline. Triage, containment, communication the operational playbook teams actually need.
List Hygiene Beyond Bounces: Engagement-Based Suppression Strategies
Bounce-based list cleaning is decades behind modern deliverability. The 90/180/365-day engagement model, sunset policies, and re-engagement that actually works.
Blocklist Remediation Playbook: Spamhaus, SORBS, and UCEPROTECT
How to remove your IP or domain from Spamhaus, SORBS, UCEPROTECT, and other blocklists. Which lists matter, which to ignore, and the delisting process for each.