KoltrixEd25519 DKIM: should you dual-sign yet?
RFC 8463 added Ed25519 to DKIM, but receiver support is uneven. Learn how dual signing with RSA works and whether it is worth the operational cost.
On this page(9 sections)
- What RFC 8463 added
- The catch: verifier support
- How dual signing works
- What dual signing costs
- Operational complexity
- Message size
- Debugging noise
- What dual signing buys you
- Readiness for an RSA transition
- Smaller DNS records
- Defense in depth against key compromise
- Signal to receivers that support it
- Who should do it now
- Generating an Ed25519 DKIM key
- Checklist for adding Ed25519
- Bottom line
Ed25519 DKIM signatures are smaller, faster and arguably more secure than RSA. They have also been standardized since 2018 and are still not something you can rely on by themselves.
The interesting question is not whether Ed25519 is better, but whether adding it today buys you anything.
What RFC 8463 added
RFC 8463 defined a new DKIM signing algorithm, ed25519-sha256, using the Ed25519 elliptic curve signature scheme. A DKIM key record for it looks like this:
e2026._domainkey.example.com. TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="Compare that with a 2048-bit RSA record, whose p= value is around 392 base64 characters and has to be split across multiple TXT strings. An Ed25519 public key is 32 bytes, 44 characters in base64. Signatures are 64 bytes instead of 256. Signing and verifying are fast.
Security-wise, Ed25519 offers strength roughly comparable to 3072-bit RSA, with a design that is harder to implement badly. Notably, it does not depend on random numbers at signing time, which removes a class of implementation failures.
The catch: verifier support
A signature only helps if receivers can verify it. RFC 8463 says verifiers should implement the new algorithm, but support has rolled out unevenly. Some mail software and filtering systems verify Ed25519 signatures; others ignore them as an unknown algorithm. Support among the very largest mailbox providers has historically lagged, and their public documentation does not always say what they verify.
When a verifier does not support an algorithm, it cannot validate that signature, and RFC 6376 tells verifiers to ignore failed signatures as though they were not present. A message carrying a second, valid signature is judged on that one. That is what makes dual signing safe.
How dual signing works
A message can carry more than one DKIM-Signature header. Each is independent, with its own algorithm, selector and key. You sign each outgoing message twice:
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=example.com; s=e2026; h=from:to:subject:date; bh=...; b=...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=r2026; h=from:to:subject:date; bh=...; b=...A receiver that supports Ed25519 verifies that signature (and probably the RSA one too). A receiver that does not support it skips it and verifies the RSA signature. For DMARC, one aligned passing signature is enough.
Order generally does not matter for verification, but many implementations add the newer algorithm signature on top.
What dual signing costs
Operational complexity
You now manage two keys, two selectors and two rotation schedules. Your signer must support both algorithms. Monitoring needs to distinguish "Ed25519 not verified because unsupported" from "Ed25519 failed because broken."
Message size
Each signature adds a header of a few hundred bytes. That is negligible for most mail, but it is not zero.
Debugging noise
Some receivers report results for every signature in Authentication-Results. You will see entries like dkim=pass header.s=r2026 alongside dkim=neutral or dkim=permerror for the Ed25519 signature at receivers that do not support it, depending on how they log unknown algorithms. Teams unfamiliar with the setup may chase those as errors.
What dual signing buys you
Readiness for an RSA transition
If RSA ever needs to be retired from DKIM, whether due to cryptanalytic advances, policy changes or a push toward smaller signatures, domains already signing with Ed25519 will have working keys, tested signers and real-world verification data.
Smaller DNS records
The Ed25519 key record fits in one string with lots of room to spare. That avoids the multi-string TXT handling problems that sometimes break 2048-bit RSA records, although you still need the RSA record for now.
Defense in depth against key compromise
Two independent keys mean that if one private key leaks, the other is unaffected. In practice the benefit is limited, because an attacker who has the RSA key can still produce RSA signatures that receivers accept. Do not count this as a major reason.
Signal to receivers that support it
Some filtering systems may give slightly more confidence to modern cryptography, but we are not aware of evidence that major mailbox providers reward Ed25519 signatures with better placement. Treat that as a non-reason.
Who should do it now
Dual signing is worth it if:
- Your signer supports Ed25519 natively (several open source signing tools do).
- You already have mature DKIM operations: documented selectors, rotation and monitoring.
- You run your own mail infrastructure and care about forward compatibility.
It is probably not worth it if:
- You rely on a sending provider that does not offer it. Adding a second signer in your path just to add Ed25519 introduces more risk than it removes.
- Your basic DKIM setup is still shaky. Fix alignment, key length and rotation first.
Generating an Ed25519 DKIM key
With OpenSSL 1.1.1 or later:
openssl genpkey -algorithm ed25519 -out e2026.private
openssl pkey -in e2026.private -pubout -outform der | tail -c 32 | base64The tail -c 32 strips the DER wrapper; RFC 8463 specifies that the p= value is the raw 32-byte public key in base64, not a DER-encoded structure. That is a common mistake when people adapt RSA tooling.
Publish it with k=ed25519 and confirm with dig:
dig +short TXT e2026._domainkey.example.comChecklist for adding Ed25519
- Keep your RSA 2048-bit signature; Ed25519 is an addition, never a replacement yet.
- Use a separate selector for the Ed25519 key.
- Publish
k=ed25519with the raw 32-byte key in base64. - Configure the signer to add both signatures to every message.
- Confirm the RSA signature passes everywhere and note which receivers report the Ed25519 result.
- Add the new selector to your rotation register.
Bottom line
Ed25519 is a better algorithm, and RFC 8463 makes it a first-class DKIM option. Because support among receivers is incomplete, it only makes sense today as a second signature next to RSA. If your signer supports it and your DKIM operations are already solid, dual signing is cheap insurance for the future. If not, spend the effort on alignment and key hygiene first.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
