智能、聚焦、邮件。
超高效兼跨平台：专为静忧收件设计，专心聚焦重要事项。
定义
💡 ARC（Authenticated Received Chain，已验证接收链）：一种电子邮件身份验证协议，基本上用于跟踪你的邮件在不同服务器之间辗转时发生了什么。 当电子邮件被转发或被邮件列表修改时，ARC 会保留原始身份验证结果，这样合法邮件就不会被标记为垃圾邮件。
为什么 ARC 很重要
它解决的问题是这样的：你发送了一封通过所有身份验证检查的电子邮件（SPF、DKIM、DMARC）。 非常好。 但随后有人通过其公司的邮件服务器转发了它，或者它经过了一个会添加页脚的邮件列表。 这些修改可能会破坏原始的身份验证签名。
接下来会发生什么？ 接收服务器会看到一封声称来自你的邮件，但它已经无法通过身份验证了。 进垃圾邮件文件夹。 或者更糟，直接被拒收。
ARC 通过创建一条信任链来解决这个问题。 每台处理该邮件的服务器都会添加自己的 ARC 签名，用来记录：是的，这封邮件到达这里时是合法的，尽管我们在继续转发前对它做了些微修改。 你可以把它想象成一场接力赛，每位跑者都签字确认自己是合法接过接力棒的。
根据 Google 的电子邮件发件人指南，如果没有 ARC，转发邮件更有可能无法通过身份验证检查。 这意味着会有大量合法邮件被拦截。
ARC 如何工作？
当邮件在服务器之间传递时，该协议会向你的邮件添加三个关键标头：
ARC-Authentication-Results 记录执行了哪些身份验证检查，以及它们是否通过。 这就像一张成绩单，记录你的电子邮件在首次到达这台服务器时具有有效的 DKIM 和 SPF。
ARC-Message-Signature 会对邮件在传递过程该阶段的内容创建加密签名。 这可证明邮件在各个中转节点之间没有遭到恶意篡改（为转发而做的小修改是正常且预期中的）。
ARC-Seal 用另一重签名把所有内容串联起来，并验证整条链。 每台服务器都会添加自己的 seal，从而形成一个相互连接的序列。 如果链条中的任何一环断裂或可疑，接收服务器就能发现。
巧妙的是，这条链是带编号的。 ARC-Seal：i=1，然后 i=2，再然后 i=3。 接收服务器可以验证是否有任何环节缺失，并确认每台合法的中间服务器都已正确验证前一步。
而且与内容一变就失效的旧协议不同，ARC 预期消息会被修改。 这正是它的意义所在。 它只是记录这些更改发生在受信任的服务器上，而不是由某个拦截你邮件的攻击者造成的。
设置 ARC
ARC 需要在中间服务器（即转发或修改邮件的服务器）和接收服务器（即验证 ARC 链的服务器）上都进行配置。 大多数用户无需执行任何操作，除非他们运行自己的邮件基础设施。
在 Gmail 中：
Gmail 在接收转发邮件时会验证 ARC 签名。 如果你将邮件转发到 Gmail，中间服务器应添加 ARC 标头。 如果你使用 Google Workspace 并通过自己的服务器将邮件转发到其他目标，请将你的邮件服务器配置为添加 ARC 标头。 Google 在其电子邮件发件人指南中为管理转发服务的管理员提供了详细说明。
在 Outlook 中：
Exchange Online 支持 ARC 验证，但管理员需要配置受信任的 ARC sealer。 前往 Microsoft Defender 门户，然后导航到 电子邮件与协作 & 策略与规则 & 威胁策略 & 电子邮件身份验证设置 & ARC。 添加所有处理你邮件的中间服务的域名（这些域名必须与 ARC-Seal 标头中的“d”标签匹配）。 好消息是：Microsoft 365 组织会自动信任来自其他 Microsoft 365 组织的 ARC 签名，所以这部分已经处理好了。
在 Spark 中：
Spark 依赖你的电子邮件服务提供商（Gmail、Outlook、自定义 IMAP 服务器或 Microsoft 365 这类 EWS 账户）所配置的电子邮件身份验证设置。 作为一款电子邮件客户端，Spark 本身不直接处理 ARC 签名或验证。 这些操作发生在服务器层面，甚至早于邮件到达你的收件箱。
对于自定义邮件服务器：
如果你运行的是自己的基础设施，就需要为你的 SMTP 服务器添加 ARC 支持。 OpenARC 是 Postfix 和 Sendmail 最常见的实现。 你需要安装它，将其配置为对发出的邮件进行签名并验证传入的链，同时添加必要的配置（与 DKIM 设置类似，但 ARC 不需要 DNS 记录）。
难点在哪？ 只有当中间服务器和最终接收服务器都支持 ARC 时，它才有帮助。 如果目标方不验证 ARC，这条链就没有意义。 但它的采用速度正在快速增长。 Gmail、Yahoo、Microsoft 以及大多数主要服务提供商现在都会验证 ARC 链。
ARC 最佳实践
先设置好核心协议。 ARC 是对 SPF、DKIM 和 DMARC 的补充，并不能替代它们。 在考虑 ARC 之前，先配置好这些身份验证方法。 如果没有正确的基础身份验证，ARC 就没有任何有用的信息可保留。
监控你的身份验证结果。 大多数电子邮件服务提供商都会提供报告，显示你的邮件通过身份验证检查的频率。 如果即使启用了 ARC，你的转发邮件仍然出现很高的失败率，那就说明某些地方配置有误。 检查你的标头。
确保 DKIM 密钥安全。 ARC 建立在 DKIM 签名之上，因此如果你的 DKIM 密钥遭到泄露，ARC 链同样也不可信。 定期轮换密钥（标准做法是每 6 到 12 个月一次）。
测试转发场景。 通过邮件列表、转发服务和不同的电子邮件客户端发送测试邮件，以验证 ARC 是否正常工作。 像 MXToolbox 这样的工具可以帮助你验证配置并检查标头。
记录你信任的 sealers。 如果你正在配置 ARC 验证，请维护一份你信任哪些中间服务的列表。 每季度审查一次这份列表。 服务可能会更换所有者、遭到入侵或停止运营。 不要信任你已经不再使用的服务所提供的 ARC 签名。
要接受并非所有人都已支持它。 一些较小的电子邮件服务提供商尚未实现 ARC 验证。 你的转发邮件在这些服务中仍可能被标记。 但主要的大型服务商都支持它，这已经覆盖了你的绝大多数收件人。
相关术语