摘要

  • DKIM pass 证明 d= 域以 s= 指定密钥，对被选择的规范化邮件材料作出有效签名；它不会自动授权可见的 From 域。
  • RFC 9989 的 DMARC 对齐另行判断作者域。即使对齐通过，也不证明内容真实、安全、新鲜或获得业务操作许可。

通过的是谁

验证器从攻击者域的 DNS 取得公钥，重新计算正文哈希并验签成功。错误发生在策略层：日志只保留 pass，丢掉了 pass 属于哪个域。

d= 是签名域，s= 选择密钥，h= 列出被签首部，bh= 保存规范化正文摘要，b= 对所选首部与 DKIM 字段签名。From 必须列入 h=，这只能防止签名后篡改该行；攻击者仍可忠实地签署一行冒用他域的 From。

RFC 6376 要求正文摘要不匹配时整条签名失败，哪怕首部签名计算原本成功。因此应分别记录规范化输入、bh= 比较、DNS 密钥和 b= 结果。

规范化不是语义审查

simple 与 relaxed 模式容忍的空白变化不同。读者眼中无害的变化可能破坏签名，而字节完全不变的恶意指令可以顺利通过。

l= 还可把正文覆盖限制为规范化后的前缀。其后的文字可以追加而不改变 bh=；l=0 意味着正文完全未签。如果界面把完整正文放在一个“已签名”徽章下，就掩盖了未签后缀。

作者域要由 DMARC 对齐

2026 年 5 月发布的 RFC 9989 已取代 RFC 7489。它把 RFC5322.From 作者域与通过验证的 DKIM d= 或 SPF 标识符比较：严格模式要求域完全相同，宽松模式要求同一组织域。

开篇邮件因此可以 DKIM pass，同时与 bank.example 对齐失败。两项结果都必须保留。即使 DMARC pass，RFC 9989 也只确认作者域的使用得到授权，不保证邮件安全或值得投递。

SMTP envelope、SPF、d=、i=、From 与 SMTP 登录账户是不同身份。Authentication-Results 也只有来自接收方管理域内授权验证器时才可信。ARC 可携带邮件列表修改前的判断，但最终接收者仍要决定是否信任 ARC 链。

签名可以被原样重放

t= 记录创建时间，x= 可写到期时间，但 RFC 6376 明确说 x= 不是防重放机制。同一封有效邮件可以再次触发流程。交易标识、幂等、账户状态与人工复核必须另行控制。

负面测试应包括：攻击者域签名并冒用他域 From；对齐域发送恶意内容；在 l= 后追加指令；分别修改已签与未签首部；多签名混合通过；伪造外部 Authentication-Results；选择器轮换、列表改写与完整邮件重放。