DKIM key length and algorithms: 1024 vs 2048, RSA vs Ed25519 (practical guide)

dkim

When teams ask "what DKIM key should be used," the real question is usually two questions mixed together:

  1. What is the minimum that still passes modern receiver expectations?
  2. What is the safest choice that will not create rollout pain?

For most production environments in 2026, the practical answer is straightforward: use rsa-sha256 with 2048-bit keys unless a specific platform constraint forces 1024.

That answer comes from the standards baseline and from receiver/operator guidance, not guesswork.

The baseline that matters today

The cryptography update in RFC 8301 is still the anchor point:

  • rsa-sha1 is historic and should not be used.
  • Signers must use RSA keys of at least 1024 bits.
  • 2048-bit RSA is the recommended target.

So, yes, 1024 is still a valid minimum in protocol terms. But minimum and recommended are not the same thing, and operationally that distinction matters.

1024 vs 2048 in real operations

Here is the practical tradeoff:

  • 1024-bit RSA: acceptable minimum for compatibility, but weaker security margin and usually not the best long-term choice.
  • 2048-bit RSA: stronger default and generally what providers and security teams expect when DNS tooling supports it.

Google's admin guidance explicitly tells admins to choose 2048-bit keys when supported, with 1024 as fallback (see Set up DKIM in Google Workspace and Google email sender guidelines).

Yahoo sender guidance also calls out a 1024-bit minimum and expects properly authenticated mail (see Yahoo sender requirements).

On Microsoft 365, DKIM operations (including rotation) are documented around the same practical key-size choices in their current admin guidance (see Microsoft DKIM configuration).

If a platform still only supports 1024 for a specific stream, that stream can remain compliant. But for new setups, 2048 is the better default.

RSA vs Ed25519: standard vs deployment reality

This is where things can feel confusing for admins, so a quick reassurance: confusion here is normal.

RFC 8463 adds ed25519-sha256 to DKIM and defines how it works (k=ed25519 in the DKIM key record). On paper, that is excellent cryptography with compact keys.

In production, support is still uneven across senders, gateways, and tooling. Because of that, RSA-SHA256 remains the safest universal signing choice for most domains.

A pragmatic pattern for advanced environments is:

  • keep RSA-SHA256 as the compatibility signature,
  • add Ed25519 only where the full path is validated end-to-end.

If multiple signatures appear on the same message, that is not automatically a problem; it is often intentional during compatibility transitions.

A sane decision framework

If a decision has to be made this week, use this framework:

  1. Default to rsa-sha256.
  2. Use 2048-bit RSA for new selectors.
  3. Allow 1024 only for documented platform constraints.
  4. Revisit Ed25519 after verifying signer and receiver behavior in your own traffic.
  5. Rotate keys on a calendar, not only after incidents.

That last point is important. Key size is only part of the story; stale keys create their own risk. If rotation policy is still being finalized, start with How Often Should You Rotate DKIM Keys? and the DKIM selectors rotation playbook.

DNS examples (copy pattern, not literal values)

Use provider-generated values for your exact platform, but the shape typically looks like this:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<base64-public-key>"
selector2._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<base64-public-key>"

For Ed25519-capable setups, the key type changes:

selector-ed25519._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=<base64-public-key>"

The important operational habit is not memorizing syntax. It is verifying DKIM-Signature and Authentication-Results in real received messages after each change.

Common mistakes that cause avoidable failures

  • Staying on 1024 forever because "it still passes" without reevaluating risk.
  • Switching algorithm/key size and selector at the same time for every sender stream in one change window.
  • Removing old selectors too quickly before delayed mail has cleared.
  • Treating a single successful test message as enough evidence.

If troubleshooting is needed, keep What is DKIM? and header-based DMARC troubleshooting close by during rollout.

Bottom line

Use 2048-bit RSA (rsa-sha256) as the default in 2026, keep 1024 as a compatibility fallback where required, and treat Ed25519 as a deliberate rollout instead of a blind switch.

That gives a clean balance between security, compatibility, and change safety.

Previous Post