[ 平台指南 ]

Google Workspace群组和转发:测试实际消息路径

跟踪Google Workspace群组和转发路径,而不假设原始身份验证结果仍然存在。

由EmailAuth研究团队提供 · 4 分钟阅读

[ 要点 ]

  • 跟踪Google Workspace群组和转发路径,而不假设原始身份验证结果仍然存在。
  • 比较前后的身份,而不仅仅是分娩状态。
在此页面上

发送到工作区邮箱或组的邮件在到达最终读者之前可能会经过第二次旅程。下一个接收者看到 转发 系统连接,消息可能已更改。测试现有的路径,而不是理想化的直接交付样本。

检查DNS之前绘制路径

记录原始发件人、初始 Workspace 收件人或组、每个扩展或转发操作以及最终外部收件人。区分邮箱转发规则、组分配和路由规则。请注意该组是否更改主题、页脚、发件人字段或回复行为。这些是从您的实际设置和消息中收集的观察结果,而不是针对每个 Google 网上论坛的普遍声明。

在转发之前保留一份副本(如果可用)和原始最终消息。将它们与消息标识符和时间戳链接起来,从而允许中介生成新的标识符。如果交付被拒绝,请捕获完整的失败通知。通用退回标签无法识别失败的身份验证机制。

检查记录的 Google 网上论坛控件

Google 的网上论坛设置参考文档“发帖政策”下的“默认发件人”,其中包含作者或群组的地址作为选项,以及单独的“谁可以发帖”群组权限。记录这两个设置,而不是假设每个发帖者都可以使用组身份。这将验证可用的控件,而不是由您的特定交付生成的“发件人”字段。

所有者或管理员可以检查组设置,然后检查电子邮件选项。 Google 记录了主题前缀控件和标准或自定义电子邮件页脚选项。在批准的测试之前保留其当前值;在受控组中一次更改一项设置。单独的“发布回复”选项控制默认回复收件人,而不是 DMARC 结盟。这些产品特定的功能解释了为什么测试计划包括主题、身体和身份比较。

Google 的页脚说明表示要检查从Gmail中的群组收到的邮件:页脚不会显示在群组对话视图、 Gmail已发送文件夹或您抄送的副本中。为了进行身份验证分析,还需要保留来自预期分发路径的最终传递的原始消息。省略页脚的屏幕不得被误认为没有发生修改的证据。这些官方指令建立了特征模型;只有前后消息才能确定特定签名字段是否发生更改以及哪个签名幸存下来。

将SPF修复与原始域对齐分开

转发会更改连接到最终接收者的 IP。原来的域名 SPF 政策可能不会授权该中介机构。 Google 引用的转发指南专门针对转发到Gmail邮件。它不是 Google 网上论坛出站默认值的规范。对于操作该转发路径的管理员,建议更改 信封发件人 转发域身份并在该域的SPF策略中授权转发服务。这可以修复转发身份的SPF结果,而无需将其与原始可见的发件人域对齐。

不要将所有可能的转发服务添加到原始发件人的服务中 SPF记录。您可能无法控制该域,并且更改会将原始发送授权与下游路由混淆。如果转发器提供发件人重写,请确认其支持的行为并测试结果身份,而不是假设特定的实现。

保留有效的DKIM路径

Google 建议避免更改签名标头和正文内容,因为修改可能会导致无效 DKIM。检查原始签名的 d= 域, 选择器 以及最后一跳后的接收器结果。来自转发服务的第二个签名不会自动与原始作者的发件人域对齐。

ARC, 或者 已验证的接收链,如果存在的话,通过中介机构进行事先认证评估。它不会将每条转发的消息都转换为DMARC通行证或强制接收者信任该链。分别记录ARC结果和最终接收者的决定。 Google 明确对转发的消息执行自己的身份验证检查。

比较三个对照病例

这个原始测试矩阵描述了预期的推理,而不是观察到的谷歌结果。使用授权的发件人域以及受控组和收件箱。

  • 案例:直接控制;变化内容:没有分组或转发步骤;比较内容:基线SPF 、 DKIM和DMARC身份。
  • 外壳:未修改的前向;发生了什么变化:连接 IP 和可能的信封;比较什么:原件是否对齐 DKIM签名 幸存下来。
  • 案例:群组扩展消息;发生了什么变化:实际配置的组转换;比较内容:签名内容完整性、可见发件人、所有签名和ARC 。

例如,假设发件人是author@example.com ,转发器将信封重写为forwarding.example.net ,并且SPF会传递到那里。如果原始d=example.com签名仍然有效,则它可以提供DMARC对齐。如果该签名失败并且唯一剩余的有效签名是d=example.net,则列出的路径均不与example.com对齐。该图假设没有额外的对齐签名;接收方仍可以应用其自己的本地处置政策。

修复最小的责任组件

如果页脚破坏了幸存的签名,请检查该转换或提供商支持的组行为。如果故意重写可见的发件人身份,请评估新身份的身份验证以及演示文稿是否仍然服务于该组的目的。不要全局禁用域保护来使一条分发路径进行交付。

保留路径图、设置修订、编辑前后标题和最终结果。在组设置更改、路由更新、新网关、签名轮换或接收提供商的策略更改后重新运行比较。认证结果是交付的一项输入;即使技术链有效,投诉和滥用控制仍然很重要。

保留最少的比较记录

对于每个受控路径,记录设置修订、原始和最终消息标识符、UTC 时间、可见发件人、信封身份、所有DKIM签名者和可信接收者结果。在证据允许的情况下添加精确变化的场或身体区域。为不可用的预转发副本保留单独的未知字段。缺席的原件无法确定哪个中间人更改了消息。

[ 外卖 ]

比较前后的身份,而不仅仅是分娩状态。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

IT/邮件管理员

跟踪完整的跳序列

最初的pass并不是最终的结果。

后续步骤

  1. 比较直接消息和扩展消息。
  2. 记录每个DKIM身份和任何ARC证据。
  3. 对比展开前后的实际可见From。

CISO / SecOps

避免广泛的身份验证例外

单个转发错误不应削弱每个域发件人的能力。

后续步骤

  1. 需要范围修复计划。
  2. 与DMARC通行证分开审查可信中介决策。
  3. 保持例外决策的时间限制和所有权。

创始人/非技术人员

保持分发路径可见

组可以是关键业务工作流程的一部分。

后续步骤

  1. 命名群组所有者和外部收件人。
  2. 更改通知和路由后进行测试。
  3. 保留对重要分发工作流程的直接交付控制。

[ 常见问题解答 ]

常见问题

为什么只有转发后SPF才会失败?

最终接收者看到的是转发器的连接 IP,而不是原始发送者的 IP。

信封重写能否保证DMARC通过?

不需要。它可以验证转发器的域,而无需将该域与原始发件人地址对齐。

DKIM能否经受住转发?

是的,当相关签名内容和密钥验证仍然有效时。

一个团体总是会破坏DKIM吗?

否。检查该组的实际转换和收到的签名结果。

ARC是否强制收件人接受邮件?

不会ARC证据是在接收者的信任和处理政策范围内进行评估的。

我们应该授权SPF中的所有转发器吗?

否。将原始发送授权与下游转发行为分开。

测试应该保留什么?

受控的直接和转发样本、组设置、标识符、时间戳和最终接收器结果。

何时需要进行全球DMARC降级?

不要将其用作默认转发修复。在考虑单独批准的策略更改之前诊断并纠正特定路径。

[ 来源 ]

来源

  1. 将电子邮件转发到Gmail的最佳做法

    部分 管理员和发件人的电子邮件转发

  2. RFC 9989 :基于域的消息身份验证、报告和一致性 ( DMARC )

    部分 标识符对齐·策略和接收者处理

  3. RFC 6376 :域名密钥识别邮件

    部分 签名及验证

  4. RFC 7208 :发件人策略框架

    部分 MAIL FROM 身份 · DNS查找限制

  5. 创建群组并选择群组设置

    部分 发帖政策 · 电子邮件选项

  6. 向组电子邮件添加页脚

    部分 为组设置页脚·查看页脚

  7. 为群组消息的主题行添加前缀

    部分 添加前缀

  8. RFC 8617 :认证接收链 ( ARC ) 协议

    部分 §7.2.1 DMARC本地策略覆盖 · §9.3 邮件内容可疑 · §9.4 邮件密封程序可疑

[ 词汇表 ]

词汇表

转发
接受消息并将其传输到另一个目的地。
ARC
Authenticated Received Chain,跨中介机构传递身份验证评估。
信封重写
更改稍后传输中使用的SMTP发件人身份。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库