Go SMTP 返回 535 怎样区分认证和发件人问题

Go 用 net/smtp 发信时遇到 535，不能只凭错误码认定“用户名或密码错了”。真正有区分度的是失败发生在哪个 SMTP 命令：Auth 阶段失败，优先看认证方式、账号和 TLS；Mail 阶段失败，则要检查信封发件人是否被服务器允许。若直接调用 smtp.SendMail，这些阶段被封装在一次调用里，排障信息往往不够细。

官方地址：https://pkg.go.dev/net/smtp

下面的示例只展示 API 边界和错误记录方式，图片是静态说明图，不是终端截图或实际投递结果。

535 到底发生在认证还是发件人阶段

先把一次 SMTP 会话拆成几个边界：建立连接并协商 TLS，调用 AUTH 完成认证，然后用 MAIL FROM 指定信封发件人，再用 RCPT TO 指定收件人。Go 官方文档中，Client.Auth 负责认证，Client.Mail 负责发起邮件事务，二者返回的错误代表不同阶段。

如果错误是在 c.Auth(auth) 返回，常见排查方向是账号密码、认证用户名格式、服务器是否开放 SMTP AUTH、认证主机名是否传对，以及连接是否满足 PlainAuth 的 TLS 条件。PlainAuth 只有在连接使用 TLS 或连接到 localhost 时才会发送凭据，否则会在客户端侧拒绝发送。

如果认证已经成功，错误出现在 c.Mail(from)，说明服务器已经进入邮件事务，却不接受当前信封发件人。此时要检查 from 是否是允许的发件地址、是否必须与认证账号一致、账号是否具有代发权限，以及服务商是否要求先验证发件人。这里不能把所有服务器的 535 文本硬编码成同一个结论，必须保留返回文本。

为什么 SendMail 不适合直接定位

smtp.SendMail 会连接服务器、尽可能切换 TLS、执行可选认证，然后发送邮件。它适合一段简单的发送逻辑，但调用方拿到的通常只是一个聚合后的 error。如果日志没有记录调用前后的阶段，就很难知道 535 来自认证还是发件人策略。

package mailtrace

import (
    "errors"
    "fmt"
    "net/smtp"
    "net/textproto"
)

// classifySMTPError 保留 SMTP 原始数字码和服务器文字，避免只凭 535 猜原因。
func classifySMTPError(stage string, err error) error {
    if err == nil {
        return nil
    }

    var smtpErr *textproto.Error
    // textproto.Error 能提供服务器返回的 Code 和 Msg，便于按阶段排查。
    if errors.As(err, &smtpErr) {
        return fmt.Errorf("%s 阶段失败：SMTP %d %s：%w", stage, smtpErr.Code, smtpErr.Msg, err)
    }
    return fmt.Errorf("%s 阶段失败：%w", stage, err)
}

// sendWithStageLog 按 SMTP 命令边界发送，便于区分认证与发件人问题。
func sendWithStageLog(addr, host, username, password, from, to string, msg []byte) error {
    c, err := smtp.Dial(addr)
    if err != nil {
        return classifySMTPError("连接", err)
    }
    defer c.Close() // 连接失败或中途返回时也要释放网络资源。

    auth := smtp.PlainAuth("", username, password, host)
    if err := c.Auth(auth); err != nil {
        return classifySMTPError("Auth 认证", err)
    }
    if err := c.Mail(from); err != nil {
        return classifySMTPError("Mail 发件人", err)
    }
    if err := c.Rcpt(to); err != nil {
        return classifySMTPError("Rcpt 收件人", err)
    }

    writer, err := c.Data()
    if err != nil {
        return classifySMTPError("Data 数据", err)
    }
    if _, err := writer.Write(msg); err != nil {
        _ = writer.Close() // 写入失败时仍尝试关闭消息写入器。
        return classifySMTPError("Data 写入", err)
    }
    if err := writer.Close(); err != nil {
        return classifySMTPError("Data 结束", err)
    }
    return classifySMTPError("Quit 关闭", c.Quit())
}

这段代码的关键不是把 535 改写成固定文案，而是把 Auth、Mail、Rcpt 分开记录。这样日志里至少会有“Auth 认证阶段失败”或“Mail 发件人阶段失败”，再结合服务器返回的 Code 和 Msg 做判断。

认证失败与发件人拒绝分别查什么

可以按“输入、约束、结果”做一次快速对照：

还有一个容易混淆的点：邮件头里的 From: 和 SMTP 信封里的 MAIL FROM 不是同一个字段。服务器在 Mail(from) 阶段检查的是信封发件人；即使邮件头看起来正确，信封地址不被允许，仍然会被拒绝。因此排查时要把传给 c.Mail(from) 的字符串单独记下来，但不要记录密码、授权码或完整凭据。

一份不容易误判的落地清单

• 先记录阶段：至少区分连接、TLS、Auth、Mail、Rcpt、Data。
• 再记录原文：保留 SMTP 数字 Code 和服务器文字 Msg，不要只存“535”。
• 核对两套地址：认证用户名与 MAIL FROM 分开看，必要时确认账号是否允许代发。
• 核对安全条件：使用 PlainAuth 时确认连接已满足 TLS 或 localhost 条件，避免凭据根本没有发送。
• 最后再看服务商文档：535 的具体文字和策略可能不同，不能用另一家服务商的经验替代当前返回。

因此，Go SMTP 返回 535 的第一步不是重试，而是把“失败阶段”和“服务器原文”补齐。只有确认错误发生在 Auth，才优先修认证配置；若错误发生在 Mail，就把注意力转向信封发件人和发件权限。

相关问题

smtp.SendMail 还能继续用吗？

可以。发送流程稳定且不需要细分故障阶段时，SendMail 更简洁；遇到持续 535 或需要审计阶段时，再切换到 smtp.Client 逐步记录。

为什么密码正确仍然会在 Auth 阶段失败？

还可能是 SMTP AUTH 未开放、认证机制不匹配、TLS 条件不满足，或者传给 PlainAuth 的 host 与服务器身份不一致。先看完整的 Msg，再按服务商规则处理。