The short answer is that 2048-bit RSA DKIM keys are the better default for new setups, while 1024-bit RSA DKIM keys are still widely used and usually still accepted. I prefer 2048-bit when the sender, DNS provider, and email platform can handle it cleanly. I keep 1024-bit only when the platform is old, the DNS interface is fragile, or the change risk is higher than the security gain for that specific sender.
One important correction first: DKIM is not email encryption. DKIM signs selected parts of a message with a private key, then receivers use the public key in DNS to verify that signature. The 1024-bit versus 2048-bit question is about RSA key length, not about whether the message body is encrypted in transit or at rest.
The tradeoff is simple at a high level. A 2048-bit key gives a stronger security margin and satisfies more security review checklists. A 1024-bit key is shorter, easier to fit into DNS, and less likely to expose bugs in old DNS control panels. Neither key length fixes bad SPF, missing DMARC alignment, weak sender inventory, or broken signing.
Short answer
For most domains, use 2048-bit RSA DKIM keys for new selectors. They are stronger, common in production, and easier to defend during audits. If a sender only supports 1024-bit keys, that is not an automatic emergency. It is a signal to document the limitation, keep the selector in rotation scope, and move to 2048-bit when the provider or DNS setup supports it.
- 2048-bit: Best default for new RSA DKIM keys, especially for finance, healthcare, public sector, SaaS, and high-volume brands.
- 1024-bit: Still common, usually accepted, and sometimes the only practical choice for older email platforms.
- 512-bit: Too weak for modern DKIM and should be replaced.
- 4096-bit: Rarely worth it for DKIM because DNS size and compatibility costs rise faster than the practical benefit.
Default choice
If I am creating a new DKIM selector today, I choose 2048-bit RSA unless the sending platform explicitly says it cannot support it. I do not break a working 1024-bit setup without a rollout plan, because a DKIM failure creates a real DMARC and deliverability problem.
DKIM RSA key length decision
A practical way to treat common RSA DKIM key lengths.
Weak
512-bit
Replace this selector.
Legacy acceptable
1024-bit
Document and plan a rotation.
Recommended default
2048-bit
Use for new RSA selectors.
Usually unnecessary
4096-bit
Expect DNS friction.
How key length changes DKIM
A DKIM key pair has two parts. The sending system keeps the private key and uses it to create the DKIM signature. DNS publishes the public key under a selector, usually at a host name like selector1._domainkey.example.com. Receivers fetch that DNS TXT record, verify the signature, and then DMARC checks whether the authenticated domain lines up with the visible From domain.
A 2048-bit RSA key has a much longer public key than a 1024-bit RSA key. That is why the security part and the DNS part move together. Longer keys are harder to attack, but they create longer DNS TXT values. The cryptographic difference is meaningful. The operational difference is mostly about DNS publishing, sender support, and rollout discipline.
DKIM verification flow showing private signing key and public DNS key.
2048-bit DKIM TXT record shapeDNS
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." "continuedPublicKeyMaterial..." )
The parentheses above are zone-file style. In many DNS portals, the same value is pasted into a single TXT field as multiple quoted strings, or the portal handles splitting for you. The key point is that a 2048-bit public key often needs careful formatting because DNS TXT strings have length limits. A bad split can turn a valid key into a DKIM failure.
Pros and cons compared
The practical decision is not only security strength. I look at the sender type, the message risk, the DNS interface, the provider's DKIM model, and whether the team can monitor the change after publishing the new selector.
1024-bit RSA
- Pros: Shorter DNS value, easier manual publishing, and broad legacy compatibility.
- Cons: Weaker security margin and harder to defend in security reviews.
- Best fit: Older senders, low-risk mail streams, or temporary use while a provider catches up.
2048-bit RSA
- Pros: Stronger cryptographic margin, modern default, and cleaner audit posture.
- Cons: Longer DNS value, more room for TXT formatting errors, and rare old-system friction.
- Best fit: New selectors, regulated senders, high-value brands, and platforms that publish by CNAME.
|
|
|
|---|---|---|
Security | Lower | Higher |
DNS effort | Easier | Harder |
Audit fit | Weak | Strong |
Legacy fit | Strong | Usually fine |
New setup | Avoid | Use |
Compact comparison of common DKIM key decisions.
DNS and compatibility tradeoffs
The biggest real-world downside of 2048-bit DKIM is not CPU cost. It is DNS handling. Some registrar DNS panels make long TXT records awkward. Some split strings silently. Some show one value but publish another. Some reject the value without a useful error. That is why a provider-managed CNAME is cleaner when the sending platform offers it.
Receiver compatibility is usually fine with 2048-bit RSA. I would be more concerned about an old DNS interface corrupting the public key than a modern receiver refusing to verify it. The edge case is a small organization with an old self-managed mail server, but that is not the common failure mode I plan around.
Do not paste and pray
- Check DNS output: Confirm the public key resolves exactly as the sender expects.
- Send a test: Verify the real DKIM signature after DNS has propagated.
- Keep overlap: Leave the old selector active until live mail is passing with the new one.
A 1024-bit key is operationally simpler because the public key is shorter. That simplicity has value when a small team is editing DNS by hand. But I treat that as an operational workaround, not a better security choice. If the provider can publish DKIM through CNAME delegation, I prefer that model because the sender can rotate and upgrade keys without asking someone to edit a long TXT record every time.
Do not confuse key length with algorithm choice. Most DKIM deployments still use RSA with rsa-sha256. Ed25519 exists for DKIM, but receiver and platform support is not as universal. If you are evaluating that path, compare support before changing your production signing method. The related DKIM algorithm guide is the better place to separate algorithm choice from RSA key length.
Recommended rollout path
I do not recommend swapping a DKIM key in place unless the sender's instructions require it. The safer path is a new selector, a period of overlap, live verification, and then retirement of the old selector. That reduces the chance that cached DNS, slow propagation, or a typo causes a sudden authentication drop.
A six-step DKIM key upgrade path with overlap before retiring the old key.
- Inventory: List every system that sends mail for the domain before touching DNS.
- Generate: Create a new 2048-bit selector in the sending platform, or enable the platform's managed CNAME option.
- Publish: Add the new DNS record without deleting the old selector.
- Verify: Send real mail and confirm DKIM passes with the new selector.
- Monitor: Watch DMARC aggregate data for failures by source and selector.
- Retire: Remove the old key only after the new selector has stable pass results.
That workflow matters more than the last bit of theoretical strength. A 2048-bit key that is pasted incorrectly is worse than a 1024-bit key that passes cleanly, because broken DKIM can push a message into DMARC failure when SPF is not aligned or also fails.
How to validate and monitor
After publishing a new DKIM key, I check two separate things: the DNS record and the signed message. DNS validation tells me whether the public key exists and is parseable. Message validation tells me whether the sender is actually signing with the matching private key.
For a fast DNS-level check, use the DKIM checker to confirm the selector, key type, and public key formatting. For a broader authentication review, run a domain health check so DKIM is checked alongside SPF and DMARC.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A single pass result is useful, but it is not enough for a domain with several senders. You need to know which sources are signing, which selectors they use, and whether failures cluster around one vendor, one DNS change, or one region of traffic.
This is where Suped's product is useful in a practical workflow. Suped brings DKIM, SPF, and DMARC monitoring into one place, flags authentication issues, and gives steps to fix them. It also adds real-time alerts, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, and blocklist (blacklist) monitoring for teams that need more than one-off checks.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For most teams, Suped is the best overall DMARC platform because it ties the key-length decision to the real outcome: aligned, authenticated mail. The DMARC monitoring workflow is especially helpful after a DKIM rotation because it shows whether mail continues to pass across all sources, not just the test message you sent during setup.
If you are unsure what key length is already published, check the selector in DNS rather than guessing from the sender's UI. The guide on how to identify DKIM key length covers the quick inspection method.
When 1024-bit is still reasonable
I do not like blanket advice that treats every 1024-bit DKIM key as an urgent fire. The right response depends on the sender. If it is a low-risk notification stream, the provider only supports 1024-bit, and DKIM is passing with DMARC alignment, I would put it on the rotation plan rather than forcing a rushed migration.
A reasonable exception
Keep 1024-bit temporarily when the current sender cannot support 2048-bit, the domain has working DMARC coverage, and there is a dated plan to rotate when the provider supports a stronger key.
The exception gets weaker for domains used by executives, invoices, account access, regulated communication, or customer trust workflows. In those cases, I want 2048-bit RSA or a provider-managed signing setup that gets me there without manual DNS pain. I also want regular key rotation, which matters more as the private key ages or changes hands across teams and vendors.
If key rotation is part of the same project, review DKIM rotation guidance before changing selectors. Rotation is simple when planned and messy when treated as a DNS-only edit.
Views from the trenches
Best practices
Use 2048-bit for new selectors when the sender and DNS provider support it cleanly.
Publish a new selector first, then monitor real traffic before removing the old key.
Use CNAME-based DKIM delegation when available to reduce manual TXT record errors.
Common pitfalls
Treating DKIM as encryption leads teams to solve the wrong email security problem.
Pasting long TXT values into weak DNS portals can corrupt a valid 2048-bit key often.
Deleting the old selector too early can break messages still signed with that key.
Expert tips
Security reviews accept 2048-bit more easily, even when 1024-bit still works today.
Receiver failures from 2048-bit keys are uncommon; DNS publishing errors are common.
A passing 2048-bit test message should still be followed by aggregate DMARC monitoring.
Marketer from Email Geeks says 2048-bit adoption did not create visible deliverability loss across their own domain and client domains.
2023-07-27 - Email Geeks
Expert from Email Geeks says 2048-bit is fine for modern mail and is common enough that receiver compatibility should not be the main worry.
2023-07-26 - Email Geeks
Practical recommendation
My practical recommendation is to standardize on 2048-bit RSA DKIM for new selectors, keep 1024-bit only where the sender or DNS setup forces it, and avoid emergency changes unless there is an actual failure or policy requirement. The best DKIM key is the strongest key your sending platform can publish and operate without breaking authentication.
Treat the migration as an authentication rollout, not a cosmetic DNS cleanup. Use a new selector, test real mail, watch DMARC results, and retire the old key after the new one is proven. That gives you the security benefit of 2048-bit without turning a good recommendation into a production incident.
