[ 平台指南 ]

Google Workspace SMTP中继:验证应用程序特定的身份验证

将使用 Google SMTP中继的权限与收件人观察到的应用程序邮件的身份验证分开。

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

[ 要点 ]

  • 分配应用程序责任
  • 验证完整的中继路径
  • 限制中继滥用
在此页面上

[ 外卖 ]

将使用 Google SMTP中继的权限与收件人观察到的应用程序邮件的身份验证分开。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

验证完整的中继路径

提交和外部身份验证是不同的门。

后续步骤

  1. 验证公共出口和范围中继权限。
  2. 捕获每个应用程序路由的外部标头。
  3. 在更改权限之前检查完整的诊断代码。

CISO / SecOps

限制中继滥用

广泛的中继权限可能会将应用程序泄露变成发送事件。

后续步骤

  1. 查看发件人范围和TLS要求。
  2. 在退休期间删除陈旧的授权。
  3. 网络更改后检查静态 IP 权限。

创始人/非技术人员

分配应用程序责任

商业工作需要投递者,而不仅仅是共享邮件租户。

后续步骤

  1. 确定关键工作和受控测试接受者。
  2. 计划数量相对于当前限制有所增加。
  3. 当数量超出中继范围时批准的替代方案的预算。

[ 常见问题解答 ]

常见问题

成功的SMTP响应是否证明DMARC通过?

否,证明提交阶段成功;检查外部收件人的身份验证结果。

通过 Google 路由传出SMTP中继消息 RFC 9989 :基于域的消息身份验证、报告和一致性 ( DMARC )

哪个IP属于IP授权规则?

Google 实际看到的公共出口 IP,已与网络所有者验证。

通过 Google 路由传出SMTP中继消息

任何地址都应该是默认地址吗?

否。选择支持批准的应用程序的最窄的允许发件人范围。

通过 Google 路由传出SMTP中继消息

SaaS 发送方是否可以因为我们使用 Workspace 而跳过自己的设置?

否。如果直接发送,请配置实际的发送服务。

我可以为中继添加第二条SPF记录吗?

否。在评估的信封域中维护一项适用的SPF策略。

RFC 7208 :发件人策略框架

TLS是否建立DMARC对齐?

不会。传输加密和域对齐是单独的检查。

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

为什么要在租户之外进行测试?

外部路径公开最终的发送者身份和任何下游修改。

设置DKIM

设备退役后会发生什么?

检查共享依赖关系并保留必要的审计证据后,删除未使用的中继授权。

[ 来源 ]

来源

  1. 通过 Google 路由传出SMTP中继消息

    部分 开始之前 · 在 Google 管理控制台中设置SMTP中继

  2. 设置DKIM

    部分 生成DKIM密钥 · 添加DKIM密钥 · 开启并验证DKIM

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

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

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

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

[ 词汇表 ]

词汇表

SMTP中继
接受消息并继续发送消息的服务。
信封发送者
由SPF对普通邮件评估的SMTP MAIL FROM 身份。
出口IP
中继看到的公共源地址。

企业出处

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

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

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

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

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

知识库