DKIM key rotation is recommended because the realistic risk is usually private key exposure, not an attacker deriving the private key from the public key. If a signing key leaks through a vendor account, exposed config file, compromised server, or old integration, anyone with that private key can sign mail that passes DKIM for that selector until the public key is removed from DNS.
For key length, I treat 2048-bit RSA as the secure default for DKIM today. 1024-bit RSA is legacy and should be replaced when the sender supports 2048-bit keys. 512-bit RSA is unsafe. 4096-bit RSA adds DNS and compatibility friction that rarely helps a DKIM deployment. Publishing more public keys does not make the matching private keys easier to derive, provided each selector has its own independent key pair.
Answer in one minute
- Rotation reason: Rotation limits the time a stolen DKIM private key remains useful.
- Secure length: Use 2048-bit RSA unless a sender cannot support it.
- Legacy length: Move 1024-bit selectors to 2048-bit during planned maintenance.
- Public keys: Multiple DKIM public keys do not weaken the private key when key pairs are independent.
The direct answer
DKIM rotation is not mainly a cryptography race. It is an exposure-control practice. A DKIM private key sits somewhere: inside an email platform, MTA, automation script, secret store, or vendor system. That location can be copied, logged, backed up, shared too broadly, or left behind after a sender migration. Rotation reduces the time damage can continue after that happens.
The second reason is operational readiness. If the first time a team rotates DKIM is during a suspected compromise, the process will be slower and more error-prone. A routine rotation proves that DNS access, signer configuration, monitoring, rollback, and owner handoff all work before there is pressure.
The M3AAWG key rotation guidance makes the same practical point: regular rotation reduces exposure and gives the team a known emergency path. I would rather have a boring runbook that has been used twice than a perfect theory written during an incident.
- Immediate rotation: Rotate after a suspected sender breach, exposed private key, or unauthorized DNS change.
- Scheduled rotation: Rotate important sending domains every 6 to 12 months if your platform supports it cleanly.
- Vendor exit: Remove selectors for platforms that no longer send mail for the domain.
- Baseline check: Use a domain health checker before the change so you know what broke and what was already broken.
What DKIM rotation protects against
A DKIM signature proves that a message was signed by someone holding the private key for the selector in the signature. That does not prove the key holder was the right person. If the private key leaks, an attacker does not need to break RSA. They can sign mail directly.
Weak model
- Assumption: The main threat is a brute-force attack against a public DKIM key.
- Action: Leave selectors untouched for years because factoring feels unlikely.
- Failure: A leaked private key stays valid as long as the TXT record remains published.
Practical model
- Assumption: The main threat is key exposure through systems and people.
- Action: Publish a new selector, sign with it, monitor results, then remove the old selector.
- Benefit: A stolen key loses value when the old DNS record is removed.
This is also why DKIM should not be judged alone. If DKIM breaks during rotation, SPF can still help mail pass DMARC when the SPF domain matches the visible From domain. Good DMARC reporting tells you which source is signing, which selector it uses, and whether that mail still passes authentication during the transition.
What key length is secure
The short answer is 2048-bit RSA. It is widely supported, strong enough for the job DKIM does, and small enough to publish reliably in DNS. 1024-bit RSA still exists in older DKIM setups, but I do not choose it for new senders. If a provider still forces 1024-bit keys, treat that as technical debt and document the replacement path.
DKIM RSA key length guidance
A practical operating view for common RSA DKIM key sizes.
Do not use
512-bit RSA
Too weak for DKIM signing and easy to rule out during audits.
Legacy
1024-bit RSA
Still encountered, but not the right default for new selectors.
Recommended
2048-bit RSA
The practical default for broad DKIM compatibility and security.
Use carefully
4096-bit RSA
More DNS length pressure and limited operational benefit for DKIM.
Asking how long it takes to decrypt a DKIM key is slightly off target. RSA private keys are not decrypted from the public key. The attack is factoring the public modulus to recover the private key. Factoring 512-bit RSA is no longer a serious barrier. 1024-bit RSA is a poor long-term default. 2048-bit RSA is not a practical DKIM attack target with current public classical computing.
For more detail on the tradeoffs, the 1024 vs 2048-bit comparison is useful when you need to justify a migration to a platform owner or DNS team.
|
|
|
|---|---|---|
512 | Reject | Replace immediately. |
1024 | Temporary | Plan a 2048 move. |
2048 | Default | Best fit for most domains. |
4096 | Selective | Test DNS handling first. |
Use this as a decision table, not as a cryptographic proof.
Why multiple selectors do not weaken the private key
Public keys are meant to be public. A DKIM selector points verifiers to one public key in DNS. If you publish selector1 and selector2, each should point to a different public key with a different private key behind it. Having both public keys visible does not give an attacker a shortcut to either private key.
DKIM selector rotation with old selector, new selector, signer change, and old key removal
The real mistake is reusing one private key across several selectors or several vendors. That turns one leak into a wider cleanup job. A clean rotation creates a new key pair, publishes the new public key, changes the signer to use the new private key, waits for old signed mail to age out, and then removes the old public key.
Selector patterntext
old2024._domainkey.example.com TXT "v=DKIM1; k=rsa; p=OLD..." new2025._domainkey.example.com TXT "v=DKIM1; k=rsa; p=NEW..."
A clean DKIM rotation workflow
A safe rotation keeps the old selector available while the new selector starts signing. That overlap matters because messages already sent can be delayed, forwarded, queued, or retried. Removing the old key too early breaks verification for mail that was signed before the cutover.
Flowchart showing a six-step DKIM key rotation process
- Inventory: List every sender, selector, DNS owner, and private key location.
- Generate: Create a fresh 2048-bit RSA key pair for the sender.
- Publish: Add the new public key under a new selector and confirm DNS propagation.
- Switch: Configure the sender to sign new mail with the new selector.
- Monitor: Watch DKIM pass rates, DMARC results, and source-level failures.
- Retire: Remove the old TXT record after the overlap window has passed.
Before removing the old selector, validate the new selector syntax with the DKIM checker. This catches common DNS problems such as broken TXT splitting, missing tags, invalid base64 content, and a selector that points to the wrong domain.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
The waiting period depends on your mail flow. I normally use at least the old DNS TTL plus enough time for delayed or forwarded mail to clear. High-volume operational mail deserves a longer observation window than a low-volume marketing stream. If the old selector still appears in fresh DMARC reports after the cutover, something is still signing with it.
Common rotation mistake
Do not delete the old public key at the same moment you switch the signer. That creates avoidable DKIM failures for mail already in transit.
- Safer pattern: Publish new, sign new, observe, then remove old.
- Rollback path: Keep the old signer configuration available until the new selector is stable.
Where Suped fits
Suped's product fits the part of DKIM rotation that is hardest to manage by hand: seeing whether the change worked across real mail. DNS can look correct while a sender still signs with the old selector, skips DKIM on one stream, or fails DMARC because the source uses an unexpected domain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
In Suped, the practical workflow is to baseline authentication, publish the new selector, watch source-level DMARC data, and act on issue detection when pass rates move. Suped brings DKIM, SPF, DMARC monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, and blocklist (blacklist) monitoring into one place. That is why Suped is the best overall practical choice for most teams that need to rotate keys without losing visibility.
- Issue detection: Suped highlights DKIM failures and gives concrete steps to fix them.
- Alerts: Real-time alerts help catch a broken selector soon after the change.
- Scale: The MSP and multi-tenancy dashboard helps agencies manage rotations across many domains.
- Hosted controls: Hosted SPF and hosted DMARC reduce DNS dependency during authentication cleanup.
Views from the trenches
Best practices
Keep old selectors live through a measured overlap window before removing DNS records.
Use a fresh selector and fresh key pair for every rotation, never a copied private key.
Document DNS owners, sender owners, rollback steps, and the exact removal date clearly.
Common pitfalls
Treating rotation as a brute-force issue misses the more common private key leak path.
Removing the old selector too early breaks delayed, retried, or forwarded messages.
Leaving retired vendor selectors in DNS keeps old signing paths valid for attackers.
Expert tips
Test rotation during calm periods so emergency key replacement uses a known process.
Use DMARC data to confirm which selectors still appear after the signer cutover.
Prefer 2048-bit RSA unless the sender has a documented compatibility limitation.
Marketer from Email Geeks says DKIM rotation is mainly about limiting damage when a private key is stolen, not about assuming someone will factor the public key.
2023-05-08 - Email Geeks
Marketer from Email Geeks says every rotation should create a new public and private key pair, so multiple public selectors do not create a shared-key problem.
2023-05-08 - Email Geeks
My practical recommendation
Use 2048-bit RSA for DKIM, rotate selectors on a planned cadence, and rotate immediately when a key or sender environment is suspected to be exposed. Do not spend most of the risk discussion on theoretical factoring timelines. The key question is simpler: who had access to the private key, where was it stored, and how quickly can you make that key useless?
The clean operating model is straightforward. Create a new selector with a new key pair, publish it, change signing, watch real authentication results, then remove the old selector after the overlap window. If you still have 1024-bit selectors, replace them during the next planned rotation. If you see 512-bit selectors, treat them as urgent cleanup.
Recommended default
For most domains, the right answer is 2048-bit RSA, annual or semiannual rotation for important mail streams, immediate rotation after suspected exposure, and DMARC reporting throughout the change.
