Why is DKIM key rotation recommended, and what key length is secure?
Published 2 Jun 2025
Updated 12 Aug 2026
11 min read
Summarize with
Updated on 12 Aug 2026: We updated this guide with current DKIM algorithm requirements and a safer six-month rotation process.
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 revoked or removed from DNS.
For RSA key length, use 2048 bits as the secure default for DKIM. RFC 8301 sets 1024-bit RSA as the minimum accepted size and recommends at least 2048 bits, so 1024-bit RSA is a standards-compliant floor rather than the right choice for new keys. RSA keys below 1024 bits fail DKIM evaluation. A 4096-bit RSA key creates a longer DNS record with little operational benefit for most DKIM deployments. 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.
Why DKIM key rotation matters
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 recommends rotating at least every six months to limit exposure and keep the emergency process familiar. A tested runbook is more useful during an incident than a process written under pressure.
- Immediate rotation: Rotate after a suspected sender breach, exposed private key, or unauthorized DNS change.
- Scheduled rotation: Rotate important sending domains at least every six months if the platform supports it cleanly.
- Vendor exit: Revoke 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 with its public key.
Practical model
- Assumption: The main threat is key exposure through systems and people.
- Action: Publish a new selector, sign with it, monitor results, then revoke the old key.
- Benefit: A stolen key loses value when the old public key is revoked.
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 for RSA is 2048 bits. It is widely supported, strong enough for the job DKIM does, and small enough to publish reliably in DNS. RFC 8301 requires RSA keys of at least 1024 bits and recommends at least 2048 bits. Do not choose 1024 bits for a new selector unless the sender cannot support 2048 bits, and document the replacement path when that limitation exists.
DKIM RSA key length guidance
A practical operating view for common RSA DKIM key sizes.
Invalid
512-bit RSA
RFC 8301 requires verifiers to treat RSA keys below 1024 bits as failed.
Minimum
1024-bit RSA
Standards-compliant floor, 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
A longer DNS record with 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, and signatures made with RSA keys below 1024 bits must fail DKIM evaluation. A 2048-bit RSA key 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 | Invalid | Revoke and replace immediately. |
1024 | Minimum | Plan a move to 2048. |
2048 | Default | Best fit for most domains. |
4096 | Selective | Test DNS handling first. |
Use this as a decision table, not as a cryptographic proof.
Check the algorithm as well as key length
Key length only has meaning inside an algorithm. For RSA DKIM, RFC 8301 requires at least 1024 bits, recommends at least 2048 bits, and requires rsa-sha256. It makes rsa-sha1 invalid for signing and verification. A 2048-bit RSA key paired with rsa-sha1 is not a current DKIM configuration.
Ed25519-SHA256 is also standardized for DKIM. Its 256-bit key is not comparable to a 256-bit RSA key, so the RSA key-length table does not apply to it. If a signer supports Ed25519, use a separate selector and keep a 2048-bit RSA-SHA256 signature during the transition while you confirm verification across real recipient traffic. A second algorithm does not remove the need for rotation or private-key protection.
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 revokes the old public key.
Selector patterntext
old2025._domainkey.example.com TXT "v=DKIM1; k=rsa; p=OLD..." new2026._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. Revoking 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: Check live headers for the new selector, then watch DKIM pass rates and DMARC results.
- Retire: After a 7 to 30 day overlap, revoke the old key by publishing an empty p= value, then remove the selector later if policy requires it.
Before retiring 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
Keep the old key available for at least seven days and up to 30 days after the signer changes, following M3AAWG guidance. The window must also exceed the relevant DNS TTL and allow delayed or forwarded mail to clear. Use the longer end for high-volume operational mail. If the old selector still appears in newly generated DMARC reports after the cutover, a source is still signing with it.
Common rotation mistake
Do not revoke 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 revoke old.
- Rollback path: Keep the old signer configuration available until the new selector is stable.
Where Suped fits
Suped's product covers the part of DKIM rotation that is hardest to manage by hand: confirming 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
The practical workflow in Suped is to baseline authentication, publish the new selector, and use source-level DMARC monitoring to compare selector use and pass rates during the overlap. Once reports show that expected sources use the new selector and the old selector no longer appears on fresh mail, retire the old key.
- Baseline: Record current selectors, sources, and DKIM pass rates before changing DNS.
- Validation: Confirm that each expected source moves to the new selector.
- Alerts: Investigate DKIM or DMARC failures that start during the overlap.
- Retirement: Use fresh report data to decide when the old key can be revoked.
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
Practical recommendation
Use 2048-bit RSA-SHA256 for DKIM, rotate selectors at least every six months, 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 revoke the old key after a 7 to 30 day overlap. Replace 1024-bit selectors during the next planned rotation. Revoke RSA selectors below 1024 bits immediately.
Recommended default
For most domains, use 2048-bit RSA-SHA256, rotate at least every six months, rotate immediately after suspected exposure, and review DMARC data throughout the change.
