- DKIM key rotation replaces your signing key pair periodically to limit the damage if a private key is ever compromised, since a stolen key can keep producing valid signatures until you retire it.
- Use 2048-bit RSA keys as the baseline. Replace any key below 1024-bit immediately; 512-bit keys have been cracked cheaply and 1024-bit is now considered weak.
- Rotate every six months for most business domains, quarterly for high-volume or high-risk senders, following M3AAWG guidance. Annual rotation is better than neglect but not ideal.
- Zero-downtime rotation relies on overlap: publish the new key under a new selector, switch signing, then keep the old key published for a drain window before removing it.
- Most rotation failures come from operations mistakes, not cryptography. The classic error is deleting the old DNS record too soon, which breaks in-transit mail signed with the old key.
Here is an uncomfortable fact: a 512-bit RSA DKIM key has been cracked for under 8 dollars in cloud compute. If your DKIM keys are old and undersized, you are one motivated attacker away from someone signing email as your domain. And yet most organizations set up DKIM once, watched it pass, and never touched it again, leaving 1024-bit keys from years ago still in production.
The problem is rarely cryptography. It is organizational: DNS is owned by IT, email signing config lives with the messaging team, and security sets policy but touches neither system, so everyone assumes someone else owns rotation. The result is stale keys that never change. This guide fixes that, covering why rotation matters, the right key length and cadence, and the exact zero-downtime process to rotate without breaking a single message.
Why DKIM Key Rotation Matters
DKIM works by signing outbound mail with a private key, while receivers verify the signature using a public key published in your DNS. The private key is a long-lived signing credential, and that is precisely the risk. If a private key is ever stolen, copied into a support ticket, left in a backup, or taken by someone who once had server access, it can keep producing valid signatures as your domain until you stop using that selector and remove trust in its public key.
Rotation limits that exposure window. By replacing the key pair periodically, you ensure that even an undetected key compromise has a bounded lifespan. The shorter your rotation cycle, the smaller the window in which a stolen key remains useful to an attacker. This is the same logic as rotating any long-lived credential, applied to the cryptographic identity of your mail.
Key Length: Use 2048-Bit
The first rotation decision is key length, and the guidance is clear:
- 2048-bit RSA is the baseline. Use it wherever your sending platform and DNS provider support it. It balances strong security with broad compatibility.
- 1024-bit is the minimum fallback, acceptable only when 2048-bit is genuinely not supported, and treated as a temporary state to upgrade away from, not a target.
- 512-bit and 768-bit must be replaced immediately. They are trivially crackable and represent an active security hole.
For senders who want extra strength, some use 3072-bit RSA, or ECDSA keys, where a 256-bit ECDSA key offers security comparable to 3072-bit RSA with a shorter DNS record. For most senders, however, 2048-bit RSA is the right, well-supported choice. The key practical caution is DNS record length: 2048-bit keys produce a longer public key that may need to be split into multiple strings in some DNS interfaces, which is a formatting detail to handle, not a reason to use a weaker key.
Rotation Cadence: How Often
How often to rotate balances security benefit against operational effort and risk. The consensus guidance:
| Sender Type | Recommended Cadence |
|---|---|
| Most business domains | Every 6 months (twice yearly) |
| High-volume or high-risk senders | Quarterly (every 90 days) |
| Regulated industries (finance, healthcare) | Quarterly, sometimes required |
| After a suspected key compromise | Immediately |
Six months is the common recommendation for normal business mail because it balances risk reduction with human workload. High-volume senders, high-risk domains, and teams with automation can rotate quarterly. Annual rotation is better than neglect, but it keeps stale keys around too long and makes the process unfamiliar, which raises the chance of errors when you finally do it.
The real rule is executability: The best rotation cadence is the one your team can execute cleanly and consistently. A botched rotation can break valid mail, so a reliable six-month process beats an ambitious quarterly schedule that gets skipped or fumbled. If 90 days is too heavy right now, start at 180 days, build the process, and tighten later. A rotation plan you actually run beats an ideal plan that never ships.
Selectors: The Key to Zero-Downtime Rotation
The mechanism that makes safe rotation possible is the DKIM selector. A selector is a label (published as a subdomain prefix in your DNS) that identifies which key should verify a given message. Your DKIM-Signature header includes an s= tag naming the selector, and the receiver looks up the public key at that selector's DNS location.
Selectors enable overlap. Because each key lives at its own selector, you can publish a new key at a new selector while the old key remains live at its old selector. Both are valid simultaneously, which is exactly what allows a transition with no gap in verification. The cardinal rule: never reuse a selector name for a new key generation. Always use a fresh selector for each new key, so the old and new keys coexist cleanly during the transition. Many teams encode the creation date or key length into the selector name to keep header forensics clear.
The Zero-Downtime Rotation Process
With 2048-bit keys and fresh selectors, here is the step-by-step process that rotates without breaking a single message:
- Generate a new key pair (2048-bit RSA preferred).
- Publish the new public key in DNS under a new selector, alongside the existing selector. Both keys are now published.
- Wait for DNS propagation and cache expiry so receivers worldwide can see the new public key.
- Switch your signing configuration to use the new selector and private key.
- Send test traffic and verify that the DKIM-Signature shows the new s= selector value and that Authentication-Results shows dkim=pass for the new key. Confirm in real received headers, not just in theory.
- Keep the old selector published through a drain window, so any mail already in transit (signed with the old key) can still be verified.
- Remove the old selector only after the drain window has passed and all delayed traffic signed with the old key has cleared.
The mistake that breaks mail: The most common rotation failure is deleting the old DNS record the same moment you switch signing. Messages already in transit were signed with the old key, and they need the old public key to verify. If you remove it immediately, those in-transit messages fail DKIM, and under a strict DMARC policy of p=reject they get dropped rather than flagged. Always keep the old key published through a drain window of at least a couple of days, with seven days being a safe conservative choice.
Provider-Specific Gotchas
Two platform details trip up otherwise careful teams:
Microsoft 365
When you trigger DKIM key rotation in Microsoft 365, the new key does not begin signing immediately. Microsoft documents a delay of up to 96 hours before the new key takes effect. Plan for this lag; do not assume the rotation is live the moment you initiate it, and verify with real headers before retiring the old selector.
Google Workspace
In Google Workspace, admins often keep the default selector name forever. That works technically, but operationally you should still introduce distinct selectors over time so that header forensics stay clear and you can tell which key signed a given message. Reusing one selector name indefinitely undermines the traceability that selectors are meant to provide.
Rotate Every Sending Stream, Not Just the Main Server
The weak point in DKIM rotation is rarely the cryptography; it is the forgotten sender that keeps signing with an old, never-rotated selector. Your rotation schedule must cover every system that sends authenticated mail as your domain:
- Your primary mail server
- Marketing platforms and your ESP
- Transactional mail providers
- Ticketing and help desk systems
- Billing and invoicing mail
- Internal applications and delegated subdomains
Each of these has its own DKIM configuration and its own selector, and each needs an owner. A rotation that updates the main server but misses the billing system leaves a stale key in production, which is exactly the exposure rotation is meant to close. Inventory every sending source as part of your rotation planning.
Keep a tiny tracker with four columns: domain, selector, creation date, and next rotation date, plus an owner for each sending stream. This single artifact prevents the most common rotation failures, the forgotten sender, the stale key, the missed schedule, because it makes ownership and timing explicit. Most organizations do not have a DKIM problem; they have a nobody-owns-DKIM problem, and a tracker with assigned owners solves it.
Monitor DMARC Reports During and After Rotation
Rotation is not complete when you switch the key; it is complete when you have confirmed the new key is authenticating correctly in the wild. Monitor your DMARC aggregate reports during and after rotation to confirm that mail signed with the new key is passing DKIM and aligning, and to catch any sending source that is still using the old selector or failing authentication.
The reports will show you, per sending source, whether DKIM is passing after the switch. If a source shows DKIM failures following rotation, you have found a system that did not pick up the new key correctly, and you can fix it before retiring the old selector. Verify your records throughout with a DKIM checker and confirm overall alignment with a DMARC checker. This monitoring step is what turns a hopeful rotation into a verified one, and it ties DKIM rotation into your broader email authentication hygiene.
Frequently Asked Questions
Every six months for most business domains, following M3AAWG guidance, which balances security benefit with operational effort. High-volume senders, high-risk domains, and regulated industries should rotate quarterly. If you suspect a key compromise, rotate immediately. Annual rotation is better than never, but it keeps stale keys around too long. The best cadence is the one your team can execute cleanly and consistently.
Use 2048-bit RSA as the baseline wherever your platform and DNS provider support it. Treat 1024-bit as a minimum fallback only when 2048-bit is not supported, and replace any 512-bit or 768-bit key immediately, since 512-bit keys have been cracked for under 8 dollars in cloud compute. For extra strength, 3072-bit RSA or 256-bit ECDSA are options, but 2048-bit RSA is the right choice for most senders.
Not if done correctly. The key is overlap: publish the new key under a new selector before switching signing, then keep the old key published for a drain window after switching so in-transit messages signed with the old key can still verify. The classic mistake that breaks mail is deleting the old DNS record the same moment you switch keys. Keep the old key live for at least a couple of days, ideally seven.
A DKIM selector is a label published in your DNS that identifies which key verifies a given message; the signature's s= tag names it. Selectors enable zero-downtime rotation because each key lives at its own selector, so you can publish a new key at a new selector while the old one stays live, keeping both valid during the transition. Never reuse a selector name for a new key generation.
Keep the old selector published for a drain window of at least a couple of days, with seven days being a safe conservative choice. Messages already in transit were signed with the old key and need the old public key to verify. Removing it too soon causes those in-transit messages to fail DKIM, which can mean rejection under a strict DMARC policy. Only remove the old selector after all delayed traffic has cleared.