定义转发器的职责
经过身份验证的重邮服务接收消息并向前发送另一个SMTP事务。该描述涵盖了不同的服务：地址转发器、讨论列表、安全网关或重新分发邮件的应用程序。 “经过身份验证”是不完整的，除非它指定了身份、机制和接收跃点。服务可以验证其自己的出站连接，而无需保留原始作者的身份验证。因此，责任边界应该遵循整个路线的消息，而不是遵循产品标签。
从邮件流的书面服务合同开始。确定谁接受原始消息、更改信封、修改签名内容、处理传送失败并向最终接收者提供证据。下面建议的责任图是一个规划辅助工具，而不是对已部署服务的观察。每个操作员应该能够解释自己的更改，而无需声称控制其他操作员的过滤决策。
将三个身份问题分开
连接IP和SMTP 信封发件人 重要的是 SPF。签名域和受保护的消息材料很重要 DKIM. DMARC 询问合格的经过身份验证的标识符是否与消息的“发件人”字段中的“作者域”一致。重邮者对其自己的信封域的成功SPF结果不会自动成为不相关的原始作者的对齐结果。即使用户界面显示一个令人放心的“经过身份验证”的标签，这些也是单独的问题。 RFC 7208 ，第 2.4 节 和 RFC 9989 ，第 4.4 节 定义相关边界。
信封重写可以使转发器负责新的返回路径，并允许SPF描述其出站基础设施。它本身并不能修复原作者 结盟。同样，一个新鲜的 DKIM签名 来自转发器的信息证明了有关该签名域的一些信息，而不一定是原始作者。记录新旧身份，以便后来的分析人员可以看到哪些关系被保留、替换或丢失。
自己的修改可能会破坏签名
附加页脚、更改签名主题字段或重新编码受保护内容的服务需要了解相关的DKIM签名和 规范化。有些转换在选定的规范化后仍然存在；其他人则不然。不要假设每个标头更改都会破坏DKIM ，或者“宽松”的规范化允许任意编辑。保留原始副本并在诊断故障时比较实际签名的标头和正文。 RFC 6376 ，第 3.4 和 5.4 节 提供机制，而不是对特定转发器的承诺。
Google 的转发指南建议保护 DKIM 覆盖的内容，并指出Gmail会自行评估转发的邮件。这是 Gmail 特定的操作建议，而不是普遍接受协议。重邮者仍然对其所做的更改负责，包括某些列表设计使用的有意的发件人重写。此类重写会更改向收件人提供的身份，并且需要有关回复和归属的明确产品决策。 Google 转发指南.
将ARC视为具有信任边界的证据
ARC 可以承载中介机构的认证评估和可验证的处理链。它的验证并不证明良性内容或确定每个密封域都是值得信赖的。最终接收者必须决定如何（如果有的话）使用该信息。分别保存链、密封域、接收者的评价和本地配置。 ARC通行证不是对齐的DKIM通行证的替代条目。 RFC 8617 ，第 7 节和第 9 节.
标准状态也需要一个日期。 2026 年 11 月 8 日， RFC 8617仍处于实验阶段。活跃的draft-ietf-dmarc-arc-to-historic-01建议结束实验并将RFC移至Historic；这是一项正在进行的工作，而不是已颁布的重新分类。服务评估应披露该提案，但不提供通用ARC部署或已完成退役的事实。 当前草案状态.
跟随一条虚构的消息穿过边界
考虑一条来自notices@sender.example的虚构消息，通过校友转发器路由到最终邮箱。假设原始流具有对齐的DKIM签名。转发器将信封发件人更改为自己的域，但保留受保护的消息不变。最终接收者的预期问题是原始签名是否仍然有效和对齐。新信封的SPF结果回答了不同的身份问题。这个例子是一个推理练习；未收集任何消息、 DNS响应或接收器结果。
现在假设同一服务添加了正文免责声明。分析人员必须比较该步骤之前和之后的签名覆盖内容。服务自己的签名或 ARC密封 可以提供额外的证据，但两者都不应该被默默地描述为原始签名的恢复。纠正工作首先属于引入相关转换的参与者，而原始发送者仍然拥有其签名配置，接收者拥有其接受策略。
承担责任但不承诺交付
当接收服务器在消息数据后给出肯定的完成响应时， SMTP责任就会转移。然后，该服务器负责交付或适当的后续故障处理。这种传输责任不同于收件箱放置或在以后的每个跃点继续进行身份验证的承诺。重邮者应保留足以解释该传输的队列标识符、时间戳和有界诊断记录。 RFC 5321 ，第 4.2.5 节.
RFC 9989 明确讨论了间接流互操作性，并警告不要将域策略视为接收者的唯一处置输入。在规划发件人策略时审查列表参与和合法转发，而不是要求转发器保证每个收件人的行为。 RFC 9989 ，第 7.4 节.
仍需证据
直接和间接传递样本与路线、信封、签名和可信结果进行比较。此要求仍然开放。收集授权的匹配样本，标记可信接收者添加的结果，并比较跃点身份和修改。文献标准研究和虚构路线并未建立实际转发服务的行为。