RSA-SHA256 和 Ed25519-SHA256 不同 DKIM签名 算法。使用签名者支持的功能和相关验证者的证据进行选择或部署两者。比较它们的原始密钥长度并不能回答互操作性问题。
将规范支持与部署支持分开
RFC 8463第 3-5 节 将 Ed25519-SHA256 添加到 DKIM 并要求验证者实施该更新来支持它。它建议签名者实施。这些要求描述了标准；他们并没有确定每个已安装的邮件设备、旧库或托管接口今天都实现了更新。
这 埃德25519 关键记录用途 k=ed25519，其公钥编码为 p=。签名算法确定为 a=ed25519-sha256。对于RSA，对应的算法是 rsa-sha256; RFC 8301第 3 节 提供更新的 RSA 大小要求并禁止 rsa-sha1。不要仅更改算法标签，同时保留不兼容的密钥材料。
确定迁移需要什么证据
清点签名软件、版本、支持的算法和提供商控制。识别其行为对业务很重要的接收系统。记录测试结果是否反映您自己的验证器库、最终接收者的可信认证结果或第三方分析工具。这些是不同的观察结果。
询问该平台是否可以发出两种算法并安全地管理两个选择器。不提供 Ed25519 控制的提供商可能仍然拥有适合该任务的记录的 RSA 配置。不要仅仅因为底层 RFC 允许配置就发明不受支持的过程。
使用不同的选择器进行并行签名
RFC 8463第 6 节 将多重签名描述为一种转换机制。 RSA 和 Ed25519 密钥需要不同的选择器。不要将两个算法密钥放在一起 选择器 并让收件人选择您喜欢的。
在说明性设计中， rsa2026._domainkey.example.com 保存RSA验证数据和 ed2026._domainkey.example.com 保存 Ed25519 数据。两个签名都使用 d=example.com，但是他们的 s= 和 a= 价值观不同。这些是示例名称，而不是可部署的密钥记录。通过支持的签名系统生成并发布实际的密钥材料。
有用的测试独立记录每个签名。接收方 A 可能会验证两者；接收方 B 可能仅验证 RSA。不要在不保留生成每个结果的算法的情况下报告“双重签名工作”。在下面 RFC 9989第 4.4.1 节，成功对齐的 RSA 签名可以提供 DMARC 只要满足适用的DMARC评估条件，即使其他签名未验证，也可以使用身份验证路径。
使切换可逆
在更改生产之前，建立受支持的方法来恢复以前的签名配置。测试正常消息和真实路由功能，例如网关或邮件列表。算法支持不能保护签名在签名后免受任意内容更改。
在观察期间，将选择者清单和接收者证据与时间戳相关联。对 Ed25519 记录的成功DNS查找证明了发布，而不是发件人发出了签名或收件人使用了该签名。根据测量的兼容性和组织要求决定是否保留两种算法或更改配置，而不是声称所有接收器都已升级。
将安全和运营决策结合在一起
记录所选的设计、特定于算法的结果、未解决的接收者限制以及停用兼容性路径的标准。在两个签名者保持活动状态的同时继续保护两个私钥。双重签名增加了另一个密钥管理依赖性；它并不能消除监管、轮换或事件响应的需要。
读取合成双重签名结果
假设一条消息具有作者域example.com和两个带有d=example.com.受信任的接收方报告 rsa-sha256， s=rsa2026,通过一个签名，并报告 ed25519-sha256， s=ed2026,对另一个签名失败。 RSA 签名是精确对齐的传递，因此它可以满足DMARC的DKIM路径。失败的 Ed25519 签名不会取消它。这是一个构造的示例，并不是接收器缺乏 Ed25519 支持的证据：失败可能与它的密钥、语法或签名内容有关。在诊断兼容性之前保留每个签名的原因。
保留紧凑的调查记录
使用此建议的工作表来查看正在审查的路线。它是一种规划辅助工具，而不是已执行测试的证据。
- 签名者：软件或服务、版本和支持的算法控制。
- 每个签名：a、d、s、结果和产生结果的接收者。
- DMARC ：作者域， 结盟 模式和传递的对齐签名（如果有）。
- 决定：保留两种算法或淘汰一种算法，并进行回滚步骤和未解决的收件人限制。
相关阅读
DKIM密钥长度 和算法：检查当前接收器支持 · 多个DKIM签名：找到对齐的传递签名.