DKIM Key Length and Algorithm: Why "Still Validates" Doesn't Mean "Still Recommended"

A DKIM key generated with default settings five years ago might still be using RSA-1024 — a key length that was considered acceptable at the time but has since been deprecated by major providers, and "my DKIM still validates" doesn't mean "my DKIM key is still considered acceptable"

The previous articles on this site covered DKIM key rotation, the full authentication audit, and DKIM's interaction with mailing lists/forwarding. This article addresses key length and algorithm choices for DKIM — a dimension that's separate from "is DKIM configured correctly" (which the DKIM Checker verifies) but increasingly relevant to "is DKIM configured securely."

RSA key lengths: 1024-bit vs 2048-bit

DKIM's most common signing algorithm is RSA — and RSA key length (measured in bits — commonly 1024, 2048, or occasionally longer) affects the cryptographic strength of the signature.

RSA-1024 was, for many years, a commonly-used, generally-accepted key length — including for DKIM. However, cryptographic research over time has progressively reduced confidence in 1024-bit RSA's long-term security — the computational resources required to potentially break a 1024-bit RSA key have, over time, become less prohibitive than they once were (though still substantial) — leading major mailbox providers to deprecate support for 1024-bit DKIM keys, treating signatures using such keys as weaker/less-trustworthy signals than 2048-bit (or longer) signatures.

RSA-2048 is the current commonly-recommended minimum for new DKIM key generation — providing substantially greater cryptographic margin compared to 1024-bit.

The practical issue: existing DKIM keys, generated years ago with then-acceptable 1024-bit settings, remain, technically, "valid" DKIM keys — they exist in DNS, signatures generated with them can be technically verified (the cryptographic math still "works" — 1024-bit RSA isn't "broken" in the sense of being trivially forgeable; it's "weaker than current recommendations," a different, more gradual concern) — but some receiving systems may treat 1024-bit-signed messages with additional scrutiny, or give them less "credit" toward positive reputation/authentication signals, compared to 2048-bit-signed messages — a "soft" deprecation, rather than an outright "signatures using this key length are now rejected entirely" cutoff — but still a meaningful, if gradual, consideration.

Ed25519: a newer, smaller, faster alternative

Ed25519 (an elliptic-curve-based signature algorithm) has been added as a supported DKIM signing algorithm (alongside RSA, not necessarily replacing it) — Ed25519 keys are substantially smaller than even RSA-2048, while providing comparable or stronger cryptographic security — and Ed25519 signature generation/verification is computationally faster.

The trade-off for adoption: Ed25519 support among receiving mail systems isn't yet universal* — a domain publishing an Ed25519-only DKIM key (with no RSA fallback) risks some receiving systems being unable to verify the signature at all (if that system doesn't yet support Ed25519 verification) — potentially treating the message as "DKIM not present/not verifiable," rather than "DKIM present and valid."

A common recommended approach: dual-key signing — signing outgoing messages with both an RSA key (for broad compatibility with receivers that don't yet support Ed25519) and an Ed25519 key (for receivers that do, gaining the Ed25519 advantages) — via multiple DKIM-Signature headers on the same message (DKIM supports a message carrying multiple signatures, each using a different selector/algorithm — receivers can verify whichever signature(s) they support, and a message is generally considered "DKIM pass" if at least one valid signature is found, even if other, additional signatures aren't verifiable by that particular receiver).

Checking your current key's algorithm/length

A DKIM DNS record includes a k= tag indicating the key type (e.g., k=rsa — RSA is the default if k= is omitted, so its absence implies RSA) and the public key itself, in the p= tag (base64-encoded).

Determining the key length from the DNS record requires decoding the public key data — the length of the decoded key data corresponds to the RSA key length (1024-bit vs 2048-bit RSA public keys have characteristically different encoded lengths — roughly, a 2048-bit key's base64-encoded p= value is roughly double the length of a 1024-bit key's, though the precise relationship involves encoding overhead that isn't perfectly 2:1).

For Ed25519 keys, k=ed25519 is explicitly specified in the DNS record (distinguishing from the RSA default).

Migration: rotating to a stronger key

Migrating from a 1024-bit RSA key to a 2048-bit key follows the same general key-rotation process covered in the previous DKIM key-rotation article — generate a new, 2048-bit key pair; publish the new public key under a new (or existing, if appropriately managed) selector; update signing infrastructure to use the new private key; after a transition period (allowing DNS propagation and any "in-flight" messages signed with the old key to be fully processed), remove the old key's DNS record.

The "1024-to-2048" migration is, in most respects, operationally identical to any other DKIM key rotation — the previous article's guidance on selectors, rotation cadence, and debugging applies equally — what's specific to this particular migration is primarily the motivation (upgrading key strength to meet current recommendations), not the mechanics of the rotation process itself.

How to use the DKIM Checker on sadiqbd.com

1. Check your current DKIM record's k= value — confirming whether it's RSA (default/explicit) or Ed25519
2. For RSA keys, estimate length from the p= value's size — a significantly shorter p= value, compared to what's typical for 2048-bit keys, may indicate a 1024-bit (or other non-current-recommended) key — if uncertain, dedicated key-length-checking tools (which decode the key and report its length explicitly) provide definitive confirmation
3. If using a 1024-bit key: consider rotating to a 2048-bit (minimum) key, following the standard rotation process from the previous article — this is generally low-urgency (existing 1024-bit signatures still function) but increasingly worth addressing as part of routine email-infrastructure maintenance

Frequently Asked Questions

If my DKIM key is 1024-bit and "still works," is there real urgency to change it? Generally, low urgency — 1024-bit RSA DKIM signatures continue to function, and the "deprecation" by major providers has, to date, generally been "soft" (reduced trust/scrutiny, rather than outright rejection) — however, cryptographic recommendations tend to move in one direction (toward stronger, not weaker, requirements) — a 1024-bit key that's "fine, for now" is unlikely to become "more acceptable" over time — treating this as "worth addressing during the next routine DKIM maintenance/rotation cycle," rather than either "urgent, fix immediately" or "never worth addressing,"* is a reasonable framing.

Is the DKIM Checker free? Yes — completely free, no sign-up required.

Try the DKIM Checker free at sadiqbd.com — verify your domain's DKIM record, key algorithm, and key length instantly.