RSA-SHA256 and Ed25519-SHA256 are distinct DKIM signature algorithms. Choose between, or deploy both, using the supported capabilities of your signer and the evidence from relevant verifiers. Comparing their raw key lengths does not answer the interoperability question.
Separate specification support from deployed support
RFC 8463 sections 3–5 adds Ed25519-SHA256 to DKIM and requires verifiers implementing that update to support it. It recommends signer implementation. Those requirements describe the standard; they do not establish that every installed mail appliance, old library or hosted interface implements the update today.
The Ed25519 key record uses k=ed25519, and its public key is encoded in p=. The signature algorithm is identified as a=ed25519-sha256. For RSA, the corresponding algorithm is rsa-sha256; RFC 8301 section 3 supplies the updated RSA size requirements and prohibits rsa-sha1. Do not change only the algorithm label while keeping incompatible key material.
Decide what evidence the migration needs
Inventory the signing software, version, supported algorithms and provider controls. Identify the receiving systems whose behaviour matters to the business. Record whether the test result reflects your own verifier library, the final recipient's trusted authentication result or a third-party analysis tool. These are different observations.
Ask whether the platform can emit both algorithms and manage two selectors safely. A provider that offers no Ed25519 control may still have a documented RSA configuration suitable for the task. Do not invent an unsupported procedure merely because the underlying RFC permits a configuration.
Use distinct selectors for parallel signatures
RFC 8463 section 6 describes multiple signatures as a transition mechanism. RSA and Ed25519 keys need distinct selectors. Do not place two algorithm keys at one selector and rely on the recipient to choose your preferred one.
In an illustrative design, rsa2026._domainkey.example.com holds the RSA verification data and ed2026._domainkey.example.com holds the Ed25519 data. Both signatures use d=example.com, but their s= and a= values differ. These are example names, not deployable key records. Generate and publish actual key material through the supported signing system.
A useful test records each signature independently. Receiver A might verify both; receiver B might verify only RSA. Do not report “dual signing works” without preserving which algorithm produced each result. Under RFC 9989 section 4.4.1, a successful aligned RSA signature can provide a DMARC authentication path even when the other signature does not verify, provided the applicable DMARC evaluation conditions are met.
Make the cutover reversible
Before changing production, establish a supported method to restore the previous signing configuration. Test normal messages and the real routing features, such as gateways or mailing lists. Algorithm support does not protect a signature from arbitrary content changes after signing.
During the observation period, keep selector inventory and receiver evidence tied to timestamps. A successful DNS lookup of the Ed25519 record proves publication, not that the sender emitted a signature or that a recipient used it. Decide whether to retain both algorithms or change the configuration based on measured compatibility and organisational requirements, not a claim that all receivers have upgraded.
Close the security and operations decision together
Record the selected design, algorithm-specific results, unresolved recipient limitations and criteria for retiring a compatibility path. Continue to protect both private keys while both signers remain active. Dual signing adds another key-management dependency; it does not remove the need for custody, rotation or incident response.
Read a synthetic dual-signature result
Assume a message has Author Domain example.com and two signatures with d=example.com. The trusted receiver reports rsa-sha256, s=rsa2026, pass for one signature and ed25519-sha256, s=ed2026, fail for the other. The RSA signature is an exact aligned pass, so it can satisfy DMARC’s DKIM path. The failed Ed25519 signature does not cancel it. This is a constructed example, not evidence that a receiver lacks Ed25519 support: failure could instead concern its key, syntax or signed content. Preserve the per-signature reason before diagnosing compatibility.
Keep a compact investigation record
Use this suggested worksheet for the route under review. It is a planning aid, not evidence of an executed test.
- Signer: software or service, version and supported algorithm controls.
- Per signature: a, d, s, result and receiver that produced the result.
- DMARC: Author Domain, alignment mode and the passing aligned signature, if any.
- Decision: retain both algorithms or retire one, with rollback steps and unresolved recipient limitations.
Related reading
DKIM key length and algorithms: check current receiver support · Multiple DKIM signatures: find the aligned passing signature.