RFC 8463: 用于 DKIM 签名的 Ed25519
ELI5: DKIM 最初使用 RSA 密钥——与保护大多数网络的密钥类型相同。但 RSA 密钥体积庞大：2048 位公钥在 DNS TXT 记录中占用 400+ 个字符。Ed25519 是一种更新的、更精简的锁，强度相同，但密钥仅占用 44 个字符。更小的密钥、更快的验证、相同的信任——这就是 RFC 8463 为 DKIM 带来的内容。
为什么要这样做
DKIM (RFC 6376) 最初仅指定 RSA 用于签名。RSA 一直表现良好，但它也带来了成本：
- 密钥较大。2048 位 RSA 公钥是约 400 字节的 Base64 编码。DNS TXT 记录每个字符串的实际限制约为 255 字节（大多数解析器支持最多约 4096 字节），使得大型 RSA 密钥在 DNS 中显得笨重，有时不稳定。
- 验证速度慢。RSA 签名验证，尤其是使用较大密钥时，在接收方每小时处理数百万条消息时会消耗可测量的 CPU 时间。
- 密钥大小升级。RSA 安全性取决于密钥长度。随着计算能力增长，2048 位密钥最终需要变成 3072 或 4096 位，使 DNS 问题更加恶化。
Ed25519（使用 Curve25519 的 Edwards 曲线数字签名算法）解决了这三个问题。其 256 位密钥提供的安全性相当于大约 3072 位 RSA，公钥仅 32 字节（44 个 Base64 字符），验证速度明显更快。
工作原理
使用 Ed25519 签名
签名过程与标准 DKIM 相同，有两处变化：a= 标签使用 ed25519-sha256 而不是 rsa-sha256，私钥是 Ed25519 密钥而不是 RSA 密钥。
- 按 RFC 6376 规则规范化报头和正文。
- 计算规范化正文的 SHA-256 哈希（
bh=标签）。 - 计算已签名报头加正文哈希的 SHA-256 哈希。
- 使用 Ed25519 私钥签名报头哈希。
- 使用
a=ed25519-sha256发送DKIM-Signature报头。
示例：Ed25519 DKIM-Signature
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
d=example.com; s=ed202601;
h=from:to:subject:date:message-id:mime-version:content-type;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=Tg2ByC4LSy9F1F6xAQchD8JFh6kYH7aKQjO6Sn7XIkfJVOzv8RBVOzv8QjO6S
n7XIkfJV==
DNS 公钥记录
密钥记录使用 k=ed25519，公钥比 RSA 小得多：
; Ed25519 DKIM 密钥 — 注意 p= 值有多紧凑
ed202601._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
; 与 RSA 2048 位密钥相比 — 大得多
rsa202601._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2UMfREvlgajdSp3jv1oI...已截断 (392 个字符)..."
双签名：推荐方法
还不是所有接收方都支持 Ed25519。RFC 8463 推荐双签名：对每条消息应用 RSA 签名和 Ed25519 签名。理解 Ed25519 的接收方可以验证更强的签名；不支持的接收方将降级到 RSA 签名。
; 具有两个 DKIM-Signature 报头的消息：
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
d=example.com; s=ed202601;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=Tg2ByC4LSy9F1F6xAQchD8JFh6kYH7aK...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=rsa202601;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=LjIEJLNOTAREALh8gAiGVQOr3K7qO6Sn7XIkfJV...
两个签名共享相同的 bh=（正文哈希）和 h=（已签名报头）但使用指向 DNS 中不同密钥类型的不同选择器。
关键技术细节
密钥大小比较
| 属性 | RSA-2048 | Ed25519 |
|---|---|---|
| 安全级别（位） | ~112 | ~128 |
| 公钥大小 (Base64) | ~392 个字符 | 44 个字符 |
| 签名大小 (Base64) | ~344 个字符 | 88 个字符 |
| 签名速度 | 中等 | 快速 |
| 验证速度 | 快速 | 非常快速 |
| DNS TXT 记录大小 | 紧凑，可能需要拆分 | 轻松适应单个字符串 |
密钥生成
# 使用 OpenSSL 1.1.1+ 生成 Ed25519 密钥对
openssl genpkey -algorithm Ed25519 -out ed25519_private.pem
# 提取公钥
openssl pkey -in ed25519_private.pem -pubout -out ed25519_public.pem
# 获取用于 DNS 的原始 Base64 公钥（剥离 PEM 报头）
openssl pkey -in ed25519_private.pem -pubout -outform DER | tail -c 32 | base64
11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=
# 在 DNS 中发布为：
# ed202601._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
DNS 记录格式
与标准 DKIM 密钥记录相比的唯一变化是 k=ed25519。所有其他标签（v=、p=、t= 等）的工作方式与 RSA 密钥记录相同：
; 必需的标签
v=DKIM1 ; 版本（始终为 DKIM1）
k=ed25519 ; 密钥类型（默认为 "rsa"）
p=<base64> ; 44 个字符的公钥
; 可选标签（与 RSA 相同）
t=s ; 严格模式：d= 必须完全匹配 From 域
t=y ; 测试模式：接收方不应将失败视为明确的
接收方行为
当接收方在 DKIM-Signature 中遇到 a=ed25519-sha256 时：
- 查找选择器的 DNS 密钥记录。
- 确认密钥记录中的
k=ed25519。 - 从
p=标签解码 32 字节公钥。 - 针对规范化报头的 SHA-256 哈希验证 Ed25519 签名。
如果接收方不支持 Ed25519，则将签名视为无法验证（不是硬失败）并继续查看消息上的任何其他 DKIM-Signature 报头。
常见错误
- 仅部署 Ed25519 而不双签名。许多接收方仍然无法验证 Ed25519 签名。放弃 RSA 意味着这些接收方看不到有效的 DKIM 签名，这会损害 DMARC 对齐和可递送性。
-
密钥提取不正确。PEM 格式的 Ed25519 公钥包含 ASN.1 前缀。DNS
p=值必须是原始 32 字节密钥，而不是完整的 DER 编码 SubjectPublicKeyInfo。出错会产生看起来有效但验证失败的密钥。 - 使用旧版本的 OpenSSL。Ed25519 支持在 OpenSSL 1.1.1 中添加（2018 年 9 月）。较旧版本无法生成或验证 Ed25519 密钥。许多 Linux 发行版在 2020 年之前仍然附带旧版 OpenSSL。
- 假设 Ed25519 今天替代 RSA。Ed25519 是未来方向，但 RSA 仍然是每个 DKIM 验证器理解的基线。在至少未来几年内规划双签名。
-
不测试验证。发布 DNS 记录后，发送测试消息并验证两个签名都能验证。
opendkim-testkey等工具可以独立检查 DNS 记录。 - 在密钥类型之间共享选择器。为 RSA 和 Ed25519 密钥使用不同的选择器。选择器只能指向一个密钥类型。尝试重载单个选择器会导致验证失败。
可递送性影响
- DNS 占用空间更小。Ed25519 密钥轻松适应 DNS TXT 记录，消除有时困扰大型 RSA 密钥的碎片化问题。更少的 DNS 相关 DKIM 失败意味着更一致的身份验证。
- 面向未来。随着 RSA 密钥大小需要增长（2048 → 3072 → 4096），DNS 问题变得更糟。Ed25519 提供更强的安全性而无需密钥大小升级。
- 大规模验证速度更快。对于处理数十亿条消息的高容量接收方，Ed25519 验证比 RSA 明显更快。这通过减少身份验证的计算成本使整个生态系统受益。
- 展示安全成熟度。部署 Ed25519 双签名表明发送方积极维护其身份验证基础设施。虽然这不是直接的评分因素，但它反映了与良好发送实践相关的运营成熟度。
- 双签名作为安全网。有两个独立签名，消息有两次通过 DKIM 验证的机会。如果一个签名因为中间消息修改而破裂，另一个可能存活。