Why is DKIM key rotation recommended, and what key length is secure?

Published 2 Jun 2025

Updated 20 Oct 2026

13 min read

Summarize with

Envelope, DNS tag, and key pair illustrating DKIM key rotation and secure key length

Updated on 20 Oct 2026: We clarified DKIM key-length requirements, provider-managed rotation, and when to revoke old keys.

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 while verifiers can retrieve or still cache the old public key. Revocation stops that key from validating once cached copies expire.

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. The private key 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. DKIM itself does not prescribe a fixed rotation interval or an automatic key expiration date.

Immediate rotation: Rotate after a suspected sender breach, exposed private key, or unauthorized DNS change.
Scheduled rotation: Rotate active DKIM signing keys at least every six months. Use a shorter cycle when your security policy requires it, and confirm the platform's rotation schedule.
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 stops validating after revocation reaches verifiers and cached public keys expire.

This is also why DKIM should not be judged alone. If DKIM breaks during rotation, SPF can still make DMARC pass when SPF passes and the authenticated MAIL FROM domain meets the visible From domain's alignment requirement. Under DMARC, relaxed alignment permits domains within the same organizational domain; strict alignment requires an exact match. DMARC reporting helps identify signing sources and selectors, while trusted recipient headers confirm live authentication results.

What DKIM 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 signing keys of at least 1024 bits and recommends at least 2048 bits. Verifiers must support RSA keys between 1024 and 4096 bits, so 4096-bit RSA is within the standard's required verification capabilities. 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

Below 1024-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

Within required verifier support; confirm sender support and DNS handling before use.

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.

A 2048-bit public key normally exceeds one DNS TXT character string's 255-octet limit. Split it into multiple strings within one TXT record when the DNS provider requires this; verifiers join the strings without adding spaces. RFC 6376 requires strings in a single TXT record to be concatenated. Do not publish multiple DKIM key records under the same selector or downgrade to 1024 bits to work around a DNS editor limitation.

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.

RFC 8463 standardizes Ed25519-SHA256 for DKIM. Its 256-bit key is not comparable to a 256-bit RSA key, so the RSA key-length guidance 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: publish a new key, switch signing, and retire the old selector

The real mistake is reusing one private key across several selectors or several vendors. That turns one leak into a wider cleanup job. A manually managed 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. Use a fresh selector rather than overwriting an active selector's public key, because cached keys can cause verification failures.

Illustrative selectors with placeholder public keystext

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 scheduled 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. This is an overlap of published public keys; signing every message with both keys is optional.

DKIM key rotation workflow: generate a key, publish DNS, switch signing, monitor, wait, and retire

Inventory: List every signing domain (d=), selector (s=), sender owner, DNS owner, and private key location. Record rotation and revocation dates.
Generate: Create a fresh 2048-bit RSA key pair for the sender. Restrict private key access to the signer; publish only the public key in DNS.
Publish: Add the new public key under a new selector. Check authoritative DNS and public resolvers before signing, allowing any cached negative response for the new name to expire.
Switch: Configure the sender to sign new mail with the new selector.
Monitor: Confirm the new s= selector, expected d= signing domain, and a=rsa-sha256 in DKIM-Signature. Check dkim=pass in a trusted receiver's Authentication-Results header, then review DMARC results.
Retire: For routine rotation, keep the old public key for 7 to 30 days after its last signing use, then revoke it with an empty p= value. Retain the revoked TXT record under M3AAWG guidance.

Before switching the signer, validate the new selector's public key and DNS 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

For routine rotation, keep the old public key available for at least seven days and up to 30 days after the last sender stops using it, following M3AAWG guidance. Choose the overlap using actual queue and retry lifetimes, and account for DNS caching. Retain the retired selector with an empty p= value to make revocation explicit; remove retired private keys from active secret stores once rollback is no longer needed.

DMARC aggregate reports cover a reporting period and arrive after that period. Check the report's start and end times against the cutover, rather than its arrival time. An old selector in a newly received report does not prove continued signing. Use recent message headers and sender logs to distinguish ongoing use from delayed mail. RFC 9990 defines the aggregate report time window.

Routine overlap and emergency revocation

During scheduled rotation, 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 an uncompromised old signer configuration available until the new selector is stable.

If a private key is exposed, contain unauthorized access to the signer, switch to a fresh key, and revoke the exposed key immediately instead of waiting through the routine overlap. Cached public keys remain usable until their TTL expires, and legitimate mail signed with the old key can fail after revocation. Never roll back to a compromised key.

Who rotates DKIM keys behind a CNAME?

A CNAME at selector._domainkey.example.com delegates the key lookup to a provider-hosted TXT record. The provider can change the underlying keys and switch signing without changing the CNAME in your DNS zone. M3AAWG's delegation guidance describes this pattern.

A CNAME does not prove that automatic DKIM key rotation is enabled. Confirm who owns rotation, its schedule, the RSA key length, and the emergency revocation process. Keep every selector CNAME the provider requires, including inactive selectors. Do not replace a required CNAME with a TXT record to rotate the key yourself.

Track the underlying public key as well as the selector name, because an unchanged CNAME does not show whether the key has rotated. Follow the provider's documented process for key replacement and offboarding, and verify fresh signed messages after each change.

Monitor DKIM rotation with Suped

Suped is our DMARC reporting and email authentication platform. Use it to compare source-level DKIM and DMARC results before and after rotation. 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. Compare report windows with the cutover time, and verify fresh message headers for each source before retiring the old key after the planned overlap.

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: Combine post-cutover report windows with recent headers and queue lifetimes 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 revoking their DNS keys.

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 revocation 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 keys active in DNS keeps old signing paths valid for attackers.

Expert tips

Test rotation during calm periods so emergency key replacement uses a known process.

Check DMARC report periods against the cutover before assuming old selectors remain active.

Prefer 2048-bit RSA unless the sender has a documented compatibility limitation.

Marketer view

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 view

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

Set a DKIM rotation policy

Use 2048-bit RSA-SHA256 for DKIM, rotate keys at least every six months, and rotate immediately when a key or sender environment is suspected to be exposed. Assign an owner for each sender's rotation and emergency revocation process.

For routine rotation, create a new selector with a new key pair, publish it, change signing, and watch real authentication results. Revoke the old key after a 7 to 30 day overlap following its last signing use. Replace 1024-bit selectors during the next planned rotation. Revoke and replace RSA selectors below 1024 bits immediately.

Frequently asked questions

Rotation itself does not boost deliverability. It protects authentication integrity. A bad rotation can hurt deliverability if it causes DKIM failures, so monitoring matters.

M3AAWG recommends rotating DKIM keys at least every six months. A shorter schedule depends on your security policy and platform. Rotate immediately after suspected compromise or exposed secrets, and retire a vendor's keys when offboarding is complete. DKIM does not impose an automatic public-key expiration date.

RFC 8301 permits 1024-bit RSA as the minimum, but recommends at least 2048 bits. Use 2048-bit RSA for new selectors and replace 1024-bit keys when the sender supports it.

Yes. Publishing old and new selectors at the same time is normal during rotation. The signer chooses which selector appears in each message signature. Keeping both public keys available does not require signing each message with both keys.

RFC 8301 requires verifiers to support RSA keys through 4096 bits, so that size is not inherently outside the standard. Confirm sender support and correct DNS handling before deploying it. For most domains, 2048-bit RSA remains the practical default.

Ed25519-SHA256 is standardized for DKIM. Use a different selector for it and keep a 2048-bit RSA-SHA256 signature during adoption while you verify results across real recipient traffic.