DKIM Ed25519 vs RSA: Why You Should Be Dual-Signing and How to Do It

DKIM has used RSA as its default signing algorithm since the specification was published in 2007. RSA-1024 was the original standard; RSA-2048 became the recommended minimum around 2013 as computational capacity for factoring 1024-bit keys became feasible. Now, in 2026, the email authentication community is in the early-to-middle stage of a similar transition toward Ed25519 — an elliptic curve algorithm that produces smaller signatures, requires less computation, and is considered more cryptographically forward-looking than RSA at equivalent security levels. The question for operators is not whether to eventually move to Ed25519, but how to do it without breaking DKIM verification for ISPs and corporate gateways that have not yet implemented Ed25519 support. The answer is dual signing — and it is simpler to implement than most operators assume.

What Ed25519 Is and Why It Matters for DKIM

Ed25519 is a specific instantiation of the Edwards-curve Digital Signature Algorithm (EdDSA) using a 255-bit elliptic curve (Curve25519) and the SHA-512 hash function. It was designed by Daniel J. Bernstein and colleagues and published in 2011. DKIM support for Ed25519 was standardised in RFC 8463 in 2018, which added it as an alternative to RSA signing in the DKIM specification.

The practical significance for email: Ed25519 produces DKIM signatures that are substantially smaller than RSA-2048 signatures (68 bytes vs 344 bytes in Base64 encoding). In an era where the DKIM long-header Microsoft failure (documented elsewhere on this site) is a real operational concern, smaller DKIM signatures directly reduce the risk of header length violations. An Ed25519 DKIM-Signature header is 68 bytes. An RSA-2048 DKIM-Signature header is 344 bytes — and when combined with other long headers like List-Unsubscribe, the total header size approaches or exceeds the RFC limits that cause Microsoft to fail DKIM verification.

The cryptographic argument for Ed25519 is also straightforward: at 128-bit security level, Ed25519 key pairs (256-bit private key, 32-byte public key) are significantly smaller and faster than RSA-2048 key pairs (2048-bit keys) that provide equivalent security. Ed25519 is also designed to avoid several implementation pitfalls that RSA is vulnerable to — specifically, it is deterministic (same message always produces same signature, removing the random number generator vulnerability that has affected some RSA implementations) and immune to timing side-channel attacks in well-implemented libraries.

RSA-2048 vs Ed25519: The Technical Comparison

The security level comparison is worth noting: RSA-2048 provides approximately 112-bit equivalent security, while Ed25519 provides approximately 128-bit security. This means Ed25519 is not just smaller and faster — it is also cryptographically stronger at equivalent key sizes. NIST has projected that RSA-2048 will remain secure through 2030 at least, so the security comparison does not create an urgent migration need. But it does mean the transition to Ed25519 is not a lateral move — it is a security upgrade alongside the operational benefits.

The Support Reality in 2026: Who Verifies Ed25519

Ed25519 DKIM verification support in 2026 is broad among major ISPs but incomplete in the enterprise gateway ecosystem:

Ed25519 verified by: Gmail (Google confirmed Ed25519 support in their DKIM verification system); Yahoo Mail; Microsoft 365 (including Exchange Online Protection, which handles filtering for Microsoft 365 tenants); Apple Mail / iCloud Mail; most modern Linux mail server implementations (Postfix with OpenDKIM, Exim, Dovecot, etc.).

Ed25519 support status uncertain or partial: Proofpoint Email Protection — the enterprise gateway used by a significant fraction of large enterprises. Proofpoint has been adding Ed25519 support progressively; specific version support depends on the customer's Proofpoint deployment version, and some on-premises Proofpoint installations may be running older versions that do not verify Ed25519. Barracuda Email Security Gateway — similar situation; cloud-based Barracuda (Barracuda Email Protection) is more likely to support Ed25519 than older on-premises appliance deployments. Cisco Secure Email (formerly IronPort) — older on-premises deployments may not support Ed25519; cloud-based Cisco Secure Email is more likely updated.

The practical implication: for senders whose primary audience is consumer email (Gmail, Yahoo, Outlook.com, Apple Mail), Ed25519 support is broad across their recipient base. For senders targeting enterprise B2B audiences routed through Proofpoint or Barracuda gateways, the support gap may mean Ed25519-only signing causes DKIM verification failure at a non-trivial fraction of recipients. This is why dual signing — not Ed25519 instead of RSA, but Ed25519 in addition to RSA — is the correct transition strategy.

Dual Signing: Getting Ed25519 Benefits Without Compatibility Risk

DKIM allows a single email to contain multiple DKIM-Signature headers — one per signing key and selector combination. When a receiving mail server verifies DKIM, it attempts verification with each DKIM-Signature header it finds. A verifier that supports Ed25519 will successfully verify the Ed25519 signature. A verifier that only supports RSA will skip the Ed25519 signature (which it does not understand) and successfully verify the RSA signature. DKIM overall passes if any signature verifies successfully.

The dual-signing strategy: configure the sending MTA to add two DKIM-Signature headers to every outgoing email — one signed with an Ed25519 key under one selector, and one signed with an RSA-2048 key under a different selector. Recipients with Ed25519 support benefit from the smaller, faster signature. Recipients with only RSA support fall back to the RSA signature. No compatibility risk.

# Example email headers with dual DKIM signing:
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
  d=brand.com; s=ed2026; t=1713744000;
  bh=BASE64_BODY_HASH;
  h=from:to:subject:date:message-id;
  b=BASE64_ED25519_SIGNATURE_68_CHARS
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=brand.com; s=rsa2026; t=1713744000;
  bh=BASE64_BODY_HASH;
  h=from:to:subject:date:message-id;
  b=BASE64_RSA_2048_SIGNATURE_344_CHARS_BASE64

# Two selectors, two public keys in DNS:
# ed2026._domainkey.brand.com  IN TXT "v=DKIM1; k=ed25519; p=BASE64_ED25519_PUBLIC_KEY"
# rsa2026._domainkey.brand.com IN TXT "v=DKIM1; k=rsa; p=BASE64_RSA_PUBLIC_KEY"

Generating Ed25519 DKIM Keys and Publishing DNS Records

# Generate Ed25519 key pair for DKIM:
# OpenSSL 1.1.1+ supports Ed25519

# Generate private key:
openssl genpkey -algorithm ed25519 -out dkim_ed25519_private.pem

# Extract public key in PEM format:
openssl pkey -in dkim_ed25519_private.pem -pubout -out dkim_ed25519_public.pem

# Extract just the base64-encoded public key value (for DNS TXT record):
openssl pkey -in dkim_ed25519_private.pem -pubout -outform DER |   tail -c +13 | base64 -w 0
# The tail -c +13 skips the DER header (first 12 bytes are algorithm OID)
# Output: base64-encoded 32-byte Ed25519 public key — this goes in DNS

# DNS TXT record for Ed25519 selector (replace BASE64_PUBLIC_KEY):
# Selector: ed2026 (use year to facilitate future rotation)
# ed2026._domainkey.brand.com  3600  IN  TXT  "v=DKIM1; k=ed25519; p=BASE64_PUBLIC_KEY"

# Important: Ed25519 public key is only 44 characters in base64
# It fits comfortably in a single DNS TXT string without chunking
# (RSA-2048 public keys often require chunked multi-string DNS records)

# Verify the DNS record is correct after publishing:
dig TXT ed2026._domainkey.brand.com +short
# Should return the TXT record value including v=DKIM1, k=ed25519, p=...

# Test Ed25519 DKIM signing works (after MTA configuration):
# Send a test email and check headers in the received message:
# Look for: DKIM-Signature: v=1; a=ed25519-sha256; ... s=ed2026
# And in Authentication-Results: dkim=pass header.s=ed2026 header.a=ed25519-sha256

PowerMTA Ed25519 DKIM Configuration

# PowerMTA dual signing configuration (/etc/pmta/config):
# Requires PowerMTA 5.x or later (Ed25519 support added in 5.x series)

# Store the Ed25519 private key in a file:
# /etc/pmta/dkim/brand.com.ed25519.key
# File content is the raw PEM private key from openssl genpkey

# DKIM signing configuration with both Ed25519 and RSA:
<dkim-signing>
  domain brand.com
  
  # Ed25519 signing (selector: ed2026)
  signing-algorithm ed25519-sha256
  selector ed2026
  private-key /etc/pmta/dkim/brand.com.ed25519.key
  header-list from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post
  
  # RSA signing (selector: rsa2026) — add second signing block
  signing-algorithm rsa-sha256
  selector rsa2026
  private-key /etc/pmta/dkim/brand.com.rsa2048.key
  header-list from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post
</dkim-signing>

# PowerMTA will add both DKIM-Signature headers to every outgoing email
# from brand.com

# Verify dual signing is working:
# pmta show dkim-signing
# Should list both ed25519-sha256 and rsa-sha256 configurations

# Monitor for signing errors in:
# /var/log/pmta/log
# Look for: "dkim signing failed" or "cannot load private key"

Postfix + OpenDKIM Ed25519 Configuration

# OpenDKIM version 2.10.3+ supports Ed25519
# Check: opendkim --version

# /etc/opendkim.conf — dual signing configuration:
Mode                    s
Domain                  brand.com

# Signing table maps sender addresses to key table entries
# /etc/opendkim/signing.table:
# *@brand.com    brand.com:ed2026:/etc/opendkim/keys/brand.com.ed25519.private
# *@brand.com    brand.com:rsa2026:/etc/opendkim/keys/brand.com.rsa2048.private
# Note: OpenDKIM supports multiple entries for the same sender for dual signing

# Key table maps selector names to key files
# /etc/opendkim/key.table:
# ed2026._domainkey.brand.com  brand.com:ed2026:/etc/opendkim/keys/brand.com.ed25519.private
# rsa2026._domainkey.brand.com brand.com:rsa2026:/etc/opendkim/keys/brand.com.rsa2048.private

# Generate keys with opendkim-genkey:
# RSA-2048 (the usual way):
cd /etc/opendkim/keys
opendkim-genkey -t -s rsa2026 -d brand.com -b 2048

# Ed25519 (requires newer opendkim):
opendkim-genkey -t -s ed2026 -d brand.com --type ed25519
# This generates ed2026.private (private key) and ed2026.txt (DNS record to publish)

# Set permissions:
chown -R opendkim:opendkim /etc/opendkim/keys
chmod 600 /etc/opendkim/keys/*.private

# Restart OpenDKIM after configuration:
systemctl restart opendkim

# Verify signing:
# opendkim-testkey -d brand.com -s ed2026 -v
# Should return: ed2026._domainkey.brand.com... key OK

When to Stay with RSA-2048 Only

Dual signing adds operational complexity: two key pairs to manage, two DNS records to maintain, two selectors to rotate annually. For some deployments, this complexity is not worth the benefit. The situations where RSA-2048 only remains the correct choice:

Heavily B2B enterprise audience with older Proofpoint: If your analysis of your recipient domain mix shows significant fractions of corporate email protected by on-premises Proofpoint or Barracuda deployments on older versions, adding Ed25519 dual signing provides minimal benefit (the enterprise verifiers do not use it) while adding operational complexity. Revisit when Ed25519 support becomes more universal in enterprise gateway products — which is happening but not yet complete across all deployment versions.

Sending infrastructure that does not support Ed25519: If you are on an ESP or MTA version that does not support Ed25519 signing, RSA-2048 is the only option until you upgrade. Check your MTA version before planning an Ed25519 deployment — PowerMTA 4.x and older OpenDKIM versions do not support Ed25519.

Very low sending volume where signature size is irrelevant: The Microsoft long-header DKIM failure is most likely to occur when List-Unsubscribe headers are very long and the DKIM signature adds to the total header size over the RFC limit. At low sending volumes with short, clean headers, RSA-2048 signature size does not create practical problems. The operational complexity of dual signing is not justified by marginal technical benefits in this scenario.

For high-volume senders targeting consumer email (Gmail, Yahoo, Outlook.com, Apple Mail), dual signing is worth implementing today. The benefits — smaller signatures, faster verification, reduced Microsoft long-header risk, cryptographic modernity — are real. The implementation is straightforward with current MTA software. The operational overhead of managing two key pairs is modest. Start with dual signing as a pilot on a low-volume sending domain, verify both signatures are appearing in received email headers and passing verification, then extend to production sending domains. The gradual rollout approach lets you confirm Ed25519 works correctly in your specific infrastructure before committing to it across all sending domains.

One final operational note that the specifications do not address clearly: selector naming conventions for dual signing. Since Ed25519 and RSA each get their own selector, I recommend naming conventions that make the algorithm and rotation year immediately obvious — ed2026 and rsa2026, for example. This makes the DKIM-Signature header human-readable (you can see at a glance which algorithm a received email used) and makes annual key rotation straightforward (create ed2027/rsa2027, publish the new DNS records, update the MTA configuration to sign with the new selectors, deprecate ed2026/rsa2026 after 30 days). The naming convention is a small operational detail that pays dividends every time you are debugging a DKIM failure or planning a key rotation — which, in a production sending environment, is more often than you might expect.