2026 Google Workspace SMTP Relay 测试邮件被拒怎么办？
这篇文章面向用 Google Workspace SMTP Relay 测试自家产品邮件的开发者、QA 和环境维护人员。我们先区分中继拒绝、连接认证失败和中继接受后的收件异常，再给出配置对照、日志取证及受控收件验收步骤。
RFC 5321 规定，SMTP 服务器在邮件内容接收完成后返回 250，表示它已接受该邮件并承担后续投递或报告失败的责任；这不代表邮件已经出现在收件箱。遇到 Google Workspace SMTP Relay 测试邮件被拒，先看 SMTP 响应和发送日志：明确拒绝时核对发信出口 IP、允许的发件人、认证方式与 HELO/EHLO 身份；中继接受后仍无可见邮件，再查后续投递和收件分类，最后用受控地址验证真实收件。
本文适合用 Google Workspace SMTP Relay 发送自家产品通知或验证邮件的开发者，以及需要复核预发邮件的 QA 工程师。
如果负责维护发信主机、网络出口或中继规则，可以按症状定位配置与日志之间的断点。
先分清连接失败、中继拒绝与没有实收
同一次测试，至少要留下发信端记录和一个可访问的受控收件地址。只看应用页面的“发送成功”提示，无法判断邮件有没有完成 SMTP 提交；只看测试收件箱，也无法判断问题究竟出在连接、中继规则，还是后续投递。
| 可观察到的结果 | 代表什么 | 下一步检查 |
|---|---|---|
| TCP 连接失败，或没有收到 SMTP 服务端问候 | 尚未证明 SMTP 会话已建立，更没有证明邮件已提交 | 主机名、端口、防火墙、TLS 或 STARTTLS 协商 |
| SMTP 会话返回拒绝，邮件事务未完成 | 中继未接受本次提交，或连接／认证阶段失败 | 完整错误文本、拒绝发生的命令阶段、规则匹配条件 |
邮件内容结束后返回 250，收件箱却看不到 |
中继接受了提交，但仍需查后续投递与收件分类 | 退信、邮件日志、受控收件端的垃圾邮件或其他分类 |
SMTP 的 250 要结合它出现的位置来读：如果是在 EHLO 后出现，只能说明该命令获肯定响应；邮件内容发送结束后收到肯定完成响应，才表示该邮件事务被接受。协议说明，服务器在邮件内容结束后接受邮件，意味着责任交接；后续诊断出的失败仍应通过适当方式报告。RFC 中的描述只能帮助判断 SMTP 事务状态，不能代替对目标邮箱实际收件的检查。
relay denied 时先对照日志与规则
Google Workspace SMTP Relay 显示 relay denied，先检查什么？
先保存完整 SMTP 错误，不要只抄下 550 或 5.7.1。Google 的错误说明会把特定拒绝关联到 IP 未登记、IP 与发件域不匹配、发件身份无法识别等情况；同样的状态码也可能对应其他策略问题，所以需要结合错误全文和本次会话记录判断。Google 的 Gmail SMTP 错误代码说明列出了包括 Email relay denied ip-address 在内的错误语义。
| 对照项 | 核对内容 | 容易遗漏的差异 |
|---|---|---|
| 发信 IP | 从 SMTP 连接实际出口确认公网 IP，并与中继规则的允许范围比较 | 本地开发、预发与 CI 可能走不同出口；一个环境登记成功，不代表另一个环境匹配 |
| 允许的发件人 | 查看当前规则允许注册用户、域内地址，还是任意地址 | From 显示名与 SMTP 信封发件人 MAIL FROM 不是同一层信息 |
| 认证方式 | 确认本次走的是 IP 验证、SMTP AUTH，还是规则允许的组合 | 不要把一个路径的凭据或前置条件套到另一个路径 |
| HELO/EHLO 与域名 | 查看客户端实际提交的主机身份，并与自家 Workspace 域及规则对照 | 通用主机名、空信封发件人或不匹配的域名，可能影响中继识别 |
| TLS | 查看管理员是否要求 TLS，以及本次连接是否完成相应协商 | TCP 可连通不代表 TLS 已完成，也不代表 SMTP AUTH 已成功 |
已登记 IP 后仍被拒，下一步查什么？
不要只核对管理后台里“有一条 IP”这一事实。要从发生故障的那台主机、容器或 CI runner 发起连接，确认实际对外出口地址；如果经过 NAT、代理或云网络出口，检查最终到达 Google 的地址是否仍在规则允许范围。再把失败环境的 MAIL FROM、From、认证结果和 EHLO 主机名与一次成功环境逐项比较。
Google Workspace 的官方 SMTP Relay 配置说明区分了允许发件人选项、IP 地址验证和 SMTP AUTH；文档还说明 SMTP AUTH 需要 TLS 连接。它也指出，对于域外发件人或空信封发件人等特定情况，服务器可能需要使用 SMTP AUTH 识别发件域，或在 HELO/EHLO 中提供自有域名。具体适用条件要以当前账户规则及错误信息为准，不能只凭某个字段推断拒绝原因。
连接与身份配置要分开定位
连接或 TLS 阶段失败，不要先改发件地址。 先从客户端日志确认是否连接到 smtp-relay.gmail.com，实际使用的端口是否与当前配置相符，TLS／STARTTLS 是否完成，以及服务端在哪一步返回响应。Google 官方配置说明给出的常见设置包括：启用 TLS 时使用端口 587；不使用 TLS 时可配置端口 25、465 或 587，但没有 TLS 时不能使用 SMTP AUTH，需采用 IP 地址验证。应按当前文档和本环境规则核对，不要把某一种部署配置当成所有环境的通用答案。
| 当前证据 | 故障更可能位于 | 处理方向 |
|---|---|---|
| 连接超时或拒绝，服务端未问候 | 网络或目标地址 | 检查 DNS 解析、出站防火墙与实际连接目标 |
| 服务端要求 STARTTLS，客户端未完成协商 | 传输加密阶段 | 检查客户端是否启动 TLS，以及证书或协议协商日志 |
| 提示需要认证，或认证被拒 | 身份验证阶段 | 对照规则是否要求 SMTP AUTH、凭据是否对应允许的账户 |
MAIL FROM 或发送方身份被策略拒绝 |
中继规则阶段 | 检查允许的发件人类型、信封发件人、HELO/EHLO 与域名关系 |
这里不建议通过重复发送来“试出”配置。每次重试都会增加噪声，也可能让日志里的测试运行难以关联。先记录发生失败的 SMTP 命令、服务端完整响应、环境标识和时间，再一次只改一个条件；这样才能知道哪项变化真正改变了结果。
中继已接受但没有邮件时，查投递证据
SMTP Relay 接受测试邮件后，怎样确认测试收件箱确实收到？
先确认返回成功的是邮件内容提交完成后的响应，而不是连接问候、EHLO 或其他命令的成功响应。然后核对收件地址、邮件标识和测试时间，并查看发送端是否有退信或后续错误。如果收件端是同一 Workspace 组织内的地址，可由有权限的管理员使用 Email Log Search 搜索发件人、收件人或邮件 ID，查看状态、投递位置以及是否被标记为垃圾邮件。Google 的 Email Log Search 指南说明了该工具的查询方式和结果边界。
| 证据层 | 可以得出的结论 | 不能据此断言 |
|---|---|---|
| SMTP 返回成功完成响应 | 中继已接受该邮件事务 | 邮件已进入目标收件箱 |
| 发送端没有记录到提交 | 这次运行未能证明邮件已交给中继 | 对方邮箱一定拒收 |
| 邮件日志显示已投递或标记为垃圾邮件 | 可进一步判断邮件到达后的状态或分类 | 用户已打开邮件，或应用业务已完成 |
| 受控收件箱中找到本次测试邮件 | 测试地址确实收到了这封可识别的邮件 | 其他用户、其他邮箱服务也会得到相同结果 |
若日志显示已交付，收件箱仍没有，就查垃圾邮件、归档、规则或其他分类；不要把“没有出现在主收件箱”直接等同于“中继拒绝”。Google 的SMTP Relay 垃圾邮件与滥用排查说明建议管理员结合发件用户和中继 IP 调查异常发送。管理员需要把邮件日志和收件端实际查看结果分开记录：前者帮助定位投递状态，后者才能证明测试地址上的邮件可见。
用受控收件完成自家产品验收
下面的步骤只用于自家产品或明确获授权的测试环境。每一步都保留能关联同一次运行的标记，例如测试运行 ID、邮件主题中的唯一标签或应用日志中的消息 ID；不要在测试证据中保留真实用户的敏感内容。
- 固定一次测试条件。 记录环境名称、目标收件地址、发件人配置和本次运行标识，避免把开发环境与预发环境的记录混在一起。
- 确认连接阶段。 在应用日志中确认目标主机、连接结果、TLS／STARTTLS 协商状态及服务端问候；若没有得到服务端响应，先修网络或连接配置。
- 保存完整 SMTP 事务结果。 记录认证结果、
MAIL FROM、RCPT TO、发送内容后的最终响应，以及完整拒绝文本。对外共享前遮盖凭据、访问令牌和不必要的个人信息。 - 被拒时一次检查一组相关配置。 先比对实际出口 IP 与规则，再核对允许发件人、验证方式、信封发件人及 HELO/EHLO 身份；不要同时改动多项后仅凭结果猜原因。
- 收到中继成功响应后转查收件证据。 核对地址拼写，检查退信和可用的邮件日志，再查看收件箱、垃圾邮件及其他分类。
- 在受控地址打开本次邮件。 验证主题、正文、链接或通知内容与预期一致；若测试验证链接，还要确认它能完成自家应用中的业务步骤。
- 写清验收结论的边界。 分别记录“中继是否接受”“受控地址是否可读”“应用流程是否闭环”。这三项不要合并成一个含糊的“邮件发送成功”。
测试证据应足以关联同一次运行，但不必包含真实用户信息。共享日志前遮盖凭据和不必要的个人数据；如果测试用邮箱还要承担长期找回或回复功能，就不要把临时收件地址当作正式账号邮箱。
测试收件地址也有边界。RelayTmp 提供即开即用的临时收件箱，页面说明无需先注册即可打开地址；它是收件工具，不提供发信或回复，也不承诺第三方一定接受其域名或每封邮件必达。可把它作为短期、低风险验收的一种受控收件方式，但应先确认当前页面可访问，并以实际收到的邮件作为证据；不要用于需要长期找回的重要账户。具体限制可查看RelayTmp 的服务边界说明，地址与邮件相关数据的处理方式见隐私说明。
如果中继日志已经证明提交被接受，下一步应把注意力转到受控收件、分类和应用闭环，而不是继续反复改中继规则。需要测试自家注册或通知邮件时，RelayTmp 可作为短期收件验证方案之一；若测试结果需要长期保存、地址要承担账号恢复用途，或流程要求从收件地址回复，就改用团队控制的长期邮箱。这样既能判断 Google Workspace SMTP Relay 测试邮件被拒究竟发生在哪一层，也不会把“服务端接受”误写成“用户真实收件”。
打开一次性收件箱
打开即获得可复制的一次性邮箱，并在同页刷新和阅读真实测试邮件。