什么是 ARC（已认证接收链）？

定义

Authenticated Received Chain 是 RFC 8617 定义的邮件认证标准，发布于 2019 年 7 月。它旨在解决 SPF 和 DKIM 的一个长期弱点：当邮件经由中间服务器中转、而非从发件人直接投递给收件人时，这两项检查会出问题。

当您直接给收件人发信时，SPF 和 DKIM 检查通常都能通过，DMARC 也会通过。问题出在邮件途经中间第三方的时候。邮件列表、自动转发的账户或安全网关往往会修改邮件：可能改写主题行、添加页脚，或从不同的 IP 地址中转。这些改动会破坏原始 DKIM 签名并使 SPF 结果失效，即使邮件完全正当，也可能导致 DMARC 失败。

ARC 由一个行业组织设计，成员包括来自 Google 和其他大型邮件运营商的工程师，目的就是让收件方能够识别这种情况。收件方不必只根据最后一跳看到的已损坏认证结果来判断，而是可以读取 ARC 链，了解邮件在中间环节处理之前已正确通过认证。

工作原理

ARC 的做法是：每个参与的中间环节在转发邮件前，向邮件添加一条经过加密签名的记录，称为 ARC 集。每个 ARC 集由三个邮件头字段组成，并带有实例编号，以便按顺序读取整条链。

第一个字段是 ARC-Authentication-Results。它记录中间环节收到邮件那一刻观察到的 SPF、DKIM 和 DMARC 结果快照，相当于该跳认证结论的冻结副本。

第二个字段是 ARC-Message-Signature。它的作用与 DKIM 签名非常相似，是对链中该节点处邮件头和正文的加密签名，将记录的认证结果与当时的实际内容绑定在一起。

第三个字段是 ARC-Seal。这是一个覆盖之前所有 ARC 邮件头整条链的签名，而不仅仅是当前这一组。该封印带有链验证标签，写作 cv，用于报告到目前为止链的状态。值为 none 表示这是第一跳，pass 表示之前每个 ARC 集都验证通过，fail 表示链中有内容无法验证。

当邮件依次经过多个支持 ARC 的服务器时，实例编号会逐跳递增。负责验证的收件服务器按顺序读取 ARC 集，确认没有缺失条目，检查每个封印是否报告之前的条目有效，并验证最新的邮件签名。如果整条链完好，收件方就可以信任第一跳记录的认证结果。

为什么它对邮件送达率很重要

ARC 之所以重要，是因为转发和邮件列表随处可见，没有 ARC，它们会悄无声息地导致正常邮件被拒收。员工把工作邮件转发到个人账户、讨论列表在每封邮件后添加页脚、第三方安全设备扫描入站邮件，这些都会破坏 DKIM 或 SPF，而这与邮件是否真实毫无关系。

当域名所有者发布 p=reject 这样严格的 DMARC 策略时，这些被破坏的认证结果通常会导致转发的副本被丢弃。收件人收不到本该收到的邮件，从外部看就像一次原因不明的投递失败。ARC 为最终收件方提供了足够的上下文来做出更好的判断。如果 ARC 链显示邮件在被可信中间环节修改之前已正确通过认证，收件方就可以选择投递，而不是对正当的转发执行严格策略。

需要准确理解 ARC 能做什么、不能做什么。ARC 不会覆盖 DMARC，也不保证投递成功。它只是一个信号。收件方仍会自行决定对某条 ARC 链的信任程度，而这种信任取决于签名的中间环节的信誉。ARC 只是消除了一个常见又令人头疼的误拒来源，让正常邮件更有机会进入收件箱。

VeriMails 如何应对

VeriMails 是邮箱验证服务，专注于送达率中一个不同且互补的环节。ARC 保护的是已经在中间环节传输中的邮件，而 VeriMails 在您点击发送之前就开始工作，确认列表中的地址真实存在且可以收信。

对于每个待检查的地址，VeriMails 都会执行语法验证、MX 记录查询、DNS 检查、与收件邮件服务器的实时 SMTP 握手、Catch-all（全收）检测、一次性邮箱检测和角色邮箱检测。这套组合能在地址进入营销活动之前告诉您它是否可送达，并给出清晰的送达分类，便于做出营销决策。

两种方法相辅相成。ARC 以及由 SPF、DKIM 和 DMARC 构成的完整认证体系，通过证明邮件真实来保护发件人信誉。VeriMails 则从另一个方向保护同样的信誉：把无效和有风险的地址挡在列表之外，从而减少退信和垃圾邮件投诉。您可以通过 VeriMails REST API 逐个验证地址，也可以上传 CSV 文件批量验证。每个新账户都免费赠送 100 积分，积分永不过期，无需信用卡。

常见问题