专题 · Google SMTP 中继服务

产品团队在选择 Google SMTP 中继服务时应评估哪些方面？

只有当 Google Workspace SMTP 中继的管理、身份和配额模式与工作负载相符时，才选择它。确认谁拥有 Workspace 域名和管理控制台中的相关设置，应用能否使用稳定且已加入允许列表的公网 IP 或受 TLS 保护的 SMTP 身份验证，允许使用哪些信封发件人，以及如何强制执行 TLS。在上线前，根据 Google 当前按用户、按客户和按事务的限制进行建模。测试暂时性和永久性错误，保留 SMTP 回复，使用 SPF、DKIM 和 DMARC 对可见发件人进行身份验证，并将受理、收件服务器投递和进入收件箱作为不同的结果分开处理。

从工作负载和管理适配度入手

Google 的 SMTP 中继服务是 Google Workspace 提供的一条管理型路由，供应用、设备和邮件服务器通过 smtp-relay.gmail.com 发信。请将其作为组织 Workspace 和邮件安全边界的一部分来评估，而不是当作一个通用的匿名 SMTP 端点。明确 Workspace 超级管理员负责人、账户中的域名、来源系统、公网出口 IP、发件地址、邮件类别、峰值和每日收件人数量、附件情况以及事故联系人。判断该工作负载属于事务性、内部运营、用户撰写、订阅批量还是设备生成的邮件。将这些类别分开，因为它们在授权、同意、抑制、审计和信誉方面的需求各不相同。确认较低级别的环境无法使用生产路由或客户地址。中继可以传输经过授权的邮件，但它不负责判断业务事件是否合法、收件人是否同意，或下游的应用状态是否应当推进。

比较 IP 授权与 SMTP 身份验证

按照 Google 当前的配置，管理员可以将中继的接入限制为指定的公网 IP 地址、要求通过 TLS 进行 SMTP 身份验证，或按照文档所述的设置组合使用这些策略。稳定的 IP 授权适合受控的数据中心或固定的出口网关，但在不断变化的云 NAT、多区域、故障切换服务或第三方网络之后就会变得脆弱。SMTP 身份验证能识别 Workspace 账户和发信域名，但会带来凭据生命周期、用户状态、多因素认证和策略之间的相互影响，并且硬性要求使用 TLS。绝不要在多个租户或互不相关的应用之间共用一个范围过大的凭据。对于每种方式，记录谁可以添加 IP 或账户、变更如何审核、如何发现泄露、如何撤销访问，以及故障切换时会发生什么。尽可能缩小允许的 IP 范围，并从实际运行环境核实公网出口地址，而不是照抄一个内网地址。

明确允许的发件人和域名身份

管理控制台中的中继设置用于控制允许哪些发件人。Google 文档描述了与已注册 Apps 用户和自有域名中的地址相关的选项，以及一个会增加滥用风险、范围更宽的“任意地址”选项。请选择工作负载能满足的最窄选项。将 SMTP 信封发件人与可见的 From 和 Reply-To 字段分开盘点。Google 指出，当发件人不属于账户中的域名时，SMTP AUTH 或在 HELO 或 EHLO 中提供的域名可能会影响信封发件人的识别或改写方式。不要把改写当作自有发件人模型的替代品。要求为应用、租户、邮件类别、信封发件人、可见 From 域名和退信路径建立经过批准的映射关系。在连接 Google 之前，拦截用户随意提供的邮件头、换行符注入和跨租户的 From 地址。测试退信路由和外出自动回复邮件（包括空信封发件人的情况），同时不要放宽整个设置。

有意识地要求传输安全

Google 当前的中继指南要求启用了 TLS 的本地系统连接 smtp-relay.gmail.com 的 587 端口，并说明 SMTP 身份验证必须使用 TLS。管理员设置还可以要求来自发件服务器的连接必须使用 TLS。除非某个成文的旧系统限制获得了有时限的例外，否则请在生产环境中启用强制 TLS。校验服务器名称、证书链、支持的协议和加密套件策略、STARTTLS 协商以及失败时的行为。如果无法建立必需的 TLS，客户端必须以失败关闭的方式处理；悄悄回退到明文会让该策略形同虚设。将 SMTP 凭据保存在托管的密钥存储中，不要出现在命令行、URL、源代码、日志、分析系统、崩溃报告和工单中。传输层 TLS 只保护到 Google 的这一跳，并不保护邮件的整个生命周期或邮箱。敏感内容可能还需要应用层控制、数据最小化、数据保留策略，以及单独的端到端加密决策。

在选择中继之前先根据当前配额建模

Google 当前的 SMTP 中继配置文档说明，每个用户在 24 小时内最多可以发送 10,000 封邮件，且收件人不超过 10,000 个唯一地址，试用账户的限制可能更低。文档还规定了每个 SMTP 事务最多 100 个收件人，以及额外的客户级、峰值和每日控制。请将这些视为当前文档中的上限，而不是容量目标或永久承诺。上线前，请针对具体账户和工作负载重新查阅官方页面。按收件人而不仅仅是按邮件数量计算，涵盖 To、Cc、Bcc、重试和扇出。将应用层的速率、并发、队列时长和租户公平性控制设在 Google 的限制之下。对增速和剩余余量设置告警。不要通过把流量分散到未经授权的账户、轮换信封发件人或打开不受控的连接来应对限制。经常逼近共享 Workspace 边界的工作负载，可能需要评估专门构建的传输方案。

构建可靠的提交工作流

将 SMTP 客户端放在经过授权的服务端 worker 或队列之后。为每个出站任务持久化保存：稳定的业务事件键、租户、邮件类别、模板版本、经批准的发件人和收件人、同意或必要性依据、抑制决策以及尝试历史。只认领该任务一次，渲染并校验内容，然后连接到配置好的 Google 端点。根据当前限制和产品策略限制每个事务的收件人数量和邮件大小。记录完整的 SMTP 回复、增强状态码、远程主机、时间戳和尝试标识符，但不要记录凭据或不必要的内容。如果中继接受了 DATA 事务，只将其标记为服务商或中继受理阶段。如果客户端在发送数据之后、收到最终回复之前超时，请将该次尝试标记为未知，并在重新发送之前进行对账。SMTP 不提供应用层的幂等键，因此防重复控制应由产品的队列和事件模型负责。

对中继错误进行分类，而不是一律重试

Google 的 SMTP 中继错误页面记录了多种不同的情况，包括拒绝邮件中继、中继凭据或域名标识无效、超出每日限制、因峰值限制而暂时延迟，以及单个事务中的收件人过多。获取确切的回复，并将其映射到一个细分的内部类别。在重放之前，先修复配置、发件域名、凭据、IP 以及单事务收件人数量方面的错误。每日限额用尽后，暂停或重新安排任务。对符合条件的暂时性峰值错误或传输错误，使用带抖动的指数退避、尝试次数上限和队列时长限制进行重试。绝不要无限期地重试永久性响应。如果错误提示某个 IP 未注册，请确认运行环境真实的公网出口地址和正确的 Workspace 设置，而不是扩大允许列表。按来源系统、配置版本、发件域名、状态类别和时间保存经过隐私最小化处理的汇总计数。对新出现的回复和身份验证失败激增设置告警，因为它们可能意味着策略漂移、凭据被撤销、NAT 变化或滥用。

在中继访问之外对发件人进行身份验证

获准使用 Google 中继并不等同于面向收件方的发件人身份验证。发布一条 SPF 策略，为信封身份授权实际的发信路径；使用由组织控制且与 DMARC 对齐的域名配置 DKIM 签名；并为可见 From 域名发布一条经过审核的 DMARC 策略。从受控的外部邮箱验证实际收到的原始邮件。记录 SPF 结果和域名、DKIM 结果、d= 域名和选择器、可见 From 域名、对齐情况以及 DMARC 结果。一个技术上有效的服务商或 Workspace 签名，仍可能与自定义的 From 域名不对齐。转发也可能改变 SPF 证据。不要为了让某个测试通过就添加第二条 SPF 记录，或在整个组织范围内削弱 DMARC。协调 DNS 和邮件管理员，保留原有记录，测试权威和递归应答，并一次只推出一项身份变更。

要求可观测性和经过测试的退出路径

在可用时使用 Google 管理控制台的电子邮件日志搜索和中继侧日志，但要以产品自有的出站台账作为决策依据。按邮件类别和发件域名监控队列时长、受理、暂时性和永久性响应、限额使用情况、退信和投诉信号、身份验证以及延迟。限制访问权限，并避免在常规指标中出现完整地址或邮件内容。测试来源 IP 变化、凭据轮换、TLS 失败、管理员设置被禁用、用户被暂停、限额用尽、收件人扇出、DNS 变更以及服务商故障。制定一个可以暂停受影响批次、又不会丢弃持久化任务的回滚方案。迁移时，将服务商特有的 SMTP 字段隔离在一个适配器中，并保留业务事件键、抑制状态、发件人授权和尝试历史。第二个中继绝不能成为自动绕过永久性策略拒绝或收件人拒绝的通道。兼容性需要逐字段、逐错误的测试，而不只是更换一个主机名。

SendHQ 的适用场景

SendHQ 是一个限定工作区作用域、用于符合预期的产品通信的邮件 API，具有已验证域名发送、入站邮件、托管模板、投递事件、抑制记录和 Web 控制台。请通过当前文档和受控测试，将其与 Google Workspace SMTP relay 比较：账户和租户边界、凭据及轮换、获准发件人规则的强制执行、信封和可见身份、TLS 失败、收件人限制、暂时性和永久性回复、结果不明确、抑制记录、事件回读和迁移。

常见问题

Google Workspace 的 SMTP 中继使用哪个主机名？

Google 当前的配置指南使用 smtp-relay.gmail.com。请根据官方说明和组织强制执行的安全策略来选择端口和 TLS 行为。

可以按来源 IP 限制 Google SMTP 中继吗？

可以。管理员设置可以只接受指定的公网 IP 地址。请将地址范围保持在最小，并核实运行环境实际的出口地址和故障切换行为。

在该中继上，不使用 TLS 能进行 SMTP 身份验证吗？

Google 当前的指南说明，SMTP 身份验证必须使用 TLS。如果必需的 TLS 协商或证书校验未成功，生产环境客户端应以失败关闭（fail closed）的方式处理。

一个 SMTP 中继事务最多可以包含多少个收件人？

Google 目前的文档规定，每个 smtp-relay.gmail.com 事务最多 100 个收件人。请重新查阅官方的最新页面，因为服务商的限制和账户条件可能会变化。

遇到中继峰值限制错误时应该重试吗？

Google 将峰值限额用尽描述为暂时性情况。请保留同一个持久化任务，使用有上限的退避、抖动、尝试次数上限和队列时长限制，而不是立即扇出。

中继受理是否意味着收件人已收到邮件？

不是。中继受理只是传输中的一个阶段。收件服务器接收、之后的退信、邮箱过滤、进入收件箱以及收件人的互动，都是各自独立的观测结果。

Google 中继访问能替代 SPF、DKIM 和 DMARC 吗？

不能。中继授权控制的是对 Google 服务的使用。面向收件方的身份验证和 DMARC 对齐，需要正确的发信身份、DNS 记录、签名以及对已收到邮件的验证。

本页能证明 SendHQ 与 Google SMTP 中继兼容吗？

不能。请将 SendHQ 文档所述功能与 Google Workspace SMTP relay 要求进行比较，并使用受控测试验证身份验证、TLS、配额、错误和投递事件回读。

参考来源

继续学习

如何评估 SMTP 中继服务从提交安全、身份验证、队列、重试行为、限制、投递事件、抑制列表、隔离和迁移适配度等方面评估 SMTP 中继服务。SMTP 邮件协议：应用邮件如何传递了解 SMTP 提交、中继、信封、响应码、TLS、重试和邮件内容如何影响应用的邮件工作流。SMTP 端口 25、465 和 587 实用指南根据角色和 TLS 模式选择合适的 SMTP 端口，并诊断连接、握手、身份验证和邮件受理失败。如何评估邮件送达率服务从范围、证据、身份验证、反馈环、抑制列表、隐私、可迁移性和运营适配度等方面评估邮件送达率服务。Gmail API 实施指南（面向产品团队）以最小权限 OAuth、可靠的邮箱同步、安全发送、有上限的重试和清晰的服务账号模型来实现 Gmail API 访问。