邮件发送失败是后端服务接入通知、验证码或订阅推送时最常遇到的故障之一。其根源大多集中在SMTP服务器的连接配置与身份认证环节，而不是业务代码逻辑本身。SMTP即简单邮件传输协议，负责把邮件从客户端投递到邮件服务器再中转给接收方。当配置的主机名、端口不正确，或者加密模式与实际服务不匹配时，TCP连接就无法建立；即便连上了，若认证凭据无效，服务器也会返回535等错误并中断会话。理解这一机制，是排查问题的前提。
SMTP基础连接配置与常见错误
在多数编程语言里，发送邮件首先要设定SMTP服务器地址与端口。以QQ邮箱为例，其SMTP主机为smtp.qq.com，非加密端口25通常被运营商封锁，推荐采用SSL加密的465端口或STARTTLS的587端口。如果代码里写成普通25端口且运行在云服务器上，经常会遇到连接超时，因为云厂商出于防垃圾邮件考虑默认禁掉25出站。此时改换465并启用SSL，往往就能连通。
另一个容易忽略的点是本地DNS解析与防火墙。有些内网环境无法解析公网邮箱域名，或者安全组没有放行对应端口，也会导致java.net.ConnectException或Timeout。排查时可用telnet smtp.qq.com 465测试通路。下面是一段Python使用smtplib的错误示范，它使用了错误端口且未加密：
import smtplib
from email.mime.text import MIMEText
msg = MIMEText('测试内容', 'plain', 'utf-8')
msg['From'] = 'user@qq.com'
msg['To'] = 'target@ipipp.com'
msg['Subject'] = '测试邮件'
try:
# 错误：使用25端口且未加密，云服务器多数会失败
server = smtplib.SMTP('smtp.qq.com', 25)
server.sendmail('user@qq.com', ['target@ipipp.com'], msg.as_string())
except Exception as e:
print('发送失败:', e)
上述代码在本地宽带可能成功，但部署到阿里云、腾讯云等环境就会卡在连接阶段。改进方式是显式指定SSL上下文与465端口，这能绕开运营商对25端口的限制，也符合邮箱服务商的安全规范。配置层面要先确认所用服务商的官方文档，不要凭记忆填写参数。
身份认证机制与授权码误区
SMTP身份认证通常在连接建立后通过AUTH LOGIN或AUTH PLAIN指令完成。这里最大的误区是把邮箱登录密码直接当作SMTP密码。主流邮箱如QQ、163、Gmail都要求开启“客户端授权码”，这是一个独立于网页登录密码的随机串，用于第三方应用发信。若填了真实密码，服务器会返回535 Authentication failed。
在代码里，登录动作必须放在starttls或ssl包装之后。以Node.js的nodemailer为例，transport配置中的auth对象应填user和pass，这里的pass就是授权码。许多人复制了邮箱密码，或者授权码生成后未保存，反复测试都失败。此外，部分企业邮箱需要额外在管理后台给账号开放SMTP权限，仅仅有授权码还不够。如下是正确填写授权码的片段：
const nodemailer = require('nodemailer');
let transporter = nodemailer.createTransport({
host: 'smtp.qq.com',
port: 465,
secure: true,
auth: {
user: 'user@qq.com',
// 此处pass是邮箱设置里生成的授权码，不是登录密码
pass: 'abcdefghijklmnop'
}
});
transporter.sendMail({
from: 'user@qq.com',
to: 'target@ipipp.com',
subject: '主题',
text: '内容'
}).then(info => console.log('发送成功', info.messageId))
.catch(err => console.error('发送失败', err));
如果依旧认证失败，建议登录邮箱网页端检查是否开启POP3/SMTP服务，并重新生成授权码。有些邮箱对授权码有有效期或设备绑定限制，更换服务器IP后可能被临时冻结，需要人工解除。认证问题排查的核心就是确认“用的不是密码而是授权码”以及“账号本身有发信许可”。
代码层重试与错误日志定位实践
即便配置和认证都正确，网络抖动也会让邮件偶尔发送失败。健壮的发送模块应当包含重试与详细日志。在Java的JavaMail中，可以开启debug输出完整的SMTP对话，从中看到是哪一步返回了错误码。例如属性mail.debug设为true后，控制台会打印出类似“535 Error: authentication failed”或“421 4.7.0 Too many connections”的信息，据此可判断是凭据问题还是频率限制。
对于批量发信，还要注意单账号的每日配额与每分钟速率。许多免费邮箱限制每天几百封，超出后服务器会拒绝。此时应在代码里做退避重试，并用独立队列削峰。以下Python示例展示了带重试的简单封装：
import smtplib
import time
from email.mime.text import MIMEText
def send_with_retry(to_addr, subject, body, max_retry=3):
msg = MIMEText(body, 'plain', 'utf-8')
msg['From'] = 'user@qq.com'
msg['To'] = to_addr
msg['Subject'] = subject
for i in range(max_retry):
try:
# 使用SSL端口465
with smtplib.SMTP_SSL('smtp.qq.com', 465) as server:
server.login('user@qq.com', '授权码填这里')
server.sendmail('user@qq.com', [to_addr], msg.as_string())
return True
except Exception as e:
print('第%d次失败: %s' % (i+1, e))
time.sleep(2 ** i)
return False
通过捕获异常类型，还能区分是SMTPAuthenticationError还是SMTPConnectError，分别导向认证排查与网络排查。生产环境建议把错误写入日志系统并告警，而不是仅打印到标准输出。只有把配置、认证、代码容错三者结合，才能彻底解决邮件发送失败的问题，保障业务通知链路稳定可靠。