DKIM Ed25519 vs RSA 2048: Which Algorithm Should You Use in 2026?

DKIM (DomainKeys Identified Mail) uses public key cryptography to sign outbound email messages. The signing algorithm — the mathematical method used to generate the signature — determines both the security strength of the DKIM implementation and the compatibility with receiving mail servers. In 2026, email practitioners face a choice between the established RSA algorithm (with 1024-bit and 2048-bit key sizes) and the more modern Ed25519 elliptic curve algorithm. The choice is consequential: RSA 1024-bit keys are now considered cryptographically broken and should be replaced immediately; RSA 2048-bit remains secure but has a larger DNS footprint; Ed25519 provides stronger security with shorter keys but has incomplete ISP support. This guide documents the current state of each algorithm and provides concrete guidance on what to implement in 2026.

DKIM Signing Algorithms: What Exists and Why It Matters

DKIM signing algorithms are specified in the DKIM-Signature header's a= field. Three algorithm/key-size combinations are in use in commercial email:

rsa-sha256 with 1024-bit key: Specified as a=rsa-sha256 with a 1024-bit RSA public key in the DKIM DNS record. Was the original DKIM standard key size. Now considered cryptographically weak — 1024-bit RSA keys are within the feasible factoring range of well-resourced adversaries using modern hardware and algorithms. NIST, academic cryptographers, and major certificate authorities have deprecated 1024-bit RSA since 2013. For email, 1024-bit DKIM keys expose the domain to the possibility of DKIM signature forgery by a sophisticated adversary. Multiple major ISPs have begun rejecting or downweighting DKIM signatures from 1024-bit keys. Any sender still using 1024-bit DKIM keys in 2026 should treat this as a critical security vulnerability requiring immediate remediation.

rsa-sha256 with 2048-bit key: Specified as a=rsa-sha256 with a 2048-bit RSA public key. The current standard for commercial email DKIM signing. Cryptographically secure against all publicly known attacks as of 2026, with security expected to remain adequate through at least 2030-2035 per NIST guidance. The 2048-bit RSA public key is a longer DNS TXT record than 1024-bit (approximately 400 characters vs 200 characters for the public key data), which is within DNS TXT record size limits but notable for heavily constrained DNS environments.

ed25519-sha256: Specified as a=ed25519-sha256 with a 32-byte Ed25519 public key. Ed25519 is an elliptic curve digital signature algorithm based on Curve25519, providing 128-bit security with much shorter keys than RSA. A 2048-bit RSA key provides approximately 112 bits of security; an Ed25519 key provides approximately 128 bits of security at 1/15th the key size. Ed25519 is specified in RFC 8463 (published 2018) and has growing but not yet universal ISP support.

RSA 1024: Dead in 2026 — Remove It Immediately

If your DKIM public key DNS record contains a key with a modulus length of 1024 bits, this is a critical issue requiring immediate remediation. How to check current DKIM key size:

# Check DKIM key size for a selector:
dig TXT selector._domainkey.yourdomain.com

# The p= value in the result is the base64-encoded public key
# Decode and check key length:
echo "BASE64_VALUE_FROM_DNS" | base64 -d | openssl rsa -pubin -inform DER -text -noout 2>/dev/null | grep "Public-Key:"
# Output example: Public-Key: (2048 bit) = GOOD
#                 Public-Key: (1024 bit) = CRITICAL — replace immediately

# Alternative: use OpenSSL to check the key in a DKIM TXT record
# Extract the p= value from the DNS TXT record
# Feed to openssl to get key size
dig TXT selector._domainkey.yourdomain.com | grep -o 'p=[^;]*' | cut -d= -f2 |   tr -d ' "' | base64 -d | openssl rsa -pubin -inform DER -text -noout 2>/dev/null

# If output shows 1024 bit — generate new 2048-bit keys immediately

Signs that 1024-bit DKIM keys are causing active deliverability problems in 2026: Microsoft began issuing warnings about 1024-bit DKIM keys in 2025 and may reject or downweight signatures using them; Proofpoint corporate gateways may flag 1024-bit DKIM signing as a risk signal; some deliverability scoring tools (Folderly, GlockApps) now actively flag 1024-bit DKIM as a critical issue in their pre-send checks.

The remediation timeline for 1024-bit keys: this is not a "schedule for the next quarter" issue — it is a "fix this week" issue. Generate new 2048-bit RSA keys, publish the new public key DNS records, configure the MTA or ESP to use the new signing keys, verify the new keys are signing correctly, and delete the old 1024-bit key DNS records. The transition from 1024-bit to 2048-bit DKIM takes approximately 2 hours of implementation work. Every additional week of 1024-bit DKIM use after 2026 is an unnecessary security vulnerability and a growing deliverability risk.

RSA 2048: The Safe Default

RSA 2048-bit is the current recommended default for DKIM signing in 2026. Universal ISP support, cryptographically sound, and well-understood operationally. If your organisation is not ready to implement Ed25519 dual signing, RSA 2048 is the correct choice — do not let perfect be the enemy of good here. RSA 2048 DKIM is excellent email security; Ed25519 is marginally better security with shorter keys; the priority order for most programmes is RSA 1024 removal first, Ed25519 implementation second.

The RSA 2048 public key in DNS is longer than Ed25519 but fits comfortably within DNS TXT record limits. The typical RSA 2048 DKIM TXT record looks like:

# Example RSA 2048 DKIM DNS TXT record:
mail._domainkey.brand.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
  "2mX5qLjnDyXVBJXbKHYjBQ2v/3nJ8D5Z4QCuMfj5pL2FmXkqhpTKnHtZR9vQ"
  "wJpDrCa3NbLkYPfX9vGz7+kYMRbCsHJFq5LUhNbR1DXCP9mZrRMa2jTB5Yz"
  "3XsWkJvZ8mPf3tLqcN4uT7mBhJXwAk5bCzQFBvKLPdRSYnKqVjWX5tJFzGaC"
  "..."
  "9xFDKQwABIDAQAB"
)

Note that RSA 2048 public keys are long enough (typically 344 characters in base64) that they often need to be split across multiple quoted strings in the DNS TXT record. Most DNS management tools handle this automatically, but manual DNS entry may require explicit string splitting.

Ed25519: The Modern Alternative

Ed25519 offers three concrete advantages over RSA 2048 for DKIM signing:

Stronger security with shorter keys: Ed25519 provides approximately 128-bit security — stronger than RSA 2048's approximately 112-bit security — with a 32-byte (256-bit) key rather than a 2048-bit key. The shorter key means a significantly shorter DNS TXT record, which reduces DNS lookup overhead and simplifies DNS management. An Ed25519 DKIM TXT record is approximately 70 characters for the key data versus 344+ characters for RSA 2048.

# Example Ed25519 DKIM DNS TXT record (dramatically shorter):
mail._domainkey.brand.com. IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
# Total record: approximately 90 characters vs RSA 2048's 400+ characters

Faster signature verification: Ed25519 signature verification is significantly faster than RSA signature verification (approximately 10x faster for verification operations). For high-volume receiving mail servers processing millions of messages, the aggregate CPU savings from Ed25519 are substantial. While individual senders don't benefit directly from faster verification on receiving servers, the ecosystem benefit of faster DKIM verification supports ISP adoption of Ed25519 checking.

Forward secrecy resistance: Ed25519 keys are more resistant to future cryptographic advances than RSA keys of equivalent security level. The elliptic curve discrete logarithm problem that Ed25519 security is based on is believed to be harder for quantum computers to attack efficiently than the integer factorisation problem that RSA security is based on — though both are vulnerable to sufficiently powerful quantum computers (Shor's algorithm). Ed25519 provides a somewhat longer security runway than RSA at equivalent security levels.

ISP Support for Ed25519 in 2026

Ed25519 DKIM verification support among major ISPs as of 2026:

The ISP support gap that makes dual signing the recommended approach: some corporate mail gateways running older software may not support Ed25519 verification. An email signed only with Ed25519 that arrives at an older mail gateway that does not support Ed25519 may have its DKIM signature fail validation — not because the signature is incorrect, but because the receiving software cannot process the algorithm. This is the reason the single-algorithm Ed25519 approach carries residual risk for programmes sending to corporate email environments.

Dual Signing: Running Both RSA and Ed25519

Dual signing — including two DKIM-Signature headers in each outbound email, one RSA 2048-signed and one Ed25519-signed — is the 2026 best practice for maximum security and maximum compatibility. The receiving mail server uses whichever signature it can verify. Servers that support Ed25519 verify the Ed25519 signature (faster, shorter key, stronger). Servers that only support RSA verify the RSA 2048 signature. Either signature passing counts as DKIM pass.

# PowerMTA dual signing configuration:
<virtual-mta sending-vmta>
  # RSA 2048 signing (universal compatibility):
  dkim-sign domain=brand.com selector=mail2027-rsa     key=/etc/pmta/keys/brand.com.rsa2048.key     algorithm=rsa-sha256     canonicalization=relaxed/relaxed     header-list=from:to:subject:date:message-id

  # Ed25519 signing (modern security):
  dkim-sign domain=brand.com selector=mail2027-ed25519     key=/etc/pmta/keys/brand.com.ed25519.key     algorithm=ed25519-sha256     canonicalization=relaxed/relaxed     header-list=from:to:subject:date:message-id
</virtual-mta>

# Two separate DNS TXT records are required:
# mail2027-rsa._domainkey.brand.com  — RSA 2048 public key
# mail2027-ed25519._domainkey.brand.com  — Ed25519 public key

# Resulting email headers include both signatures:
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=brand.com;
   s=mail2027-ed25519; ...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brand.com;
   s=mail2027-rsa; ...

Implementation: Generating and Deploying DKIM Keys

# Generate RSA 2048-bit DKIM key pair:
openssl genrsa -out brand.com.rsa2048.private.key 2048
openssl rsa -in brand.com.rsa2048.private.key -pubout -out brand.com.rsa2048.public.key

# Generate Ed25519 DKIM key pair:
openssl genpkey -algorithm Ed25519 -out brand.com.ed25519.private.key
openssl pkey -in brand.com.ed25519.private.key -pubout -out brand.com.ed25519.public.key

# Extract base64-encoded public key for DNS:
# RSA 2048:
grep -v "^---" brand.com.rsa2048.public.key | tr -d '
'
# Ed25519 (much shorter):
grep -v "^---" brand.com.ed25519.public.key | tr -d '
'

# Alternative: use opendkim-genkey for both:
opendkim-genkey -b 2048 -d brand.com -s mail2027-rsa -D /etc/dkim/keys/ --subdomains
# Ed25519 not directly supported by opendkim-genkey — use openssl as above

# DNS TXT records to publish:
# For RSA 2048:
mail2027-rsa._domainkey.brand.com IN TXT "v=DKIM1; k=rsa; p=RSA_PUBLIC_KEY_BASE64"

# For Ed25519:
mail2027-ed25519._domainkey.brand.com IN TXT "v=DKIM1; k=ed25519; p=ED25519_PUBLIC_KEY_BASE64"
# Ed25519 public key is approximately 44 characters base64 — fits in one DNS string easily

# Verify after deployment:
dig TXT mail2027-rsa._domainkey.brand.com
dig TXT mail2027-ed25519._domainkey.brand.com

# Test signatures by sending to Gmail and checking Authentication-Results:
# dkim=pass header.i=@brand.com header.s=mail2027-rsa (RSA signature verified)
# dkim=pass header.i=@brand.com header.s=mail2027-ed25519 (Ed25519 signature verified)

Key Rotation Cadence and Security Best Practices

DKIM key rotation — replacing the private key and updating the DNS public key record — is the standard security hygiene practice that limits the exposure window if a private key is compromised. Best practices for 2026:

Rotation frequency: Annual rotation as standard security practice. Immediate rotation after any suspected server compromise that may have exposed the private key file. Some security frameworks (HITRUST, SOC 2 Type II) specify key rotation requirements — check applicable compliance frameworks for mandated rotation frequency.

The rotation procedure: (1) Generate a new key pair with a new selector name (e.g., mail2028-rsa for the new RSA key). (2) Publish the new public key DNS record. (3) Allow 48 hours for DNS propagation. (4) Update the MTA signing configuration to use the new private key and new selector. (5) Verify the new selector is signing correctly using a test send. (6) After confirming the new selector is working, update the DKIM signing configuration to stop using the old selector. (7) After 30 days (to allow any deferred messages signed with the old key to be delivered), remove the old public key DNS record.

Selector naming convention: Use a naming convention that encodes the year and optionally the algorithm: mail2027-rsa, mail2027-ed25519, or mail2027-01 (for programmes that rotate more frequently than annually). This naming convention makes it immediately clear which key is current and which are expired, preventing accidental deletion of the current key or use of an expired key after rotation.

The algorithm choice for DKIM signing — RSA 2048 for universal compatibility, Ed25519 for modern security, dual signing for both — is one of the email authentication decisions that once made correctly does not require frequent revisiting. Set it up correctly with dual signing, document the private key storage locations and rotation schedule, and revisit annually at key rotation time to verify the configuration is still current with best practices. The DKIM algorithm foundation, correctly established, supports all authentication and deliverability work built on top of it.