DKIM Key Length: 1024-bit vs 2048-bit

Why This Is One of the Rare Clear-Cut DKIM Decisions

Most DKIM configuration choices — canonicalization mode, selector naming, which headers to sign — involve genuine trade-offs where reasonable people land in different places depending on their specific setup. Key length isn't really one of those. The cryptographic and industry consensus on RSA key strength has moved decisively enough that there's little defensible argument left for deploying a new 1024-bit DKIM key today, and a strong argument for actively rotating away from any 1024-bit key still in production. This guide focuses on why that consensus formed and what actually changes practically when you act on it, rather than presenting it as an open trade-off it genuinely isn't anymore.

Why 1024-bit RSA Fell Out of Favor

RSA's security rests on the practical difficulty of factoring the product of two large prime numbers back into its original factors. A 1024-bit key represents a number space that, while enormous by everyday standards, has become increasingly tractable to attack given the computing resources realistically available to well-resourced adversaries today — a gap that has only widened as computational power has grown. This isn't a DKIM-specific problem; it's the same broader cryptographic reasoning that pushed 1024-bit RSA out of favor across TLS certificates, SSH keys, and other RSA-dependent systems industry-wide, and DKIM is simply catching up to the same baseline the rest of the ecosystem already moved past.

What Actually Changes in Your DNS Record

The multi-string TXT handling point is worth taking seriously rather than treating as a footnote — a 2048-bit key's public value routinely exceeds the 255-character limit for a single DNS TXT string, meaning the record needs to be split across multiple quoted strings within the same TXT entry. Most modern DNS provider panels handle this correctly when you paste in a full record generated by DKIM key-generation tooling, but it's worth specifically verifying the published record wasn't silently truncated at 255 characters by a panel that doesn't support multi-string entry gracefully.

How to Check What You're Currently Running

Query your domain's active selector's TXT record directly and inspect the p= tag's value length — roughly 180 to 220 base64 characters typically indicates a 1024-bit key, while roughly 370 to 450 characters indicates 2048-bit, though a properly built lookup tool should report the decoded key length directly rather than requiring you to eyeball character counts and estimate. If you're unsure which selector is currently active, check a recent sent message's DKIM-Signature header for the s= tag it references, then look up that specific selector's record.

Performing the Upgrade Without Breaking Anything

This mirrors the same selector-based rotation process covered in detail in the companion key rotation guide — a key length upgrade is, mechanically, just a specific instance of ordinary DKIM key rotation, not a fundamentally different process requiring its own separate playbook.

Why Provider Policy Is Trending Toward Explicit Enforcement

Beyond the underlying cryptographic reasoning, there's a practical enforcement dimension worth understanding: major mailbox providers have been increasingly explicit, through their own published sender guidelines and bulk sender requirements, about treating short RSA keys as a signal worth penalizing rather than accepting silently. This shift means the cost of staying on a 1024-bit key isn't purely theoretical or forward-looking — it can translate into concrete deliverability friction today, independent of whether any actual cryptographic attack against your specific key ever occurs. Upgrading is as much a practical deliverability decision as a security-hardening one at this point.

Putting the Factoring Difficulty in Concrete Terms

Cryptographic key strength discussions often stay abstract enough that the actual stakes are hard to picture, so it's worth grounding this in what "factoring difficulty" practically means for RSA. The security of an RSA key rests on the fact that multiplying two large prime numbers together is computationally easy, while taking that product and working backward to find the original two primes is, for a sufficiently large product, computationally infeasible with any known practical method — it would take an amount of computing time so large as to be meaningless on any human timescale, for a properly sized key. The entire question of "is this key length still adequate" comes down to how that infeasibility threshold has shifted as computing power and factoring algorithms have both improved over time. A 1024-bit key's threshold has shifted enough that it's no longer considered comfortably outside the reach of a sufficiently motivated, well-resourced attacker, while 2048-bit remains, at current understanding, comfortably beyond practical reach for the foreseeable future.

A Note on Why This Isn't Really About "Attacks in the Wild"

It's worth addressing a specific line of reasoning that sometimes delays action on key length: the absence of a widely publicized, documented instance of a 1024-bit DKIM key actually being broken and exploited in practice. This absence of publicized incidents isn't strong evidence of continued safety, for a few reasons. Successfully factoring a specific key and using it to forge signatures isn't the kind of attack that necessarily gets loudly disclosed even when it happens, particularly if used for targeted or quiet abuse rather than a splashy public demonstration. More importantly, cryptographic recommendations are set with a forward-looking margin precisely because the computational resources available to attackers, and the sophistication of factoring algorithms, only ever improve over time — waiting for confirmed exploitation before acting means accepting risk during exactly the window when the recommendation was already telling you the margin was closing.

Comparing Key Length Guidance Across Other Protocols

DKIM's situation isn't an isolated, email-specific concern — it's simply the same industry-wide RSA key strength consensus that's already been applied elsewhere, arriving at DKIM specifically somewhat later than it did at these other, longer-established protocols.

What to Do If a Third-Party Platform Still Issues 1024-bit Keys

Occasionally, an older or less actively maintained third-party sending platform's DKIM setup process still generates a 1024-bit key by default, without offering an obvious option for a stronger one. In this situation, the practical options are: checking whether the platform has since added 2048-bit support that simply isn't the default and needs to be explicitly selected, contacting the platform's support to ask directly whether stronger keys are available, or, for organizations with sufficient technical control, self-managing DKIM signing outside the platform's built-in mechanism specifically to control key strength directly. None of these options are ideal compared to a platform that simply defaults to 2048-bit from the start, but understanding that the limitation sits with the specific platform, not with DKIM as a protocol, at least clarifies where the actual fix needs to happen.

Generating a 2048-bit Key Pair in Practice

For self-managed mail server setups, generating a 2048-bit RSA key pair is typically a single command using standard cryptographic tooling widely available on any modern server operating system, producing a private key file (kept secret, used for signing) and a corresponding public key that gets base64-encoded and formatted into the p= tag of the DNS TXT record. The private key must be kept accessible only to the mail signing system itself and protected with the same care as any other sensitive credential — anyone with access to it can produce valid DKIM signatures on the domain's behalf, which is precisely the property that makes key length matter in the first place, since a factored or leaked private key of any length grants that same capability to whoever obtains it. Most hosted email platforms handle this key generation step internally as part of their DKIM setup flow, presenting the domain owner only with the resulting DNS record to publish, without exposing the private key generation process directly.

Signature and Verification Overhead: The Actual Numbers

The claim that key length has negligible performance impact deserves a bit more substance than just asserting it. RSA signing and verification operations, even at 2048-bit, complete in a small fraction of a second on any modern server hardware — the computational cost scales with key size, but not so steeply that doubling key length from 1024 to 2048 bits produces any delay perceptible in the context of overall mail processing and delivery, which typically involves far more time spent on network transmission, queueing, and other processing steps than on the cryptographic operations themselves. For context, a mail server signing thousands of outbound messages per second can comfortably do so with 2048-bit keys on ordinary hardware; key length is simply not a meaningful bottleneck for any deployment scale a typical organization is likely to operate at.

What Happens to Key Length During Key Rotation

It's worth explicitly connecting this topic back to rotation: a key length upgrade doesn't require any special process beyond ordinary rotation, covered in depth in its own companion guide. Generate the stronger key, publish it under a new selector, switch signing over, verify, and retire the old selector once confident — the exact same sequence used for any routine rotation, whether or not key length happens to be changing as part of it. There's no DKIM-specific mechanism that treats "rotating to a longer key" any differently from "rotating to a same-length key generated fresh"; both are simply instances of introducing a new key under a new selector and retiring the old one on a safe timeline.

Key Length as Part of a Broader Certificate and Credential Hygiene Practice

Organizations that already maintain a formal schedule for reviewing TLS certificate strength and SSH key hygiene often find it natural to fold DKIM key length review into that same existing practice, rather than treating it as an entirely separate concern requiring its own new process. The underlying cryptographic reasoning is shared across all of these credential types, so a review cadence and set of minimum standards developed for one tends to transfer directly to the others with minimal adaptation.

Key Length Guidance Is Expected to Keep Moving Forward

It's worth setting the right expectation that 2048-bit won't necessarily remain the recommended baseline indefinitely, in the same way 1024-bit didn't remain adequate indefinitely. Cryptographic guidance evolves as computing power grows and factoring techniques improve, and it's entirely plausible that industry consensus eventually shifts toward 3072-bit or higher as the new practical baseline at some point in the future. Building key rotation into a routine, low-friction organizational habit now, rather than treating this one upgrade as a one-time project to complete and forget, is what makes adapting to whatever the next recommended baseline turns out to be a minor routine update rather than another overdue scramble.

Related Reading in This Series

For the full mechanics of safely introducing a new key without breaking existing signatures, see DKIM Key Rotation. For how selectors make running old and new keys simultaneously possible, read DKIM Selectors. For DKIM fundamentals end to end, see What Is DKIM. To check your current key length right now, open DKIM Lookup.