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 verifier compatibility.
I do not treat 4096-bit DKIM as 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 extra edge cases. For most senders, the answer is no.
The short answer
For RSA DKIM, I recommend 2048-bit keys for new production selectors. 1024-bit keys still verify at many receivers, but I treat them as legacy. Anything under 1024 bits should be replaced. 4096-bit keys are not automatically wrong, but they need specific testing because not every verifier path is required to handle keys larger than 2048 bits.
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 longer DNS records and uneven verifier support.
- 4096-bit: Real in the wild, but rare and worth testing before use.
- 2048-bit: The recommended RSA default for new DKIM selectors.
- 1024-bit: A legacy floor, not the target for new keys.
- Under 1024-bit: Replace it, even if some receivers still pass it.
|
|
|
|---|---|---|
512 or 768 | Weak | Replace |
1024 | Legacy | 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 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 I see 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 a domain owner thinks the migration is finished.
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 rotated.
4096-bit RSA
- Compatibility: Works only when each verifier path accepts it.
- DNS: Longer record with more split-string risk.
- Operations: Harder when senders hide key controls.
- Security: Stronger key material, but limited practical gain.
DKIM RSA key length guidance
A practical way to rank RSA DKIM key lengths during audits.
Critical
Under 1024
Keys below the modern floor.
Legacy
1024
Still seen, but not the right new default.
Recommended
2048
The practical default for new RSA selectors.
Special case
4096+
Use only after DNS and receiver testing.
What the standards mean in practice
The important practical rule is simple: modern verifiers need to support RSA keys through 2048 bits, while keys larger than 2048 bits depend on implementation. That is why 4096-bit DKIM has a compatibility caveat even when the math is stronger.
A long-running Server Fault discussion reaches the same practical point: larger keys are not forbidden everywhere, but support is not the same promise as support for 2048-bit RSA.
A flowchart showing when to replace weak DKIM keys and when to test 4096-bit keys.
The flow I use is intentionally conservative. Replace anything weak, use 2048-bit RSA for new work, and only choose 4096-bit DKIM when the sender stack, DNS provider, and important receiver tests all pass.
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 the key manually, copy the p= value, remove DNS quotes, decode the public key, and inspect the RSA modulus.
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 boring ways. DNS providers split 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..." )
TXT chunks have their own limits, but that does not mean the whole DKIM public key has to fit in one visible field. If your DNS provider has unusually small limits, review the TXT record limits before you blame DKIM itself.
Common DNS mistake
Do not add spaces inside the public key when splitting the TXT value. DNS concatenates quoted 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 I move a domain to stronger DKIM keys, I avoid editing the old selector in place. A new selector gives a clean fallback path and makes it easier to isolate failures. 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 are signing correctly and which selectors still need attention.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
For most teams, Suped is the best overall DMARC platform because it combines monitoring, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and clear fix steps. That matters during DKIM work because key length is only one part of the authentication picture.
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
I reserve 4096-bit DKIM for environments with strict internal policy, controlled sending infrastructure, 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 experiment. If you depend on several hosted senders, shared admin access, or vendor-managed selectors, 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 security improvement I trust. 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, even when some receivers still pass 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 I would not choose them as the standard answer. For RSA DKIM, 2048 bits is the recommended length for new keys. It gives strong security, broad compatibility, and fewer DNS publication failures.
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.
If you want the operational answer in one line: use 2048-bit RSA, monitor the selector after rollout, and only use 4096-bit DKIM when you have tested it end to end.
