一个 ARC 当屏幕截图显示cv=pass或dmarc=pass.这些字符串是要解析的证据，而不是接受消息的指令。从原始消息和接收系统的可信评估开始，然后将中介的声明与在最终边界执行的检查区分开来。单独复制的标头摘录无法建立有效的链。
按实例对字段进行分组
参考： RFC 8617 §4.2.1, RFC 8617 §5.2.
找到ARC-Authentication-Results 、 ARC-Message-Signature和 ARC-Seal 并按i=.有效集需要预期的组件和有序的实例结构。第一组使用cv=none,而后面的有效链断言使用适当的延续状态。丢失的组件、重复的设置字段或不一致的编号需要协议验证，而不是手动修复收到的证据。 RFC 8617第 4 节和第 5.2 节提供了规则。
RFC 8617 §5.2 将链限制为 50 组，并要求在从 1 到 N 的每个连续实例中恰好有一个 AAR、AMS 和密封件。验证会检查最新的 AMS 和每个密封件；检查旧的 AMS 值是可选的，并且本身并不决定链的有效性。失败的链被视为无ARC链进行ARC处理，而不是作为拒绝消息的自动指令。
保留工具的原始排序和展开值，同时保留原始字节用于签名验证。不要删除令人困惑的内容 标题来自 使解析器成功的证据副本。如果工具报告格式错误的结构，请保留该结果和使用的版本，而不是默默地将看起来最接近的字段视为有效。
标记每个声明的发言人
参考： RFC 8617 §4.1, RFC 8601 §5.
对于 AAR，确定中介的身份验证服务和报告的结果。对于 AMS 和印章，将 d= 和 s= 标识为签名域并 选择器 输入。早期集合中的dmarc=pass描述了中介的评估上下文，不一定是最终接收者的当前结果。后面的cv=pass本身就是一个签名断言，必须评估其有效性。
普通的 Authentication-Results 标头还需要信任边界。发件人可以在发送前插入看似合理的文本。使用最终接收者记录的处理和可信标识符，而不是对单词 pass 进行子字符串搜索。 RFC 8601 描述了接受来自不可信来源的结果的问题。
完成提供的插图
参考： RFC 8617 §5.2, RFC 8617 §7.2.1.
私人审查包保留了与签名测试消息分开的非验证ARC标头说明。该插图将实例 1 中的一个 AAR、一个 AMS 和一个印章分组。签名字段明确表示 NOT-A-SIGNATURE，并且 正文哈希 是说明性的。其有用的结果是对现场角色的认可，而不是成功的验证。
然后检查可执行的信任案例。具有不受信任密封器输入的有效链输入仍然不符合示例覆盖的条件。具有无效链输入的可信密封器输入也是如此。只有有效链、可信密封器和有利的事先评估的组合才符合资格，即使这种情况也可能无法通过玩具内容过滤器。这些提供了布尔模型决策，而不是验证ARC加密。
将解析转变为调查
参考： RFC 8617 §5.2, RFC 8601 §5.
对于真实消息，请使用具有相关DNS证据的合格验证者并保留所有报告的失败。询问接收提供者它信任哪个中介以及它如何使用该断言。如果这些详细信息不可用，请报告可见性差距，而不是仅通过交付来制定信任决策。
在调查中保留一份注明日期的协议状态说明。检查的IETF记录仍然将实验性RFC 8617与主动提议的历史性重新分类区分开来。 当前记录 发表前应重新检查。保留的证据包括本地收到的转发消息和下面单独验证的本地ARC链。不提供外部接收器或部署验收。
保留的实验室证据
参考： RFC 8617 §5.2.
私人审查包保留 arc-sealed-footer.eml 作为真正签名的一套ARC装置，与占位符插图分开。 dkimpy 根据保留的公钥验证其 AMS 和密封； arc-tampered.eml 在密封后添加内容并产生消息签名失败，而密封本身仍然有效。 comments.json 保留了区别。 i=1集合包含本地转发器的实际早期认证结果。单独的本地信任决策功能仅在其肯定的情况下将该实验室域视为可信。 ARC签名和篡改是SMTP抓包后的离线操作；这两个ARC工件本身并不是通过外部提供商发送的，也不是声称作为附加SMTP传送的。
对保留的赛跑者和2026年11月7日捕获的赛跑者进行了检查；本次审查没有重新运行网络实验。最初的实验仅使用环回并且不发送互联网邮件。它的接收者根据自己的检查创建Authentication-Results ，使这些字段具有已知的实验室来源。身份验证结果和处置保持独立：所有六个SMTP样本均在显式捕获策略下收到 250，包括失败样本。信任边界是这个受控实验室，而不是生产邮箱提供商。 DNS适配器提供保留的固定答案而不是查询公共DNS ，并且 DMARC 评估器仅使用严格的域相等。完整的组织域发现、生产策略解析和实时部署结果尚未经过测试。
有效的历史重分类草案建议不要在不同的发送者和接收者之间部署或依赖ARC 。这是在规划新依赖项、未完成停用或证明当前提供程序已禁用ARC时需要考虑的重要建议。在标准流程继续进行的同时，保留过时的特定于提供商的依赖性评估。