Rotate production DKIM keys every six months. Use 2048-bit RSA keys wherever your sending platform and DNS provider support them. Treat 1024-bit RSA as the minimum fallback, not the target. Replace 512-bit and 768-bit keys immediately.
That is the direct answer. The caveat is operational: a broken rotation can damage valid mail, so the right cadence is the one your team can execute cleanly. For most domains, twice a year is the best balance between risk reduction and human workload. High-risk domains, high-volume senders, and teams with automation can rotate quarterly. Annual rotation is better than neglect, but I would not set it as the normal target for business mail.
The reason is simple. DKIM private keys are long-lived signing credentials. If a private key is stolen, copied into a ticket, left in a backup, or taken by someone who once had server access, it can keep producing valid signatures until you stop using that selector and remove trust in the public key. Rotation gives that risk an end date.
Short answer
- Cadence: Rotate every six months for normal production domains.
- Best length: Use 2048-bit RSA for new DKIM keys.
- Minimum: Use 1024-bit only when 2048-bit is not supported.
- Urgent fix: Replace anything below 1024-bit and audit every sender that used it.
The practical rotation schedule
For a normal business domain, I use a six-month DKIM rotation schedule. That matches M3AAWG guidance, which moved its common recommendation to twice yearly because it balances security benefit with operational effort.
The schedule should cover every sending stream, not only the main mail server. Marketing platforms, transactional mail, ticketing systems, billing mail, internal apps, and delegated subdomains all need owners. The weak point in DKIM rotation is rarely the cryptography. It is usually the forgotten sender that keeps signing with an old selector.
|
|
|
|---|---|---|
Core domain | 6 months | Best default for business mail. |
High-risk mail | 3 months | Use when automation is ready. |
Low-volume test | 6-12 months | Do not leave it unmanaged. |
Compromised key | Immediate | Rotate outside schedule. |
Recommended DKIM rotation cadence by sender type.
I do not like annual rotation as a default because it keeps stale keys around for too long and makes the process unfamiliar. When teams rotate twice a year, the steps stay fresh, the DNS owners remember the handoff, and emergency rotation is less likely to turn into a scramble.
Rotation cadence decision guide
A simple way to choose the right schedule for each DKIM signer.
Quarterly
3 months
Use for sensitive mail, automated rotation, or strict internal controls.
Recommended
6 months
Use for most production domains and third-party senders.
Fallback
12 months
Use only for low-risk mail with documented ownership.
Unmanaged
Over 12 months
Treat old unknown selectors as an audit finding.
What key length is best
For RSA DKIM, 2048-bit is the best practical key length today. It has strong security margin and broad support across serious sending infrastructure. Use it for new selectors unless a specific sender cannot publish or use a 2048-bit public key.
A 1024-bit RSA key still verifies in many environments and remains common, but I treat it as a compatibility floor. If a sender is stuck at 1024-bit, tighten rotation, document the limitation, and ask the sender owner when 2048-bit support is available. A 512-bit key has no place in a modern DKIM setup. A 768-bit key is also too weak for business mail.
DKIM RSA key length bands
Use this as a quick triage view when auditing selectors.
Replace now
512-bit
Too weak for modern email authentication.
Replace now
768-bit
Below the minimum I would accept for business mail.
Minimum fallback
1024-bit
Accept only when 2048-bit is blocked by a real constraint.
Best default
2048-bit
Use for new selectors and planned rotations.
DNS record length still matters
A 2048-bit DKIM public key creates a longer TXT record. Good DNS hosts handle this by splitting the value into quoted chunks while returning one logical TXT value. If your DNS panel rejects the value or mangles the quotes, fix the DNS process before you switch signing to the new selector.
Do not confuse public key size with private key handling. A 2048-bit public key reduces cracking risk, but it does not protect a private key that has been copied out of the signer. Limit access, store private keys outside shared tickets and wikis, and rotate immediately when access control is uncertain.
How to rotate DKIM keys without breaking mail
A clean DKIM rotation uses overlap. Publish the new public key first, wait for DNS propagation, switch signing to the new private key, then leave the old public key available long enough for queued and already delivered mail to verify. After that validation window, retire the old key.
Flowchart showing the DKIM rotation sequence.
- Inventory: List every domain, subdomain, selector, signer, and owner.
- Generate: Create a new 2048-bit key pair inside the signing system.
- Publish: Add the new public key as a fresh selector in DNS.
- Wait: Allow DNS caches to see the new TXT record before signing.
- Switch: Start signing new mail with the new selector and private key.
- Retire: Keep the old public key for 7 to 30 days, then empty the key value.
Example selector overlapDNS
dkim1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=OLDKEY" dkim2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=NEWKEY" Current signing selector: dkim1 Next signing selector: dkim2
The overlap is important because DKIM verification can happen after delivery, after queue delays, or during later security review. If you delete the old selector the same day you switch signing, some valid mail loses its DKIM verification path.
Retired selector patternDNS
dkim1._domainkey.example.com TXT "v=DKIM1; p=" dkim2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=ACTIVEKEY"
Selector naming and ownership
Selector naming needs enough structure to support audits, but it should not create confusion. I prefer names that make ownership and sequence clear. Reusing selector names is a bad habit because cached DNS values and old messages can collide with new key material.
Cleaner selector practice
- Unique names: Use a new selector name for each rotation.
- Clear owners: Tie each selector to a mail stream and team.
- Rotation slots: Keep the next selector published before cutover.
Selector patterns to avoid
- Reused names: Old messages and cached DNS can fail later.
- No owner: Nobody knows who can change the signer.
- Stale labels: A date in the selector is useless if no one acts on it.
Some teams include the rotation month or key length in the selector. That can help during audits, but it also makes neglected keys obvious. The real issue is not whether the selector has a date. The issue is whether the date is tied to a working rotation process.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
After each rotation, check a real signed message and inspect the d= domain, the s= selector, and the DKIM pass result together. A DNS-only check proves the record exists. A real message proves the sender is using the expected key.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Where DMARC monitoring fits
DKIM rotation should not be handled as an isolated DNS task. It belongs inside DMARC monitoring because aggregate reports show which sources are sending mail, which ones pass DKIM, and which selectors still appear after a planned cutover.
This is where Suped's product is the strongest practical choice for most teams. It brings DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability signals into one workflow, then turns authentication problems into specific remediation steps. During a rotation, that means you can watch authentication health, find the sender still using an old selector, and act before the issue becomes a deliverability problem.
For a quick baseline before or after a rotation, run the domain health checker and confirm DKIM, SPF, and DMARC are all still clean. If your team wants policy staging and simplified DNS management around broader authentication work, Hosted DMARC is the cleaner path than scattering authentication changes across multiple owners.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
I also treat DKIM key rotation as part of the same operating model as DKIM, SPF, and DMARC practices. If DKIM passes but DMARC fails because the signing domain is wrong, key length will not solve the problem. Authentication has to be checked as a system.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Operational rules I follow
The security benefit of rotation comes from reducing how long a stolen or weak key remains useful. The operational benefit comes from making the rotation process ordinary. If only one person knows how to rotate keys, the process has too much risk even when the keys are strong.
Rotation checklist
- Owner: Every selector has a named technical owner.
- Private key: The key stays inside the signing system and never goes through plain email.
- Evidence: A real post-cutover message is captured and verified.
- Retirement: The old selector is emptied after the validation window.
The biggest practical mistake is deleting the old public key too early. The second biggest is publishing the new key and assuming the signer changed. Always verify actual mail, not only DNS. The third is leaving old selectors active after the window closes.
When a key is suspected to be exposed, skip the normal calendar. Generate a new key, publish it, switch signing as soon as DNS is visible, and retire the old selector after the shortest safe validation window. Then review access logs, backups, deployment systems, and any place the private key passed through.
Views from the trenches
Best practices
Schedule DKIM rotation every six months, with DNS and mail owners assigned before the change.
Keep the old public key live for 7 to 30 days so delayed validation still works cleanly.
Track active selectors by stream so one stale sender cannot hide in aggregate reporting.
Common pitfalls
Leaving 1024-bit keys untouched for years turns a compatibility fallback into lasting risk.
Deleting the old selector too soon breaks verification for mail already delivered or queued.
Putting private keys in tickets or email creates a bigger risk than the rotation solves itself.
Expert tips
Use two or three selector slots so the next public key can sit ready before cutover.
Test one real message after rotation and verify the d=, s=, and pass result together.
Treat provider-managed DKIM as owned work, not a set-and-forget DNS record process.
Marketer from Email Geeks says many organizations only rotate DKIM keys during server replacement, which leaves old selectors active for far too long.
2025-05-08 - Email Geeks
Marketer from Email Geeks says six-month rotation for 2048-bit keys is workable when the process has clear DNS ownership and reminders.
2025-05-09 - Email Geeks
My recommended baseline
Use 2048-bit RSA DKIM keys, rotate them every six months, and keep each old public key available for 7 to 30 days after cutover. That baseline is strong enough for most production domains and realistic enough that teams can actually maintain it.
If you still have 1024-bit keys, do not panic, but do not treat them as permanent. Move them to 2048-bit during the next planned rotation. If you find anything under 1024-bit, replace it as an urgent authentication fix.
Suped's product helps most when the DKIM work is part of a wider authentication program: monitoring, alerts, hosted management, SPF flattening, blocklist (blacklist) visibility, and clear steps to fix issues. Key rotation is not just a DNS edit. It is an email authentication control that needs evidence after each change.
