How widely supported are Ed25519 DKIM keys and how many providers still accept weak keys?

Email authentication is evolving, and Ed25519 DKIM keys promise clear advantages over traditional RSA: smaller keys, faster verification, and stronger cryptographic guarantees. But those benefits only matter if mailbox providers actually support the standard. To find out, Red Sift analyzed DKIM behavior across major email platforms to answer critical questions for email administrators: can Ed25519 keys be deployed safely today without risking authentication failures?

We also tested how providers handle weak DKIM keys, including sub-1024-bit RSA keys that should be rejected, to see where critical security gaps remain. The results show which providers have embraced modern cryptography, which are lagging, and what that means for your email security strategy.

Ed25519 is a modern elliptic curve signature algorithm that offers compelling advantages over traditional RSA keys for DKIM. While RSA-2048 uses 2048-bit keys, Ed25519 achieves equivalent or better security with just 256 bits—an 8x reduction that’s particularly valuable for DNS records where space is limited.

Ed25519 signature verification is also 10-20x faster than RSA-2048, reducing computational overhead for mailbox providers processing high email volumes. The algorithm provides approximately 128 bits of security (comparable to RSA-3072) and is resistant to timing attacks by design, eliminating a common vulnerability in RSA implementations.

We tested 19 major mailbox providers by sending emails signed with five different DKIM key configurations:

• 512-bit RSA (cryptographically weak, factored in hours)
• 768-bit RSA (weak, factored in months with moderate resources)
• 1536-bit RSA (acceptable, but not standard)
• 4096-bit RSA (strong, potentially computationally expensive)
• Ed25519 (256-bit elliptic curve, modern standard)

Each provider received test emails from domain dkim.testsift.com with corresponding DKIM selectors. We then examined Authentication-Results headers, or other provider-proprietary headers, to determine whether signatures passed, failed, or were rejected for policy reasons.

Only 9 out of 19 providers (47%) successfully validate Ed25519 DKIM signatures:

• Fastmail
• GMX
• HEY
• Hostpoint
• LaPoste (FR)
• MXroute
• Migadu
• Proton Mail
• Soverin

The most concerning finding: Gmail, Microsoft 365, and Yahoo (which collectively handle the majority of global email traffic) do not support Ed25519. This makes widespread Ed25519 deployment risky for domains that rely on DMARC policies, as failed DKIM validation contributes to DMARC failures.

While 68% of providers correctly reject cryptographically weak keys (512-bit and 768-bit RSA), 6 providers still accept them:

• HEY – Passes both 512-bit and 768-bit signatures
• LaPoste (FR) – Accepts weak keys with “good signature” status
• Migadu – No key length validation
• Proofpoint Essentials – Validates weak signatures
• Soverin – Passes signatures regardless of key strength
• mailbox.org – Accepts 512-bit and 768-bit keys

These providers create a security vulnerability. A 512-bit RSA key can be factored in hours using commodity hardware, allowing attackers to forge DKIM signatures for any domain using weak keys. Even 768-bit keys are vulnerable; they were publicly factored in 2009.

The following 13 providers correctly reject sub-1024-bit keys, enforcing minimum security standards:

• Comcast – “signing key too small”
• Fastmail – “Key length 512/768 too short”
• GMX – Explicit failure on weak keys
• Gmail – “policy (weak key)”
• Hostpoint – “public key too short”
• Microsoft 365 – “ignored public key size” (treated as policy violation)
• MXroute – “pubkey_too_short”
• MailChannels – Returns temperror for weak keys
• Proton Mail – “signing key too small” with bit length reporting
• Rackspace – “signing key too small”
• Tuta – “key length is too short”
• Yahoo – perm_fail on weak keys
• iCloud – “signing key too small” with policy reason

Gmail’s approach is particularly noteworthy: it explicitly marks weak keys with a dkim=policy (weak key) result, making the security issue visible in headers while still processing the email. This allows administrators to identify vulnerable configurations without immediate delivery impact.

Certain platforms, such as Cisco’s CES (formerly IronPort), have configurable options to reject or quarantine messages with weak keys.

All 19 tested providers successfully validated both 1536-bit and 4096-bit RSA keys without issue. This demonstrates that concerns about compatibility problems with larger key sizes are unfounded. Providers have no trouble handling keys well above the 1024-bit minimum, including non-standard sizes like 1536-bit.

The universal acceptance of 4096-bit keys confirms that organizations can deploy stronger RSA keys without risking delivery problems, though the computational overhead on receiving servers increases with key size.

Only 5 providers implement both best practices—supporting modern Ed25519 keys while rejecting weak RSA keys:

• Fastmail
• GMX
• Hostpoint
• MXroute
• Proton Mail

This creates an uncomfortable tradeoff for email administrators. Deploying Ed25519 keys risks authentication failures at Gmail, Microsoft 365, and Yahoo—the three largest providers by volume. Yet sticking with RSA means larger DNS records, continued computational overhead for receiving mail servers, and compatibility with the six providers that would validate even a trivially-weak 512-bit signature.

• Deploy RSA-2048 for maximum compatibility
• Audit your current DKIM keys—if any are below 1024 bits, rotate immediately and make sure you’re signing with at least 1024 bits, preferably 2048.
• Monitor Authentication-Results headers to identify providers treating weak keys as valid
• For the email geeks: consider dual-signing (RSA + Ed25519) if your mail infrastructure supports it, though this adds complexity and is mostly a novelty right now.

• Ed25519 adoption is growing but remains incomplete among tier-1 providers
• DMARC failure rates may increase if Ed25519 is deployed without careful provider analysis
• The six providers accepting weak keys represent an exploitable vulnerability in the email ecosystem

• Rejecting weak keys should be universal—512-bit and 768-bit RSA keys are cryptographically broken
• Ed25519 support should be prioritized given its standardization in RFC 8463 (published September 2018)
• Clear error messaging (like Gmail’s weak key policy flag) helps administrators identify and fix issues

The email authentication landscape shows a troubling split. While nearly half of tested providers support modern Ed25519 signatures, the three largest providers—Gmail, Microsoft 365, and Yahoo—do not, making broad Ed25519 deployment premature for most organizations. Simultaneously, six providers continue accepting cryptographically weak keys that should have been rejected years ago, creating an exploitable gap in email security.

Email administrators face a waiting game: Ed25519 offers real security and performance benefits, but deploying it today means accepting authentication failures at major providers. Until Gmail, Microsoft, and Yahoo implement RFC 8463, RSA-2048 or RSA-4096 remains the only viable choice for universal compatibility. The priority should be eliminating weak keys from the ecosystem—any domain still using sub-1024-bit DKIM keys is vulnerable to signature forgery and should rotate immediately.

The path forward requires coordinated action: providers must implement Ed25519 support and enforce minimum key lengths, while senders must audit their DKIM configurations and eliminate weak keys. Until broad Ed25519 adoption, the promise of modern email cryptography remains partially unfulfilled. Beyond that, the eventual need for post-quantum signature algorithms looms—though the timeline and standards remain uncertain, both RSA and Ed25519 will eventually be vulnerable to quantum attacks.