邮件可能在邮件列表修改之前通过认证。下一个接收方需要该早期结果的证据，以区分合法处理与冒充。
为什么合法转发会破坏认证？
转发可能更改认证检查所依赖的发送服务器或已签名内容。
SPF 检查服务器是否获得了用于退信通知的信封发件人域的授权。转发方可能从未授权的 IP 发起连接。
DKIM 验证与签名域关联的签名。签名可以在简单转发中保持完整。邮件列表如果更改了已签名的主题或正文，则可能使签名失效。
DMARC 要求通过的 SPF 或 DKIM 域与可见的 From 域匹配。该匹配称为对齐。如果两种方法都无法提供对齐的通过结果，即使消息是合法的，DMARC 也会失败。
ARC 为消息添加了什么？
每个参与处理的中间方添加三个请求头，合称为一组 ARC 集。
| 请求头 | 提供的证据 |
|---|---|
ARC-Authentication-Results | 在该中间方更改之前观察到的认证结果 |
ARC-Message-Signature | 对该中间方转发出去的消息所做的签名 |
ARC-Seal | 保护该 ARC 集及先前链的签名 |
实例编号 i= 确定各组的顺序。第一个中间方使用 i=1，下一个使用 i=2，使顺序明确。
封印的 cv= 值记录链验证结果。none 标记第一组。pass 表示已有链验证成功。fail 表示验证失败。
RFC 8617 描述了接收方如何验证链的完整性。验证并不能证明每个中间方报告的评估结果是可信的。
有效的链能保证投递吗？
有效的 ARC 链不保证投递。它为接收方自身的处理决策提供证据。
接收方决定是否信任提供证据的中间方。未知的中间方不会仅因为生成了有效签名就变得可信。
ARC 规范处于实验阶段，意味着它记录的是一个供评估的协议，而非互联网标准化进程规范。投递决策仍由接收方控制。
谁需要实现 ARC？
转发方和邮件列表使用 ARC 为下游接收方保留认证证据。
| 您的角色 | 相关任务 |
|---|---|
| 原始发件方 | 使用对齐的域对邮件进行认证 |
| 转发方或邮件列表 | 评估传入的链，并在处理消息时添加一组 ARC 集 |
| 接收方 | 验证可用的链并决定信任哪些中间方 |
Yahoo 的发件方指南要求转发方实现 ARC。这样做可以帮助收件人评估受转发影响的合法邮件。接收方仍然决定是否接受。
如果您的直发邮件未通过 DMARC，请修复其认证或对齐。添加 ARC 封印无法修复原始域不匹配问题。
原始发件方能对转发邮件做什么？
原始发件方可以提供对齐的 DKIM，在已签名内容保持完整的情况下使其在转发中存活。
对需要保护的请求头进行签名。避免设置正文长度限制导致追加内容未被签名。DKIM signing解释了这些选择。
如果后续中间方编辑了已签名内容，保留早期结果的证据需要该中间方的参与。ARC 为其提供了记录该证据的方式。接收方仍然决定给予多大权重。
简而言之
转发和编辑可能影响认证。
更换发送服务器可能导致 SPF 失败。更改已签名内容可能导致 DKIM 失败。
每个参与处理的中间方添加一组 ARC 集。
三个请求头分别记录认证结果、对发出的消息进行签名并封装链。
有效的链不保证投递。
接收方决定是否信任中间方以及如何使用其提供的证据。
发件方与中间方承担不同任务。
原始发件方对其邮件进行认证。中间方可以保留在其更改之前观察到的认证结果证据。