ARC 的三个头字段各起什么作用？cv= 的取值怎么判断转发链是否可信？

转发与列表会打断 SPF 对齐与 DKIM 签名，使接收方无法判断「这封信在进入中介之前是否通过了认证」。

ARC 的思路是：让链路上每一个处理环节把自己看到的认证结论签名固定下来，形成一条可逐跳验证的链条。最终接收方即便看到 DMARC 失败，也能通过这条链回溯到最初的认证状态，从而做出更合理的处置决策。

关键定位：ARC 提供的是「可验证的历史证据」，不是「认证豁免」。是否采信这条链，最终仍由接收方的本地策略决定。

RFC 8617 定义了三个头字段，它们成组出现：

• 第 4.1.1 节 ARC-Authentication-Results (AAR)：记录本跳看到的认证结果，内容形态与常规认证结果头相当，是链条承载的核心信息。
• 第 4.1.2 节 ARC-Message-Signature (AMS)：对本跳看到的邮件内容做签名，作用类似 DKIM 签名，用于证明消息在本跳时的状态。
• 第 4.1.3 节 ARC-Seal (AS)：对此前所有 ARC 头字段做签名，把链条本身封存，防止中间环节被删改。

三者分工要点：AMS 保护「邮件内容」，AS 保护「链条完整性」，AAR 承载「认证结论」。理解这个分工，才能读懂验证失败时问题出在哪一层。

RFC 8617 第 4.2.1 节（Instance Tags）规定了实例标签规则：

• 实例值从 1 开始递增，取值范围为 1 至 50。
• 同一个 ARC Set 内的三个头字段共享相同的实例值——这正是把它们归为一组的依据。

运维含义：看到 i=3，说明这封信至少经过了三个实现 ARC 的处理环节。序号必须连续；出现缺号意味着链条被破坏，验证将不通过。上限 50 也意味着极长的转发链无法继续追加 ARC 头。

RFC 8617 第 4.4 节（Chain Validation Status）定义了链验证状态，通过 ARC-Seal 的 cv 标签传递，取值为三者之一：

• cv=none：本跳是链条的第一环，此前不存在 ARC 头。对应 i=1 的情形。
• cv=pass：本跳验证了此前的链条并且通过，链条在本跳之前是完整可信的。
• cv=fail：本跳验证此前链条失败。链条已被破坏，后续环节不应再将其作为可信依据。

最重要的判定规则：一旦链条中出现 cv=fail，整条链即失去可信性，后面再多的 pass 也无法挽回。因为可信性是逐跳累积的，断了一环，之前的结论就无法被安全地传递下来。

RFC 8617 第 5.2 节（Validator Actions）描述了验证方处理认证接收链的完整步骤，其中会依次检查链验证状态与实例连续性。实践中的核对顺序：

1. 确认链条是否存在。没有 ARC 头则无链可验，按常规 DMARC 处理。
2. 检查实例序号是否从 1 开始且连续。缺号或重复即判定链条被破坏。
3. 检查最早一环的 cv 是否为 none，符合「第一环没有前序链条」的语义。
4. 逐环验证 AS 与 AMS 签名，确认链条未被篡改、且各跳所见内容可被证明。
5. 检查是否存在任何一环为 cv=fail，存在即整链不可信。
6. 全部通过后，读取最早一环的 AAR，据此了解邮件进入中介之前的原始认证状态。

• ARC 需要中介方实现才有意义。作为域名所有者，你无法单方面让转发链具备 ARC；这是链路上各方共同参与的机制。
• ARC 不改变 DMARC 的判定结果。它提供的是补充证据，接收方可据此在 DMARC 失败时选择不执行拒收，但这属于本地策略范畴，不可假定所有接收方都会采信。
• 不能把 ARC 当作放宽自身认证的理由。发送侧仍应确保 DKIM 对齐覆盖完整——ARC 是链路修复手段，不是源头认证的替代品。
• 与 RFC 7960 配套理解。该文档系统梳理了间接邮件流的互操作问题，ARC 正是针对其中转发链场景的应对机制之一。