← RFC Reference

RFC 8463: Ed25519 for DKIM Signatures

Why This Exists

DKIM (RFC 6376) originally specified only RSA for signatures. RSA has served well, but it comes with costs:

• Large keys. A 2048-bit RSA public key is ~400 bytes Base64-encoded. DNS TXT records have a practical limit around 255 bytes per string (with most resolvers supporting up to ~4096 bytes total), making large RSA keys cumbersome and sometimes fragile in DNS.
• Slow verification. RSA signature verification, especially with larger keys, consumes measurable CPU time when a receiver processes millions of messages per hour.
• Key size escalation. RSA security depends on key length. As computational power grows, 2048-bit keys will eventually need to become 3072 or 4096 bits, making the DNS problem worse.

Ed25519 (Edwards-curve Digital Signature Algorithm using Curve25519) solves all three problems. Its 256-bit keys provide security equivalent to roughly 3072-bit RSA, the public key is only 32 bytes (44 characters Base64), and verification is significantly faster.

How It Works

Signing with Ed25519

The signing process is identical to standard DKIM, with two changes: the a= tag uses ed25519-sha256 instead of rsa-sha256, and the private key is an Ed25519 key instead of RSA.

1. Canonicalize headers and body per RFC 6376 rules.
2. Compute the SHA-256 hash of the canonicalized body (bh= tag).
3. Compute the SHA-256 hash of the signed headers plus body hash.
4. Sign the header hash using the Ed25519 private key.
5. Emit the DKIM-Signature header with a=ed25519-sha256.

Example: Ed25519 DKIM-Signature

DNS Public Key Record

The key record uses k=ed25519 and the public key is dramatically smaller than RSA:

Dual Signing: The Recommended Approach

Not all receivers support Ed25519 yet. RFC 8463 recommends dual signing: apply both an RSA signature and an Ed25519 signature to each message. Receivers that understand Ed25519 can verify the stronger signature; those that don't will fall back to the RSA signature.

Both signatures share the same bh= (body hash) and h= (signed headers) but use different selectors pointing to different key types in DNS.

Key Technical Details

Key Size Comparison

Key Generation

DNS Record Format

The only change from a standard DKIM key record is k=ed25519. All other tags (v=, p=, t=, etc.) work the same as RSA key records:

Receiver Behavior

When a receiver encounters a=ed25519-sha256 in a DKIM-Signature:

1. Look up the DNS key record for the selector.
2. Confirm k=ed25519 in the key record.
3. Decode the 32-byte public key from the p= tag.
4. Verify the Ed25519 signature against the SHA-256 hash of the canonicalized headers.

If the receiver does not support Ed25519, it treats the signature as unverifiable (not a hard failure) and moves on to any other DKIM-Signature headers on the message.

Common Mistakes

• Deploying Ed25519-only without dual signing. Many receivers still do not verify Ed25519 signatures. Dropping RSA means those receivers see no valid DKIM signature, which hurts DMARC alignment and deliverability.
• Incorrect key extraction. Ed25519 public keys in PEM format include an ASN.1 prefix. The DNS p= value must be the raw 32-byte key, not the full DER-encoded SubjectPublicKeyInfo. Getting this wrong produces a key that looks valid but fails verification.
• Using an old OpenSSL version. Ed25519 support was added in OpenSSL 1.1.1 (September 2018). Older versions cannot generate or verify Ed25519 keys. Many Linux distributions shipped older OpenSSL well into 2020.
• Assuming Ed25519 replaces RSA today. Ed25519 is the future direction, but RSA remains the baseline that every DKIM verifier understands. Plan for dual signing for at least the next several years.
• Not testing verification. After publishing the DNS record, send test messages and verify that both signatures validate. Tools like opendkim-testkey can check the DNS record independently.
• Sharing selectors between key types. Use distinct selectors for RSA and Ed25519 keys. A selector can only point to one key type. Attempting to overload a single selector causes verification failures.

Deliverability Impact

• Smaller DNS footprint. Ed25519 keys trivially fit in DNS TXT records, eliminating fragmentation issues that sometimes plague large RSA keys. Fewer DNS-related DKIM failures means more consistent authentication.
• Future-proofing. As RSA key sizes need to grow (2048 → 3072 → 4096), the DNS problem gets worse. Ed25519 provides stronger security with no key-size escalation.
• Faster verification at scale. For high-volume receivers processing billions of messages, Ed25519 verification is meaningfully faster than RSA. This benefits the ecosystem by reducing the computational cost of authentication.
• Demonstrates security maturity. Deploying Ed25519 dual signing shows that a sender actively maintains their authentication infrastructure. While this is not a direct scoring factor, it reflects operational maturity that correlates with good sending practices.
• Dual signing as a safety net. With two independent signatures, a message has two chances to pass DKIM verification. If one signature breaks due to intermediate message modification, the other may survive.

Related RFCs