Are people using 4096-bit DKIM keys, and what is the recommended DKIM key length?
Published 23 May 2025
Updated 9 Oct 2026
12 min read
Summarize with
Updated on 9 Oct 2026: We clarified DKIM key length recommendations, signing performance, DNS publication rules, and checks for a successful key rotation.
Yes, 4096-bit DKIM keys are used in production. The recommended DKIM key length for RSA is 2048 bits for new selectors. That is the practical balance between security, DNS reliability, signer support, and broad verifier compatibility.
4096-bit DKIM should not be the default hardening step. A 4096-bit key provides greater resistance to cryptographic attacks, but it does not fix broken DNS, stale selectors, unsigned mail streams, or exposed private keys. A correctly published 2048-bit key, rotated with a new selector and monitored after rollout, is the better answer for most domains.
Recommended DKIM key length
For RSA DKIM, use 2048-bit keys for new production selectors. A 1024-bit key meets the minimum in RFC 8301, but it should be treated as legacy. Verifiers must not consider anything under 1024 bits valid. RFC 8301 requires verifiers to handle RSA keys through 4096 bits, although older software and local verifier policies can still create real-world failures.
Direct recommendation
Use 2048-bit RSA DKIM keys unless you have a documented reason and a tested path for 4096-bit keys. The additional cryptographic strength does not remove the need to test DNS responses and receiver support.
- 4096-bit: Standards-compliant, but test signer support and receiving systems before use.
- 2048-bit: The recommended RSA default for new DKIM selectors.
- 1024-bit: The standards minimum and a legacy choice, not the target for new keys.
- Under 1024-bit: Replace it because compliant verifiers must not treat it as valid.
|
|
|
|---|---|---|
512 or 768 | Invalid | Replace |
1024 | Minimum | Plan upgrade |
2048 | Default | Use now |
4096 | Special case | Test first |
Practical DKIM RSA key length guidance
If you are choosing between 1024 and 2048, the better default is 2048. For a deeper comparison, the 1024 vs 2048 breakdown covers the tradeoff in more detail.
Why 4096-bit DKIM remains uncommon
A 4096-bit public key is longer in DNS and creates larger responses. Standards compliance does not guarantee that every sending platform exposes a 4096-bit option. Check the supported key lengths before generating a replacement key.
DKIM failures also arise when a sender signs with the wrong selector, a DNS provider truncates a TXT value, a retired selector gets deleted too early, or a vendor keeps signing with an old key after the migration is expected to be complete.
2048-bit RSA
- Compatibility: Fits the normal verifier support range.
- DNS: Easier to publish without TXT chunk mistakes.
- Operations: Common in managed sending platforms.
- Security: Strong for DKIM when keys are protected and rotated.
4096-bit RSA
- Compatibility: Required by RFC 8301, but legacy or policy-limited paths can fail.
- DNS: Larger responses require checking TXT publication and DNS transport.
- Operations: Harder when senders do not expose key-size controls.
- Security: Greater cryptographic strength, but no protection against a stolen private key.
DKIM RSA key length guidance
A practical way to rank RSA DKIM key lengths during audits.
Critical
Under 1024
Keys that compliant verifiers must reject.
Legacy
1024
The standards minimum, but not the right new default.
Recommended
2048
The practical default for new RSA selectors.
Special case
4096
Supported through 4096, but test DNS and delivery.
How 4096-bit keys affect signing performance
DKIM (DomainKeys Identified Mail) uses a private key to create a digital signature and a public key in DNS to verify it. DKIM does not encrypt the email. RSA key length is the size of the modulus, not the length of the DNS text.
Larger RSA keys increase the computation needed for signing and verification. For high-volume senders, benchmark CPU use and signing throughput on the actual mail server. Doubling the key length does not imply twice the security or a fixed performance penalty.
A 4096-bit RSA signature is 512 bytes before base64 encoding, compared with 256 bytes for 2048-bit RSA. This also enlarges the DKIM-Signature header. These lengths follow the RSA signature format in RFC 8017.
What RFC 8301 requires
RFC 8301 says RSA signers must use keys of at least 1024 bits and should use keys of at least 2048 bits. Verifiers must validate RSA signatures with keys from 1024 through 4096 bits and can support larger keys. For RSA DKIM, it requires RSA-SHA256 and prohibits RSA-SHA1 for signing or verification. These requirements are specified in RFC 8301.
The Server Fault discussion began before RFC 8301. Its answer includes older RFC 4871 guidance alongside the later RFC 8301 requirements. The current standard requires support through 4096 bits, but older implementations, local verifier policy, DNS transport, and firewall handling still justify end-to-end testing.
DKIM key length decision flow: replace RSA keys below 1024 bits, use 2048 bits by default, and test 4096-bit keys.
Replace RSA keys below 1024 bits and use 2048-bit RSA for new selectors. Choose 4096-bit DKIM only after the sending system and DNS provider support it and messages pass DKIM at your important receivers.
How Ed25519 changes the comparison
DKIM key size numbers only compare security cleanly within the same algorithm. Ed25519-SHA256 uses a 256-bit public key, but that does not make it weaker than 1024-bit or 2048-bit RSA. The algorithms use different mathematics, so their bit counts are not directly comparable.
RFC 8463 adds Ed25519-SHA256 to DKIM and requires verifiers to implement it. Its base64 public key is only 44 characters, so a typical selector record fits in a single TXT character-string. Implementation support still needs testing. The key format and transition rules are defined in RFC 8463.
Practical Ed25519 rollout
Use Ed25519 only when the sending platform supports it, and keep a separate 2048-bit RSA signature while testing operational coverage. The two signatures need different selectors because each selector can publish only one key record.
- Algorithm tag: Ed25519 signatures use ed25519-sha256.
- DNS key type: The selector record uses k=ed25519.
- Migration: Sign with RSA and Ed25519 on separate selectors during testing.
- Comparison: Do not rank Ed25519 and RSA strength by bit count alone.
How to check DKIM key length
The fastest way to check a DKIM key length is to inspect the selector record that appears in a signed message. Look at the s= selector and d= domain in the DKIM-Signature header, then query the matching DNS name.
Query a DKIM selectorbash
dig +short selector1._domainkey.example.com TXT
If the selector points to a CNAME, follow it to the provider-hosted TXT record. Check every active sending source and both selectors in systems that alternate keys; a new platform default does not automatically upgrade an existing selector.
To inspect an RSA key manually, copy the complete p= value from that one TXT record and join its quoted strings. Exclude the p= tag, other tags, and DNS display quotes. Replace the placeholder below with that value; the command removes whitespace, decodes the public key, and displays its size. For Ed25519, check k=ed25519 instead of using an RSA modulus check.
Inspect the RSA public key sizebash
dkim_public_key='PASTE_COMPLETE_P_VALUE_HERE' printf '%s' "$dkim_public_key" | tr -d '[:space:]' | openssl base64 -d -A | openssl pkey -pubin -inform DER -text -noout
For a quicker check, enter the selector and signing domain into Suped's DKIM checker to inspect the live DNS record and public key. A successful lookup does not verify a message signature.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A DNS-only check is not enough after a rotation. Send real mail and inspect the receiving server's Authentication-Results header for dkim=pass and the expected signing domain and selector. Check each signature separately when a message has more than one.
DNS publication and TXT length
Long DKIM records fail in ordinary ways. DNS control panels handle TXT strings differently, admin screens wrap text visually, and a pasted key can be truncated. A 2048-bit key already needs careful handling. A 4096-bit key makes correct TXT publication more important.
A split DKIM TXT record shape, not a publishable keydns
selector1._domainkey.example.com. TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..." "...continued-public-key-material..." )
Each character-string inside a TXT record is limited to 255 octets, but a TXT record can contain multiple strings. DKIM joins those strings without adding spaces before it parses the public key. Publish all chunks within one TXT record, not as separate TXT records at the selector. These rules are defined in RFC 1035 and RFC 6376. If your DNS provider has unusually small limits, review the TXT record limits before reducing the key size.
The full DNS response matters too. A 4096-bit RSA public key exceeds the traditional 512-byte DNS UDP response limit and requires EDNS or TCP fallback. EDNS permits larger UDP responses, so a 4096-bit key does not automatically cause fragmentation. The complete response, including any DNSSEC data, and the advertised UDP size determine whether truncation or fragmentation occurs. Test UDP lookups and TCP fallback before rollout; the transport considerations are covered in RFC 6891.
Common DNS publication mistakes
Keep the public key intact when splitting a TXT value. RFC 6376 permits folding whitespace in p=, so a space alone does not necessarily invalidate the key. Missing base64 characters, literal quotes, or copied ellipses do break it. Multiple TXT records at one selector have undefined results.
- Good split: Adjacent quoted strings within one TXT record.
- Bad split: Separate TXT records, truncated key material, or copied ellipses.
- Best check: Query public DNS after saving, then parse the live value.
- Rotation rule: Publish the new selector before signing with it.
How to rotate DKIM keys safely
When moving a domain to stronger DKIM keys, avoid editing the old selector in place. A new selector gives a clean fallback path and makes failures easier to isolate. The old selector keeps validating older mail while the new selector handles fresh mail. Keep the private key on the signing system with restricted access; only the public key belongs in DNS.
- Create: Generate a new 2048-bit RSA key pair with a new selector name, or request a supported key upgrade from the sending platform.
- Publish: Add the public key or provider-supplied CNAME to DNS. Confirm it resolves publicly and allow cached negative answers to expire before signing.
- Sign: Update the sending system to sign with the new selector.
- Test: Send real messages and confirm DKIM passes for the expected signing domain and new selector in received headers.
- Monitor: Check DKIM results and reported selectors for each sending source. A DMARC pass alone does not prove the new key works, because SPF or another valid DKIM signature can satisfy DMARC.
- Retire: Remove the old selector only after every signer has switched and queued or retried mail has cleared. Account for DNS caches; there is no universal waiting period.
Suped's DMARC reporting product helps monitor authentication during a key rotation. Its DMARC monitoring workflow shows reported DKIM results by sending source, helping identify failures after the switch. Use selector details when present and confirm the change in received message headers.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
In Suped's product, compare source-level DKIM results before and after the change and use authentication alerts to investigate regressions. A DMARC pass rate alone can conceal DKIM failures when SPF passes with the required domain match. DMARC's pass criteria are defined in RFC 9989.
If you are auditing a domain before a key change, a domain health check helps surface the broader DNS and authentication issues that affect the same rollout.
When 4096-bit DKIM makes sense
Reserve 4096-bit DKIM for environments with a documented requirement for stronger RSA keys and enough test coverage to prove the key works across important receivers. Check that the signer supports 4096 bits and that the DNS response works through production resolver paths.
If you run your own MTA, own the DNS zone, and can test delivery at scale, 4096-bit RSA is a reasonable option. If you depend on hosted senders, shared admin access, vendor-managed selectors, or limited receiver testing, 2048-bit RSA is the safer default.
A good 4096-bit rollout has proof
- DNS proof: The live TXT record parses exactly as intended.
- Signing proof: The DKIM-Signature header uses the new selector.
- Receiver proof: Real delivered messages show DKIM pass results for that signature.
- Report proof: Reported DKIM results for the new selector show no new failures at reporting receivers.
Larger keys do not guarantee inbox placement or compensate for an exposed private key. If the checks reveal failures, restore the tested selector and fix the cause before continuing the rollout.
Views from the trenches
Best practices
Use 2048-bit RSA for new DKIM selectors unless a platform has a documented constraint.
Keep old selectors published until delayed mail and active campaigns have fully aged out.
Check real signed mail after changing keys, not only the DNS record that holds the key.
Common pitfalls
Choosing 4096-bit keys before testing receivers creates risk without much operational gain.
Publishing key chunks as separate TXT records at one selector creates undefined results.
Rotating a key and deleting the old selector immediately breaks delayed or retried mail.
Expert tips
Log observed DKIM key sizes over time so weak selectors become measurable work items.
Treat keys under 1024 bits as remediation tasks because compliant verifiers reject them.
Use selector names that identify systems and dates without exposing private internals.
Marketer view
Marketer from Email Geeks says 4096-bit DKIM keys exist in live mail, but they are uncommon enough that logging samples is useful.
2024-08-19 - Email Geeks
Marketer view
Marketer from Email Geeks says the practical question is how often 4096-bit keys appear in normal mail streams, not whether they can be created.
2024-08-19 - Email Geeks
Plan the next DKIM key rotation
Plan to replace 1024-bit RSA keys with 2048-bit keys, and replace anything below 1024 bits as a priority. Rotate by adding a new selector, validating real mail, checking DKIM results in DMARC reports, and retiring the old selector after all signers have switched and delayed mail has cleared. The DKIM key rotation process matters as much as the key length itself.
