Are people using 4096-bit DKIM keys, and what is the recommended DKIM key length?
Published 23 May 2025
Updated 2 Aug 2026
10 min read
Summarize with
Updated on 2 Aug 2026: We corrected the 4096-bit verifier requirements, expanded the DNS guidance, and added practical Ed25519 advice.
Yes, people are using 4096-bit DKIM keys today, but they are uncommon. 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 gives stronger key material on paper, but email authentication fails more often because of broken DNS, stale selectors, unsigned mail streams, or weak operational process. A clean 2048-bit key, rotated with a new selector and monitored after rollout, is the better answer for most domains.
The real question is not whether a 4096-bit DKIM key can exist. It can. The real question is whether it improves mail authentication enough to justify the larger DNS response and remaining implementation edge cases. For most senders, the answer is no.
The short answer
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 gain from 4096-bit signing is usually smaller than the operational risk created by larger DNS responses and uneven implementation support.
- 4096-bit: Standards-compliant, uncommon, and worth testing 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, creates larger responses, and gets less routine exercise across deployed email verification stacks. That does not make it invalid. It means the key length has more operational surface area than the common 2048-bit choice.
Most DKIM problems are not brute-force problems. They are publication and control problems: a sender signs with the wrong selector, a DNS provider mangles quoted TXT chunks, 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 add fragmentation and split-string risk.
- Operations: Harder when senders hide key controls.
- Security: Stronger key material, but limited practical gain for most senders.
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.
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. It also requires RSA-SHA256 and prohibits RSA-SHA1 for signing or verification.
The long-running Server Fault discussion predates RFC 8301. 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.
A flowchart showing when to replace weak DKIM keys and when to test 4096-bit keys.
A conservative decision flow still makes sense. Replace anything below the standard, use 2048-bit RSA for new work, and choose 4096-bit DKIM only when the signer stack, DNS provider, verifier policy, and important receiver tests all pass.
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, which avoids the multi-string TXT record and large DNS response concerns associated with long RSA keys.
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 you want to inspect an RSA key manually, copy the p= value, remove DNS quotes, decode the public key, and inspect the RSA modulus. For Ed25519, check the k=ed25519 tag instead of applying an RSA modulus command.
Inspect the RSA modulusbash
printf '%s\n' 'MIIBIjANBgkqh...' | base64 -d > dkim.der openssl rsa -pubin -inform DER -in dkim.der -text -noout
For a quicker check, paste the selector and domain into the DKIM checker. It should tell you whether the public key parses cleanly, whether the DNS record is valid, and whether the selector matches the signing domain you expect.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A DNS-only check is not enough after a rotation. Send real mail after the change and inspect the received headers. DKIM has to pass on the messages people actually receive, not only on the record you meant to publish.
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 gain an unwanted space. A 2048-bit key already needs careful handling. A 4096-bit key gives the DNS publishing step more room to go wrong.
A split DKIM TXT record shapedns
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. If your DNS provider has unusually small limits, review the TXT record limits before you blame DKIM itself.
The full DNS response matters too. A 4096-bit RSA public key can exceed the traditional 512-byte DNS UDP response size, causing truncation and a retry over TCP. EDNS permits larger UDP responses, but oversized packets can fragment, and firewalls or older resolver paths do not always handle fallback reliably. This transport risk matters more than signing CPU cost when choosing 2048 bits.
Common DNS mistake
Do not add spaces inside the public key when splitting the TXT value. DKIM concatenates the character-strings, but extra characters inside the quoted material change the key.
- Good split: Adjacent quoted strings with no added key characters.
- Bad split: Manual spaces, line-break artifacts, 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.
A safe migration pattern
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.
- Create: Generate a new 2048-bit RSA key pair with a new selector name.
- Publish: Add the public key to DNS and wait for it to resolve publicly.
- Sign: Update the sending system to sign with the new selector.
- Test: Send real messages and confirm DKIM passes in received headers.
- Monitor: Watch DMARC reports for sources still using the old selector.
- Retire: Remove the old selector only after delayed mail has aged out.
This is where Suped's product is useful in practice. Suped brings DKIM, SPF, DMARC, blocklist (blacklist), and deliverability signals into one place, then turns authentication issues into concrete steps to fix. Its DMARC monitoring workflow helps confirm which sources adopted the new selector and which still fail after the rotation.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
During DKIM work, Suped's product can connect selector changes with DMARC pass rates and alerts. That keeps the key-length decision tied to the messages receivers actually evaluate instead of treating the DNS record as proof that the rollout worked.
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 strict internal policy, controlled sending infrastructure, managed DNS, and enough test coverage to prove the key works across important receivers. That is a narrower case than normal commercial sending.
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.
- Report proof: DMARC data shows no source falling back or failing.
If a 4096-bit rollout lacks those checks, it is not a reliable security improvement. A smaller, widely supported key with clean signing and monitoring beats a larger key with unclear verification.
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 a long key as one broken TXT string causes failures that look like bad signing.
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 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 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
The practical recommendation
Yes, 4096-bit DKIM keys are being used, but they should not be the standard answer. For RSA DKIM, 2048 bits is the recommended length for new keys. It provides a strong RSA baseline with broad support while keeping DNS responses smaller than 4096-bit records.
Move away from 1024-bit keys when you can, and replace anything below 1024 bits as a priority. Rotate by adding a new selector, validating real mail, watching DMARC reports, and retiring the old selector only after traffic has settled. The DKIM key rotation process matters as much as the key length itself.
The operational answer in one line is to use 2048-bit RSA, monitor the selector after rollout, and choose 4096-bit DKIM only after end-to-end testing.
