从转发路由开始，而不是从Gmail标签开始
转发后到达Gmail的邮件与直接发送到 Gmail 的邮件具有不同的递送历史记录。转发服务可以更改SMTP信封、保留或更改原始消息，并附加其自己的身份验证观察结果。在要求原始发件人更改DNS之前先诊断该历史记录。成功的直接传递建立了有用的比较，但它并不能证明间接路由保留了相同的身份验证路径。
确定最终账户类型和转发机制。 Google 的一般发件人指南明确针对个人Gmail帐户，而组织的Google Workspace路由可能涉及其他管理选择。记录中介是否是别名服务、邮箱规则、网关或邮件系统。不要仅仅因为两个目标都显示熟悉的Gmail界面而对一种产品或路线应用规则。
阅读其范围内的提供商指南
谷歌目前的 转发指导 建议使用转发域 信封发件人，授权该域中的转发基础设施 SPF 策略，限制垃圾邮件转发并避免干扰的更改 DKIM。它还表示Gmail会执行自己的身份验证检查。这些建议并不保证收件箱送达或使以前的服务器的通行证在Gmail中具有权威性。
将该指南与 个人Gmail发件人要求。要求因发送量和消息目的而异。本文不能替代确定哪些要求适用于实际发件人。它也不建议更改用户的帐户设置，在没有适当的所有者决定的情况下启用转发或将地址添加到任何受信任列表。
分别遵循信封和可见标识
在最终的SMTP连接中， SPF使用连接服务器的地址评估相关身份。转发器是一个新的连接服务器，这就是为什么保留原始信封可以改变SPF结果。 RFC 7208第 10.3 节 解释了中介问题。消息的可见发件人地址是一个单独的标识，并且可能始终保持不变。
在转发者的域下重写的信封可以获得该域的SPF授权。仅通过在本地部分包含原始地址，它不会与原始作者域对齐。在下面 RFC 9989第 4.4 节, DMARC 需要传递具有所需域关系的经过身份验证的标识符。记录实际的域并 结盟 模式，而不是将SPF通行证视为整个答案。
为了进行调查，请从可用的可信传递记录中请求原始信封身份。决赛 Return-Path 可能有用，但不能独立描述每个早期的SMTP事务。将不可用的早期值标记为未知，而不是根据显示名称或引用的消息文本重建它们。
当转发允许时保留对齐的签名
当所覆盖的内容仍然经过验证时， DKIM可以继续转发。修改是否会使签名无效取决于签名的标头字段、主体覆盖率、 规范化 以及验证时的实际字节。 RFC 6376第 3.4 和 5.4 节 提供这些规则。不要声称每个添加的标头都会破坏DKIM ，或者每个具有未更改的可见正文的邮件都必须进行验证。
检查原始签名的签名域并 选择器，其列出的签名标头和接收者的验证结果。主题前缀、页脚、 MIME转换或附件转换可能会影响所涵盖的材料。比较可疑转换前后的消息。从不相关的转发域添加新签名不会修复原始签名或为原始作者建立对齐。
接收者可能会考虑 ARC 根据其自己的政策提供证据。 RFC 8617 描述该实验机制；有效的链不是自动DMARC通行证或交付保证。截至本次审查， 重新分类ARC的提案 工作仍在进行中。请勿将提案草稿变成有关Gmail已启用或禁用的功能的声明。
直接收据和转发收据的虚构比较
想象一下，虚构的发件人示例票证将一张收据直接发送到受控Gmail邮箱，并通过example.net的别名发送另一张等效收据。预期的作者域是example.com 。在本发明的场景中，直接副本具有有效的对齐签名，而转发的副本保留该签名，但获取改变其覆盖正文的页脚。
假设最终的信封在example.net下重写，并且SPF通过该身份。该假设的通行证与example.com不一致。接下来，审核者将检查是否有任何其他有效的对齐签名幸存以及最终接收者报告的内容。该示例未断言Gmail判决、 ARC覆盖或观察到的拒绝；没有发送或收集消息。
所提出的修复问题很狭窄：授权货运代理能否在满足服务需求的同时保留相关消息材料？这比在不了解身份和授权后果的情况下将转发器添加到原始发件人的策略中更有用。
在宣布成功之前保留证据包
使用经同意的测试帐户和批准的非敏感消息。捕获直接和间接的交付时间、路线标识符、信封观察、完整签名和可信的最终身份验证结果。单独记录实际处置： SMTP接受、邮箱传送、垃圾邮件放置和用户可见性不是可互换的结果。如果中间副本不可用，请说明无法本地化哪个转换。
根据代表性格式和路线评估拟议的更改，而不仅仅是一条纯文本消息。保留早期配置并定义触发恢复的内容。确切的目录门仍然开放：直接和间接交付样本与路线、信封、签名和可信结果进行比较。本手稿包含虚构的练习和当前的文档指导，而不是那些原始示例或经过验证的Gmail部署。