签名的消息仍然可能是垃圾邮件。其签名域也可能与接收方看到的地址不同。
DKIM 签名覆盖哪些内容？
DKIM 签名保护选定的请求头字段和正文的哈希值。
h= 标签列出签名的请求头字段。bh= 标签保存正文哈希。发送服务器使用私钥生成签名。接收方使用对应的公钥进行验证。
接收方重新计算正文哈希，同时验证选定请求头和签名请求头上的签名，签名请求头中包含该哈希值。
RFC 6376 要求对 From 请求头签名。其他请求头字段可以不签名。因此，添加未签名的 Reply-To 不会使 DKIM 失效。
重复的请求头需要单独处理。签名者可以将某个请求头名称列出超过其实际出现次数，以防止未被检测到的新增。
接收方在哪里找到公钥？
接收方使用签名域和选择器（标识该密钥的名称）定位公钥。d= 标签提供域名。s= 标签提供选择器。
对于 d=example.com 和 s=foo.bar，查找名称为 foo.bar._domainkey.example.com。选择器允许在同一签名域下使用不同的密钥。
轮换密钥时，先发布替换密钥，再用它签名。在使用旧密钥签名的消息仍在传输期间，保持旧验证密钥可用。过早移除会导致接收方无法验证这些消息。
为什么格式变化会破坏签名？
规范化（签名和验证前应用的标准化处理）决定了 DKIM 能容忍哪些格式变化。
c= 标签为请求头和正文分别选择算法。在 relaxed/relaxed 中，两者都使用 relaxed 规范化。
| 算法 | 请求头行为 | 正文行为 |
|---|---|---|
simple | 保留请求头格式 | 忽略末尾的空行 |
relaxed | 规范化请求头名称大小写、折叠和空白 | 规范化空白和末尾空行 |
折叠的请求头会延续到下一行。Relaxed 请求头处理容许这种折叠。Simple 处理在服务器重新折叠同一请求头后可能失败。
比较失败中继前后的签名内容，因为不可见的格式变化可以解释该结果。
DKIM 支持哪些签名算法？
DKIM 支持 RSA 和 Ed25519 签名算法，两者均与 SHA-256 结合使用。
根据 RFC 8301，RSA 的最小密钥长度为 1024 位。更短的密钥对密钥泄露的抵抗力不足。
推荐的 RSA 密钥长度至少为 2048 位，可提供更强的抗密钥泄露能力。如果签名系统支持，请选择该长度。规范禁止将 rsa-sha1 用于签名和验证。
RFC 8463 增加了 ed25519-sha256。一封邮件可以同时携带 RSA 和 Ed25519 签名，以兼容支持不同算法的接收方。
Yahoo 的指南也要求最小 1024 位的 DKIM 密钥。
邮件列表编辑消息后会怎样？
当编辑更改了签名覆盖的内容时，可能使 DKIM 失效。
转发本身不会更改签名内容。完整的签名可以在转发中保留。附加的页脚可能改变正文哈希。重写已签名的 Subject 可能使请求头签名失效。
可选的 l= 标签将正文覆盖限制为指定的字节数。使用 l=100 时，前 100 个规范化字节之后的内容不受保护。因此，附加误导性文本可以在签名仍然有效的情况下进行。
当需要保护整个正文时，避免使用该限制。ARC 允许中间方在编辑之前保存已签名的身份验证证据。
如何使用 Bird 配置 DKIM？
发布注册发送域时返回的 DKIM 记录。
API 的 dkim.mode 字段默认为 txt。在该模式下，将公钥发布到 TXT 记录中。架构还列出了 delegated。注册发送域时该值返回 HTTP 422，因此请使用 txt。
Bird 为使用发送域的每个组织创建单独的密钥和选择器。使用同一域名的组织无需共享签名密钥。
身份验证指南解释了返回的记录。
通过签名验证是否证明消息是安全的？
通过签名验证表明对签名内容承担责任，但不表明消息是否被期望或值得信任。
签名域也不要求与可见的 From 域匹配。DMARC 通过对齐提供该匹配规则。发送者信誉，即接收方对发送者流量的评估，是单独的考量因素。
简而言之
仅选定的内容受保护。
DKIM 覆盖列出的请求头字段和正文哈希。未受保护的内容可以在不使签名失效的情况下发生变化。
选择器定位验证密钥。
选择器和签名域标识包含公钥的 DNS 记录。
规范化影响验证。
simple 和 relaxed 算法对格式变化的处理方式不同。
转发不保证通过验证。
完整的签名可以在转发中保留，但签名内容的更改可能使其失效。