程序报出 Gmail SMTP 535 5.7.80，认证流程停在 AUTH，测试邮件还没发出去。
本周建议动作：先核对客户端实际发出的 AUTH 机制和对应凭据，再分别验证认证通过、邮件提交、受控收件；不要只凭错误文本认定是密码输错。这个错误表示 Gmail 不接受当前 SMTP 认证信息，但不能单独证明具体是哪项配置有问题，也不是邮件进垃圾箱的证据。Google 的 Gmail SMTP 错误说明
遇到该错误、要定位自家测试程序认证环节的开发者，可以从这里开始。
负责邮件回归的 QA，可以据此区分认证、提交与实际收件证据。
维护测试环境的独立开发者，也能按步骤核对配置，并避免把令牌或验证链接写进日志。
认证拒绝与邮件未到：故障发生在不同阶段
SMTP 流程中，认证发生在客户端连接服务器之后、提交邮件之前。Gmail 将 535 5.7.80 列为“用户名和密码不被接受”；这说明当前认证尝试被拒绝，不足以证明密码一定拼错，更不能由此推断邮件已提交但被收件箱拦截。
排查时，把日志里的响应对应到具体阶段：
- 如果收到 535 5.7.80 的位置是
AUTH，先查 SMTP AUTH 使用的认证机制、账号身份和凭据。 - 如果 AUTH 已成功，之后才进入邮件提交阶段。此时应查看服务器对邮件事务的最终响应，而不是继续把问题归为认证失败。
- 如果 SMTP 服务器接受了邮件，也还需要用受控测试收件地址检查是否实际收到。SMTP 的接受响应表示服务器承担后续投递或转发责任，不等同于邮件已进入收件箱。RFC 4954 对 AUTH 响应的说明；RFC 5321 对邮件接受与后续投递责任的说明
为什么 535 5.7.80 不足以直接判断是密码错误？
因为错误码说明的是当前认证没有通过，不是对你应用配置的完整诊断。用户名字段、传入的认证材料、所用机制或实际运行配置都可能与预期不一致。应先取得客户端真实发送的机制与账号信息，再对照 Google 的说明判断；不要把“用户名和密码不被接受”扩大解释成已确认的唯一成因。
还有一个容易混淆的边界：RFC 4954 描述通用 SMTP AUTH 响应，其中 235 2.7.0 表示认证成功，535 5.7.8 表示认证凭据无效或不足；Gmail 文档列出的则是 535 5.7.80。RFC 的通用定义不能替代 Gmail 对特定错误码的解释，更不能仅因数字相近，就把不同服务端响应认定为同一根因。
AUTH 机制与连接设置：客户端实际行为优先于配置意图
Gmail 的 SMTP 文档确认支持 OAuth 2.0，且使用 SASL XOAUTH2 将 OAuth 2.0 凭据用于 SMTP AUTH。关键不只是应用“配置了 OAuth”，而是实际连接时是否选择了 XOAUTH2，并按该机制传递认证响应。Gmail 的 IMAP、POP 和 SMTP 文档
怎么确认客户端使用的是 OAuth 2.0？
检查运行时日志、协议调试输出或邮件库的认证配置，确认 SMTP AUTH 行为使用 XOAUTH2，而不是用户名密码的其他机制。Google 的示例中，XOAUTH2 初始响应由邮箱身份和 Bearer 访问令牌组成，再按协议编码发送；只看到应用持有 OAuth 令牌，不足以证明 SMTP 客户端把它用于 XOAUTH2。Google 的 XOAUTH2 协议说明
对照客户端发送的字段时，重点看三件事：user= 后的邮箱是否是预期账号；auth=Bearer 后是否是本次连接使用的访问令牌；客户端最终发出的 SASL 机制是否确实为 XOAUTH2。不要把令牌全文复制到工单或共享日志中。只保留机制名称、账号脱敏标识和认证阶段等必要证据。
客户端还可能没有按预期连到 Gmail，或在 AUTH 前就遇到传输层问题。先核对实际运行时的 SMTP 主机、TLS 建连模式和连接日志；不要只检查环境变量或本地配置文件，因为部署环境可能覆盖它们。Google 文档说明 SMTP 主机为 smtp.gmail.com，支持 TLS；客户端若先以明文连接再发 STARTTLS，文档列出的连接方式为端口 587（TLS）或 465（SSL）。以客户端实际采用的方式为准，不要在没有核对建连过程时，把端口问题和 AUTH 阶段的 535 混为一谈。Gmail SMTP 连接说明
账号与令牌：授权有效不等于本次 SMTP 认证必然匹配
OAuth 令牌看起来有效，但认证仍被拒绝怎么办？
把“令牌能取得”与“令牌适用于这次 Gmail SMTP 认证”分开检查。先确认 SMTP XOAUTH2 响应中的邮箱身份与令牌授权对应的用户是否一致，再核对客户端申请和获得的授权范围。Google 的 OAuth 说明指出，令牌可执行的操作受其授权范围限制；访问令牌也有生命周期，应用需要按授权流程处理续期。不能仅凭令牌尚未过期，就认定它必然适用于当前 SMTP 连接。Google OAuth 2.0 服务端应用说明
按证据逐步收窄：
- 确认当前程序连接的是预期 Gmail 账号，而非另一套测试环境中的账号。
- 确认程序读取的邮箱身份与令牌取得授权时对应的用户一致。
- 核对 OAuth 授权范围是否适用于 Gmail；Google 的 XOAUTH2 文档提供了 Gmail 使用的范围说明。
- 确认程序使用的是可用于本次连接的访问令牌，并检查刷新逻辑是否返回了新令牌。
- 重新发起受控认证，只比较脱敏后的账号标识、机制名称和服务端响应，不把令牌原文写入日志。
不要把 Google 错误列表中相邻的其他响应自动等同于 535 5.7.80。例如，文档分别列出 504 5.7.40 的认证类型不识别，以及 534 5.7.90 的应用专用密码相关提示。它们属于不同响应，只有日志实际出现对应错误时，才按各自说明排查；不能因为都与登录或认证相关，就断定当前 535 5.7.80 由同一原因造成。
自家测试程序排查：按证据选择下一步
下面的条件分支用于排查自家产品或获授权的测试环境，不适用于批量注册第三方平台。
- 若日志显示 TLS 尚未建立，或程序没有到达 AUTH：先核对 SMTP 主机、传输加密模式和连接错误；此时不要先重置 OAuth 凭据。
- 若日志显示 AUTH 使用的机制不是
XOAUTH2：回到邮件客户端实际认证配置，确认它是否按预期使用 OAuth 2.0；不要把令牌塞入用户名密码认证字段后就认为已切换机制。 - 若 AUTH 使用
XOAUTH2，但返回 535 5.7.80：核对账号身份、Bearer 令牌对应关系、授权范围与令牌刷新结果，再做一次受控认证。 - 若 AUTH 收到成功响应：继续发测试邮件，记录服务端对邮件提交的响应；不要把认证成功记成“邮件已送达”。
- 若邮件提交得到接受响应，但测试地址没有来信：保留关联本次测试的非敏感标识，检查测试收件箱及发件端后续状态；不要回头把已通过的 AUTH 判断为失败。
- 若需要长期收信、回复邮件或找回重要账号：改用团队管理的邮箱或邮箱别名，不要把临时收件地址当作长期联系方式。
现场案例：QA 在预发环境触发注册验证邮件，应用日志只显示“发送失败”，团队一开始检查了收件箱规则。补齐 SMTP 会话后发现，失败点实际上在 AUTH；这时收件端尚无可供判断的测试邮件。修复机制与令牌后，团队仍需单独发送一封可关联的邮件，并确认测试地址确实收到，才能把整条流程标记为通过。
这种拆分有明确取舍：
- ✅ 按认证、提交、实收分别记录，能减少把认证问题误报成垃圾箱问题的排查回合。
- ✅ 使用脱敏测试账号和受控收件地址，不必把真实用户个人信息带入回归记录。
- ❌ 只看到 AUTH 成功就关闭工单，会漏掉提交失败或收件未验证。
- ❌ 将令牌、密码或完整验证链接贴进日志和截图，会把测试故障变成凭据与个人信息暴露风险。
验收记录：认证成功、邮件提交、实际收到分开签字
认证通过后，怎样确认测试邮件确实收到？
为这次自家产品测试触发一封可识别的邮件，并分别保留三个结果：SMTP AUTH 的原始状态；邮件事务是否得到提交接受响应；受控测试收件地址中是否出现对应邮件。邮件主题或关联标识应能和本次测试匹配，但不要把真实用户信息放进主题，也不要把完整验证链接写进日志。最终收件证据应来自收件端，而不是发送代码的“成功”布尔值。
验收记录可以控制在以下字段：
- 测试环境与触发操作，例如注册或密码重置。
- SMTP 连接是否到达 AUTH，以及使用的认证机制。
- Gmail 返回的原始错误码或认证成功响应。
- 邮件提交阶段的响应与脱敏后的关联标识。
- 受控测试收件地址的收件结果，以及检查时间。
- 凭据是否已从日志与截图中排除。
分别作有限定结论：“本次测试环境认证通过”“本次邮件得到 SMTP 提交接受”“本次受控地址已收到邮件”。这些结论只覆盖被测的应用配置、账号和测试路径，不能外推为所有环境都正常。若只是短期测试收件，SendTmp 当前提供无需注册即可使用的临时邮箱，可作为受控地址方案之一；开始测试前先查看临时邮箱入口，并按地址与邮件生命周期说明安排测试窗口。临时收件不适合需要持续收信、回信或账号找回的场景。涉及测试数据和个人信息时，也应先阅读SendTmp 隐私政策。
Gmail SMTP 535 5.7.80 的排查终点不是“改到不报错”，而是有证据地分清认证是否通过、邮件是否提交、受控地址是否实收。若你的目标只是给自家注册或验证流程接收一封测试邮件，SendTmp 可以作为不暴露主邮箱的可选收件方式；重要账户、长期通知和需要回复的邮件，仍应使用可持续管理的邮箱。