邮件列表为什么会让 DMARC 失败？发送方、列表方、接收方各能做什么？

RFC 7960《Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows》整篇就是讨论 DMARC 与间接邮件流的互操作问题。邮件列表是其中最典型的场景，规范在第 3.2.3 节（Mailing Lists）专门分析。

先建立正确预期：这不是某一方配错了，而是机制之间的结构性冲突。解决方案都是权衡取舍，不存在无代价的完美方案。

RFC 7960 第 2.2 节（Message Forwarding）与第 2.3 节（Message Modification）分别指出了两个独立的破坏因素：

• 转发打断 SPF 对齐（第 2.2 节）。转发操作引入了 SPF 标识符对齐问题，使 DMARC 无法获得对齐的 SPF 认证标识符。
• 修改打断 DKIM（第 2.3 节）。规范明确指出，对邮件内容的修改会使大多数 DKIM 签名失效，而邮件列表等系统正是常做此类修改的一方。

第 3.2.3 节进一步列举了列表的典型修改动作——如在主题行添加标签、在正文追加页脚等，这些都会导致 DKIM 签名失效。

两条腿同时断，DMARC 必然失败。这就是为什么列表场景比普通转发更棘手：普通转发至少 DKIM 还能存活。

除列表本身外，RFC 7960 还列出了同样会破坏签名的相邻环节，排障时应一并纳入视野：

• 第 3.1.2.1 节（Message Encoding）：MTA 转换消息编码（如在 8 位与 7 位表示之间转换）超出了 DKIM 规范化的容忍范围，导致签名失效。
• 第 3.1.2.2 节（Header Standardization）：MTA 为符合规范而重写头字段，导致签名失效。
• 第 3.1.2.3 节（Content Validation）：MTA 出于安全目的修改内容，破坏签名。
• 第 3.2.5 节（Boundary Filters）：边界过滤器（如恶意软件扫描）修改内容使签名失效。

排障提示：若邮件未经列表也出现 DKIM 失效，应重点排查上述这些「好意的修改者」。

RFC 7960 第 4.1.1.2 节（Message Modification）给出了发送侧的缓解方向，落到操作上：

1. 限制签名覆盖的头字段。只签必要字段，尤其避免把易被列表改写的字段（如主题）之外的大量头字段纳入，降低失效概率。
2. 使用 relaxed 规范化。对应 RFC 6376 第 3.4.2 与 3.4.4 节，容忍空白与折行层面的调整。
3. 评估策略强度与业务的匹配度。若本域用户大量参与外部邮件列表，收紧到 reject 前必须评估这部分流量的影响面。
4. 用聚合报告量化影响。先看清有多少流量来自列表类中介，再决定策略节奏。

RFC 7960 第 4.1.3.2 节（Avoiding Message Modification）与第 4.1.3.3 节（Mailing Lists）给出了转发方与列表方的两类思路：

• 路线一：尽量不修改邮件（第 4.1.3.2 节）。取消主题标签、取消正文页脚、不重排 MIME 结构，让原始 DKIM 签名存活下来。这是最干净的方案，代价是牺牲列表的一部分惯用体验。
• 路线二：承认修改，改写发件人身份（第 4.1.3.3 节）。规范列举了当前在用的缓解措施，包括修改 From 头、用 MIME 包装原邮件等。改写 From 后，DMARC 评估的对象变成列表自己的域，由列表方保证其认证通过。

路线二的代价必须明说：收件人看到的发件人变成了列表，直接回复的行为路径改变，且原始发件人的身份信息被弱化。这是以可用性换互操作性的取舍，不存在两全。

• 不要机械执行策略。对已知的列表类中介，可结合本地策略与信誉判断，避免对正常列表流量造成大面积拒收。
• 参考 ARC 链。当中介实现了 ARC 时，接收方可依据经验证的链上原始认证结论来还原「进入中介之前这封信是否通过认证」，从而在 DMARC 失败时做出更合理的判断。
• 把 DMARC 结论作为综合评分的输入之一，与来源信誉、内容特征共同决策。