网站安装完成后,找回密码、注册验证、订单通知、表单提醒等功能通常都需要发送邮件。不少后台会提供一组看起来相似的配置项:SMTP主机、安全协议、SMTP端口、SMTP账号、账号密码、发送账号和联系Email。

真正配置时,问题往往就出在这些字段之间。有人把邮箱地址填进SMTP主机,把普通登录密码直接当成SMTP密码,也有人认为“SMTP账号”“发送账号”“联系Email”必须是三个不同邮箱。

这些字段实际上属于三个不同层面:一部分负责连接邮件服务器,一部分负责证明“你有权使用这个邮箱发信”,还有一部分决定收件人最终看到谁在发邮件、应该联系谁。

配置网站邮件服务时,SMTP各字段应该怎么填写?

先看一封邮件怎么发出去

网站程序通常不会自己把邮件直接送到收件人的邮箱服务器,而是先把邮件提交给一个SMTP服务器。

一个常见流程是:

网站程序
↓
连接 SMTP 主机和端口
↓
建立 TLS 加密连接
↓
使用 SMTP 账号和密码认证
↓
提交邮件
↓
邮件服务商继续投递
↓
收件人邮箱

因此,后台出现的SMTP配置,本质上是在告诉程序三件事:去哪里连接、使用什么身份登录、最终以什么邮件身份发送。

SMTP主机

SMTP主机是负责接收网站发信请求的邮件服务器地址。

常见形式类似:

smtp.example.com
smtp.qq.com
smtp.gmail.com

具体地址由邮箱服务商提供,不同服务商不能互相套用。即使邮箱地址是admin@example.com,SMTP服务器也不一定就是smtp.example.com,仍应以邮箱服务商公布的配置为准。

SMTP主机也不是邮箱地址。

例如:

邮箱地址:admin@example.com
SMTP主机:smtp.example.com

前者代表一个邮箱身份,后者代表程序需要连接的服务器。

安全协议

安全协议决定网站程序连接SMTP服务器时,如何保护账号密码和邮件传输过程。

后台常见选项包括:

  • 无加密或None;

  • SSL;

  • TLS;

  • STARTTLS。

实际配置界面中的“SSL”通常对应连接建立后立即进行TLS握手,也就是常说的Implicit TLS;STARTTLS则是在建立SMTP连接后,再通过STARTTLS命令升级为加密连接。

对于邮件提交,现代配置应优先使用邮件服务商明确支持的加密方式,不建议为了让邮件暂时发送成功而随意关闭加密。

这里还存在一个常见误区:后台写的是“SSL”,并不一定意味着底层仍在使用已经淘汰的旧SSL协议。很多软件界面沿用“SSL”这个名称,实际建立的是现代TLS连接。

SMTP端口

SMTP端口必须与安全协议和邮件服务商的服务器配置匹配。

端口常见用途常见连接方式
465加密邮件提交连接建立时直接使用TLS
587客户端或应用提交邮件通常配合STARTTLS
25邮件服务器之间传递邮件主要用于SMTP Relay

587是标准的邮件提交端口之一,465则用于基于Implicit TLS的邮件提交。两种方式都被广泛使用,具体选择取决于邮箱服务商提供什么配置。

25端口更多用于邮件服务器之间转发邮件,而不是普通网站程序登录邮箱发信。部分云服务器、宽带网络和主机商还会限制25端口出站连接,以减少垃圾邮件发送。

因此,看到SMTP连接失败时,不应该简单把465、587和25轮流尝试。正确方法是同时确认主机、安全协议和端口,因为这三个参数需要成组匹配。

SMTP账号

SMTP账号是网站向邮件服务器进行身份认证时使用的账号。

很多邮箱服务要求填写完整邮箱地址:

notice@example.com

也有部分邮件系统只要求用户名:

notice

具体格式由邮箱服务商决定。

SMTP账号解决的是“谁正在登录服务器”的问题。只有认证成功,服务器才会判断这个账号是否有权限发送邮件。

在大多数普通邮箱场景中,SMTP账号就是用于发信的邮箱地址,但两者在概念上仍然不是同一个字段。

账号密码

这里填写的是SMTP认证所需的密码。

需要特别注意,它不一定等于网页登录邮箱时使用的登录密码。

越来越多邮件服务会把网页账户密码和第三方应用发信凭证分开。用户开启SMTP服务后,可能需要另外创建:

  • 授权码;

  • 应用专用密码;

  • SMTP密码;

  • API生成的邮件凭证。

例如后台要求:

SMTP账号:notice@example.com
账号密码:xxxxxxxxxxxxxxxx

第二项可能是邮件服务生成的一串授权码,而不是用户每天登录邮箱使用的密码。

直接填写网页登录密码,是网站SMTP配置失败的常见原因之一。

从安全角度看,也不应该把高权限主账号密码直接保存在网站数据库或明文配置文件中。邮箱服务支持独立授权码时,应优先使用权限更容易撤销和管理的专用凭证。

发送账号

“发送账号”这个名称没有SMTP主机和端口那样统一,不同网站程序对它的定义可能稍有不同。

多数情况下,它指邮件中的发件人地址,也就是收件人在邮件列表中看到的From地址。

例如:

SMTP账号:smtp-user@example.com
发送账号:notice@example.com

理论上,认证账号和发件地址属于两个不同概念,因此技术上可能不同。但实际邮件服务通常会限制发件人身份。

例如,一个SMTP账号可能只允许:

  • 使用自身邮箱地址发信;

  • 使用已经验证过的别名发信;

  • 使用经过认证的企业域名地址发信。

如果随意填写一个并未获得授权的发件地址,邮件服务器可能直接拒绝,也可能自动改写发件人,还有可能影响SPF、DKIM、DMARC等邮件身份验证结果。

因此,对于不确定的用户,最稳妥的初始配置通常是让SMTP账号和发送账号保持一致。

联系Email

“联系Email”更多是网站应用层面的字段,并不是SMTP协议本身规定的连接参数。

它可能有几种用途:

  • 作为网站管理员的联系邮箱;

  • 接收用户留言、表单和系统通知;

  • 作为邮件中的回复地址;

  • 显示在网站联系信息中;

  • 接收系统异常或业务提醒。

因此,联系Email不一定负责实际发送邮件。

例如一个企业网站可能这样设置:

SMTP账号:system@example.com
发送账号:notice@example.com
联系Email:service@example.com

system@example.com负责SMTP身份认证,notice@example.com作为系统通知发件地址,service@example.com则用于接收客户联系。

但不同CMS、商城系统和网站程序对“联系Email”的使用方式不同。部分程序可能直接把它作为Reply-To地址,也有程序只是把它展示在前台。因此,最终仍应结合当前软件的字段说明确认。

三个邮箱字段有什么区别

字段主要作用是否必须与其他字段一致
SMTP账号登录SMTP服务器进行身份认证由邮件服务商决定
发送账号作为邮件的发件人地址通常需要是认证账号或已授权地址
联系Email用于网站联系、回复或接收通知通常可以不同

对个人网站或小型博客来说,没有必要为了区分字段专门注册三个邮箱。完全可以使用同一个邮箱:

SMTP账号:admin@example.com
发送账号:admin@example.com
联系Email:admin@example.com

随着业务规模扩大,再根据用途拆分:

system@example.com   系统SMTP认证
notice@example.com   系统通知发件
service@example.com  客服联系
security@example.com 安全通知

这样可以让不同类型的邮件职责更加清楚。

一套配置示例

假设邮箱服务商给出的参数如下:

SMTP服务器:smtp.example.com
SMTP端口:465
加密方式:SSL/TLS
邮箱账号:notice@example.com
SMTP授权码:AbCd123456

网站后台可以对应填写:

SMTP 主机:smtp.example.com
安全协议:SSL/TLS
SMTP 端口:465
SMTP 账号:notice@example.com
账号密码:AbCd123456
发送账号:notice@example.com
联系Email:admin@example.com

另一家邮件服务如果要求587端口和STARTTLS,则应按其文档调整:

SMTP 主机:smtp.example.com
安全协议:STARTTLS
SMTP 端口:587
SMTP 账号:notice@example.com
账号密码:应用专用密码
发送账号:notice@example.com
联系Email:admin@example.com

不能因为其他教程使用465,就认为所有邮箱都应该选择465。

为什么测试邮件发不出去

SMTP配置完成后,常见错误通常集中在几个位置。

连接超时

通常先检查SMTP主机是否正确、DNS是否能够解析、服务器防火墙是否允许出站连接,以及主机商有没有限制对应SMTP端口。

TLS握手失败

常见原因是端口与安全协议不匹配。例如服务器要求465直接TLS,却在程序中配置成STARTTLS;或者587要求STARTTLS,客户端却按Implicit TLS建立连接。

认证失败

检查SMTP账号格式以及密码类型。邮箱服务要求授权码时,普通登录密码通常不能直接使用。

认证成功但拒绝发件

此时应重点检查“发送账号”。部分邮件服务不允许认证账号冒用其他From地址,只允许自身邮箱或经过验证的发件身份。

发送成功但收不到

这已经不一定是SMTP连接问题。邮件可能进入垃圾箱,也可能因为域名缺少SPF、DKIM、DMARC配置,或者发信信誉较低而被接收方过滤。

后台提示“发送成功”,通常只代表SMTP服务器已经接受邮件,并不等于最终一定进入收件人的收件箱。

企业邮箱还要看域名认证

对于使用自己域名发送邮件的网站,仅仅把SMTP账号密码配置正确还不够。

例如:

notice@example.com

邮件能否稳定送达,还可能与域名DNS中的邮件身份验证配置有关。

  • SPF:声明哪些服务器有权代表域名发送邮件;

  • DKIM:通过数字签名帮助接收方验证邮件内容和发件域名;

  • DMARC:规定SPF或DKIM验证失败时的处理策略,并提供报告机制。

这些记录并不是填写在网站SMTP设置里的参数,而是在域名DNS和邮件服务商后台配置。

对于注册验证码、订单通知和密码重置等重要邮件,只测试“能不能发送”是不够的,还应观察邮件是否进入垃圾箱、发件人是否显示正常,以及不同邮箱服务商的实际到达情况。

配置时注意凭证安全

SMTP密码通常具有直接发信权限。一旦泄露,攻击者可能利用邮箱发送垃圾邮件或钓鱼邮件,严重时还会影响整个域名的邮件信誉。

实际部署时,应尽量避免:

  • 把SMTP密码提交到公开Git仓库;

  • 把密码直接写进前端JavaScript;

  • 在网页错误信息中输出完整密码;

  • 多人长期共用高权限邮箱主密码;

  • 使用已经废弃但没有及时撤销的授权码。

服务器应用更适合通过环境变量、受保护的配置文件或密钥管理系统保存SMTP凭证。更换人员、服务器迁移或发现异常发信后,应及时撤销旧授权凭证。

参考资料

  1. IETF邮件提交协议RFC 6409

  2. IETF邮件TLS与465端口规范RFC 8314