DMARCbis 如何处理邮件转发（forwarding）场景下的认证？和 ARC（RFC 8617）的配合有无增强？

邮件转发（forwarding）一直是 DMARC 体系中的最大痛点之一：当用户设置了自动转发到另一个邮箱，转发的邮件可能会因为 SPF 和 DKIM 验证失败而被接收方拒收或放入垃圾箱。DMARCbis 对这一问题给出了更清晰的指导意见，并与 ARC（Authenticated Received Chain）标准形成了更强的协同。

一、邮件转发为什么会导致认证失败？

转发场景下常见的认证失败路径：

• SPF 失效：转发服务器用自己的 IP 重新投递，原发信方的 SPF 记录中不包含转发服务器的 IP，导致 SPF 验证失败
• DKIM 失效：转发过程中邮件头部或正文可能被改写、签名缓存器退出，导致 DKIM 签名无效
• DMARC 失效：SPF 和 DKIM 均不对齐时，DMARC 评估结果为 fail

结果是：用户明明设置了自动转发，但收件人收不到邮件，或邮件被扔进垃圾箱。接收方无法区分"这是合法转发"还是"假冒攻击"。

二、DMARCbis 对转发场景的改进

1. 明确 ARC 优先级

RFC 9989 第 8.3 节规定了 ARC 的评估优先级规则：

"如果邮件包含 ARC-Seal 且标准验证通过（cv=pass），接收方应当使用 ARC 中记录的原始认证结果作为 DMARC 评估依据，而非邮件当前状态的 SPF/DKIM 结果。"

这一规定结束了过去业界对 ARC 优先级的争议。简言之：ARC 验证通过 → ARC 结果覆盖当前 SPF/DKIM。

2. 转发邮件的 DMARC 报告标记

DMARCbis 的聚合报告（RFC 9991）和鉴证报告（RFC 9989）中新增了专门的转发标记：

• 聚合报告中 <arc><chain_validation>pass</chain_validation> 标记转发链验证情况
• 鉴证报告中新增失败原因值 dmarc-forwarding（参见 FAQ-03）
• 统计报告中新增 <forwarded_count> 可选字段，单独统计转发邮件的数量

3. 转发服务的 ARC 部署建议

DMARCbis 对邮件转发服务商提出以下 ARC 部署建议：

1. 转发时必须使用 ARC 签名，包含原始的 Authentication-Results 头
2. ARC 签名必须在转发操作之前、DKIM 签名失效之前完成
3. 转发服务器应在 ARC-Authentication-Results 中记录所有原始验证结果
4. 建议转发服务器部署自己的 DKIM 签名（即"重签名"），覆盖因转发导致的签名失效

三、转发问题完整的解决方案矩阵

DMARCbis 认可以下三种方案来解决转发认证问题：

方案	适用场景	DMARCbis 推荐度
ARC 部署	通用转发场景（推荐）	强烈推荐
SRS（Sender Rewriting Scheme）	仅解决 SPF 问题	有限推荐
重签名（Re-signing）	同域内转发或受信任的 ESP 场景	推荐

DMARCbis 特别强调了 ARC 的优越性：它保留了原始认证链的完整性，允许最终接收方了解邮件的完整转发路径。

四、ARC cv= 与 DMARC 策略的交互规则

接收方决策流程：
1. 收到邮件，检查是否有 ARC-Seal
2. 如果有，尝试验证 ARC 链
3. 如果 ARC 验证通过（cv=pass）：
   - 使用 ARC-Authentication-Results 中的原始认证结果做 DMARC 评估
   - 忽略当前 SPF/DKIM 结果
4. 如果 ARC 验证失败（cv=fail）：
   - 回退到标准 DMARC 评估流程（使用当前 SPF/DKIM）
5. 如果没有 ARC：
   - 标准 DMARC 评估

五、实际部署建议

1. 如果你使用邮件转发功能且遇到问题——建议你的转发服务器启用 ARC
2. 如果你是邮件服务商——尽快实现 ARC 签名功能
3. 使用现有的 ARC 验证工具（如 ARC Validator 扩展）测试转发链的完整性
4. 注意：ARC 不是强制性的，但在 DMARCbis 生态中，没有 ARC 的转发服务器处理将会越来越困难