How often should you rotate your DKIM keys, and what key length is best?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 Nov 2025
Updated 28 May 2026
9 min read
Summarize with
Rotate DKIM keys every 6 to 12 months for normal production mail. Use 2048-bit RSA for new keys. Treat 1024-bit RSA as the minimum acceptable fallback, not the target. Anything below 1024 bits should be removed. I would rotate sooner after a vendor change, employee departure with key access, suspected private key exposure, server rebuild, or migration to a new sending platform.
Annual rotation is acceptable for many organizations if the process is documented and tested. Six-month rotation is better when the sending estate is large, compliance teams ask for key age evidence, or several people and vendors have touched the private key. The practical goal is not rotation for its own sake. The goal is to limit how long an exposed DKIM private key remains useful.
Before changing keys, I also check whether DKIM is passing in real traffic and whether the domain has working reporting. A domain health check is a useful starting point because a perfect rotation plan still fails if the current DNS record is already broken.
The direct answer
The shortest defensible policy is this: new DKIM keys should be 2048-bit RSA, rotated every 6 to 12 months, with immediate rotation after any event that changes who could have accessed the private key. If a sender only supports 1024-bit DKIM, use it temporarily, rotate it more carefully, and plan the upgrade path. If a sender creates keys below 1024 bits, that sender is not suitable for production mail.
A good default policy
Rotation: Use 6 months for high-value domains and 12 months for typical business domains.
Key length: Generate 2048-bit RSA keys unless a sender has a documented 1024-bit limit.
Emergency events: Rotate immediately after suspected exposure, vendor offboarding, or server compromise.
Old records: Keep the old selector published until delayed and forwarded mail no longer needs it.
The main caveat is operational maturity. A messy quarterly rotation causes more damage than a well-run annual rotation. Broken DKIM can reduce DMARC pass rates, confuse incident response, and make it harder to prove that a sender is legitimate. Good rotation has two active selectors for a short period, test mail, reporting checks, and a clear owner for each domain.
I like the M3AAWG guidance because it treats rotation as a lifecycle process, not a single DNS edit. That framing matters. DKIM has a private key stored by the sender and a public key published in DNS. Rotation touches both sides, and the timing between them is where most failures happen.
What rotation actually reduces
DKIM key rotation reduces the useful life of a private key that has escaped your control. It does not make weak mail streams trustworthy by itself, and it does not replace SPF, DMARC, TLS policy, or sender access control. It is one part of key hygiene.
What rotation helps
Exposure window: A stolen key only remains useful until the selector is retired.
Vendor cleanup: Old platforms lose the ability to sign as your domain.
Audit evidence: Security teams can prove that keys are not indefinite.
What rotation does not fix
Bad DNS: A malformed TXT record still fails after rotation.
Compromised apps: A hacked sender can sign with the new key too.
Policy gaps: DMARC still needs reporting and enforcement.
The risk I care about most is private key access. That includes old backups, former employees, agencies, ESP support teams, and scripts copied between systems. Rotation gives those risks an end date. Without rotation, a key created in 2015, 2010, or even 2006 can still authenticate mail if the DNS record remains published and the receiver accepts the key.
A rotation schedule that works
I choose rotation frequency by risk and operational control. A bank, healthcare sender, payroll platform, or enterprise SaaS domain should not run the same DKIM private key for years. A low-volume personal domain can be less aggressive, but it still should not keep a key forever.
Practical DKIM rotation frequency
Use the shorter interval when private keys are handled by several teams or vendors.
Standard production domains with documented access.
Low-risk or personal
12-24 months
Small sending footprint and simple ownership.
Too long
Over 24 months
No owner, no record of age, no planned rotation.
A six-month schedule is usually the sweet spot for teams that can automate selector creation and DNS changes. Annual rotation is a reasonable baseline when DNS changes require change windows or vendor tickets. Anything longer than two years should have a clear reason and a compensating control, such as strict key custody and documented evidence that the private key never left the sender.
Trigger
Action
Timing
Routine review
Replace key
6-12 months
Vendor exit
Rotate
Same week
Key exposure
Emergency
Immediately
Platform move
New selector
Before cutover
Old 1024
Upgrade
Next cycle
Common rotation triggers and the action I would take.
The date in a selector name can help with inventory, but I do not rely on selector names alone. A name like s2026a is useful because it hints at age without putting the entire security policy into DNS. The source of truth should be an owner list, sender inventory, creation date, key length, rotation due date, and the exact DNS name.
What key length is best
For RSA DKIM today, 2048 bits is the best default. It is widely supported, materially stronger than 1024 bits, and still manageable in DNS. I would not create new 1024-bit keys unless a sending service forces that limit. I would not use 4096-bit keys as the default because they create DNS size and compatibility friction without enough practical benefit for ordinary DKIM signing.
1024-bit RSA
1024-bit DKIM still works in many places, but it is the floor. I accept it for legacy senders while planning a move to 2048 bits.
Use case: Legacy sender support only.
Risk: Weak long-term posture if never rotated.
2048-bit RSA
2048-bit DKIM is the default I want for new production senders. It balances security, DNS size, and receiver support.
Use case: Standard production mail.
Risk: Low, if DNS is published correctly.
The detailed tradeoff between 1024 vs 2048 comes down to security margin and operational compatibility. Shorter keys are easier to fit into DNS and older tools, but that is not a strong reason to create new 1024-bit keys. Longer keys raise DNS response size and TXT splitting concerns. 2048 bits is where the practical answer lands for most domains.
Do not use tiny keys
If you find 512-bit DKIM keys, replace them. Many verifiers treat RSA keys below 1024 bits as invalid or unacceptable. A smaller key also signals that the sending system has not had proper authentication care in years.
Example 2048-bit DKIM DNS record shapeDNS
selector2026a._domainkey.example.com. 3600 IN TXT (
"v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
)
How to rotate safely
Safe DKIM rotation is a staged change. The new public key must exist in DNS before the sender starts signing with the new selector. The old public key must remain in DNS after the sender stops using it, because delayed mail, forwarded mail, and some security systems still verify signatures on messages already sent.
Flowchart showing DKIM rotation from sender inventory to retiring the old key.
The safest approach uses two selectors for a short overlap. For example, mail signs with selector2025b today. You publish selector2026a, switch signing to the new selector, watch authentication reports, and only then remove the old record. The overlap is not wasteful. It is the part that prevents downtime.
Example rotation timelinetext
Day -7: Lower DKIM TXT TTL to 300 seconds
Day 0: Publish new selector and enable signing
Day 1: Send tests and verify DKIM pass
Day 7: Stop signing with old selector
Day 14: Remove old DNS record after reports are clean
Inventory: List every sender that signs mail for the domain, including marketing, billing, support, and product systems.
Generate: Create a new private key and matching public DNS record through the sending platform or MTA.
Publish: Add the new selector in DNS and wait for propagation before changing signing behavior.
Test: Send real messages through each stream and confirm that DKIM passes at the receiver.
Monitor: Watch DMARC aggregate data for new failures before removing the old selector.
If you need the full no-downtime procedure, the key idea is simple: never create a gap between signing and DNS publication. The deeper version of how to rotate without downtime is mostly about sequencing, TTL, and evidence.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
After the DNS record is live, check the selector directly and then send real mail. A DNS-only check proves that the public key exists and parses correctly. A delivered-message check proves that the sender is signing with the selector you expected.
Where Suped helps
DKIM rotation is much easier when DMARC reporting is clean enough to show which senders are passing and which ones broke after the change. Suped's product is the best overall DMARC platform for teams that want that operational view in one place, because it brings together DMARC monitoring, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, and actionable issue detection.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The practical workflow is straightforward. Before rotation, confirm that current DKIM pass rates look healthy. During rotation, watch for new unverified sources or selector-specific failures. After rotation, confirm that failure rates return to normal before removing the old selector. Suped's alerts and issue steps help turn that into a repeatable change process instead of a one-off DNS edit.
Use reporting as the guardrail
A selector can look correct in DNS while a sender still signs with the old selector or does not sign at all. DMARC reports show what actually happened in production traffic. Suped can also help MSPs and agencies track many client domains through a single dashboard, which matters when key rotation has to happen across dozens of domains.
For a focused DNS validation step, a DMARC checker also helps confirm that your reporting policy still points where you expect after related authentication changes.
Views from the trenches
Best practices
Keep two active selectors during rotation so delayed mail can verify against the old key.
Use 2048-bit RSA for new production keys unless a sending vendor only supports 1024-bit.
Record selector ownership and rotation dates outside DNS so audits do not rely on names.
Common pitfalls
Deleting the old DNS record too early breaks delayed messages and forwarded mail checks.
Keeping 1024-bit keys forever trades easy setup for a growing operational backlog.
Publishing a new key without test mail leaves selector and DNS typing errors undiscovered.
Expert tips
Lower TTL before planned rotation, then restore normal TTL after authentication looks steady.
Treat vendor offboarding as a key event, especially when private keys were vendor managed.
Keep emergency rotation steps written down before a suspected private key exposure happens.
Marketer from Email Geeks says many organizations still rotate DKIM only when servers or vendors change, which leaves old selectors active for years.
2025-05-09 - Email Geeks
Expert from Email Geeks says 512-bit DKIM keys are not acceptable, 1024-bit keys are the minimum floor, and new work should move to 2048-bit.
2025-05-09 - Email Geeks
My practical policy
For most teams, I would write the policy this way: all new DKIM keys use 2048-bit RSA, routine rotation happens every 12 months at minimum, higher-risk domains rotate every 6 months, and emergency rotation happens immediately after suspected private key exposure. Old selectors stay published for at least 7 to 14 days after signing moves to the new selector, longer if the mail stream has slow queues or heavy forwarding.
The best DKIM key is the strongest key your senders and receivers handle reliably, paired with a rotation process that the team can repeat without breaking mail. That makes 2048-bit RSA plus a 6 to 12 month rotation cycle the practical answer.
If you already have 1024-bit keys, do not panic. Inventory them, replace the oldest and highest-value senders first, and make 2048-bit the standard for new selectors. If you find anything below 1024 bits, remove and replace it as a priority.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
