邮箱验证怎么做才靠谱:从语法到域名 MX 的完整校验

我维护过一个三万人的发信名单,第一次群发退信率冲到 9%,发信服务直接给我降了信誉分。复盘下来,坏数据全是肉眼根本看不出的:name@gmail,com 的逗号、尾随的一个空格、还有人手抖把 gmail.com 打成 gmial.com。从那以后我养成习惯:任何名单进系统之前,先过一遍邮箱格式校验。这篇就把校验这件事拆清楚。

邮箱地址到底由哪几部分组成

一个合法邮箱地址被 @ 切成两段:@ 左边叫本地部分(local part),右边叫域名(domain)。RFC 5321 给出的硬性边界很明确:本地部分不超过 64 个字符,整个地址不超过 254 个字符。本地部分允许的字符比很多人以为的宽,除了字母数字,还包括 !#$%&'*/=?^_{|}~- 和英文句点,只是句点不能出现在开头、结尾,也不能连续两个。

域名这一段走的是 LDH 规则,也就是只允许字母(Letter)、数字(Digit)和连字符(Hyphen),且连字符不能在某一段的开头或结尾。最右边的 TLD(顶级域)按惯例要求全字母,所以 user@host.123 这种纯数字 TLD 会被判非法。

校验分三层:语法、域名规则、MX 记录

我习惯把邮箱校验理解成由浅到深的三层:

第一层是语法,检查 @ 的数量、本地部分和域名的字符与长度,这一层纯靠规则就能跑完,不需要联网。第二层是域名段规则,确认域名每一段符合 LDH、TLD 合法、没有结尾点。第三层才是 MX 记录查询,通过 DNS 看这个域名有没有配置邮件交换服务器,没有 MX 记录的域名收不了信。

前两层在浏览器里就能做完,第三层 MX 查询和更深的 SMTP RCPT TO 握手需要后端,因为浏览器开不了 TCP 套接字。所以纯前端工具能拦住的是退信里占大头的那部分:typo、临时邮箱、长度超标、粘贴坏字符。

常见错误长什么样:一组真实判例

下面这组输入是我从真实名单里截出来的,跑一遍邮箱格式校验,结果是这样:

输入                       判定        原因
li.lei@toolora.info        合法        语法 + 域名段都通过
you+report@gmail.com       合法        + 号是 subaddressing,合法
name@gmail,com             非法        逗号不是句点,域名段含非法字符
a@@b.com                   非法        出现两个 @
test@test                  非法        缺少 TLD,域名只有一段
john@gmail.com.            非法        域名结尾带点
hi@mailinator.com          合法但临时   语法合法,命中一次性邮箱黑名单

值得单独说的是最后两类。test@test 这种缺顶级域的,和多个 @ 的,是最高发的两种格式错误,通常来自表单没做前端校验或者从 Excel 复制时带进了脏字符。而 @mailinator.com 这种,语法挑不出毛病,它确实是个能收信的真邮箱,只是属于分钟级失效的临时邮箱,机器人拿它绕注册墙、刷试用额度。识别这类要靠域名黑名单,跟语法校验是两码事。

批量校验:清洗列表的正确姿势

单个邮箱用肉眼还能看,几千上万行就只能上工具了。我的流程是:把表格里那一列邮箱整列复制,粘进邮箱校验器,它会表格化逐行给出状态和原因,然后按状态排序,只导出合法行的 CSV。一份一万两千行的报名表,经常能筛掉五六百条坏地址,退信率就压到了 2% 以下。

如果你的源数据格式更乱,比如带着 : 分隔符的凭据 dump,或者一列里塞了好几个字段,先用 CSV 转 JSON 工具把结构理顺、把邮箱列单独抽出来,再喂给校验器,会省掉很多手工 trim 的功夫。这里有个反复踩的坑:从 Excel 直接粘的列经常带着看不见的尾随空格或逗号(a@b.com,),不先处理一遍,这些行会被判成格式错误,容易让人误以为是工具的问题。

语法合法,不等于这个邮箱真实存在

这是我最想强调的一点。ceo@yourcompany.com 可以通过上面所有的语法和域名检查,域名也确实配了 MX,但这个具体邮箱可能根本没人注册,发过去照样退信。语法校验只能证明地址"长得对",证明不了收件箱真实存在。

要确认邮箱可送达,必须做 DNS MX 查询加 SMTP RCPT TO 握手,这一步需要后端。务实的做法是分两步走:先用纯前端的邮箱格式校验把明显的坏数据筛掉,这一步免费、不上传、能解决 95% 以上的问题;剩下的合法子集再喂给 NeverBounce、ZeroBounce 这类付费深度验证服务。先过滤再深验,能省掉八成以上的付费验证额度,因为大批量名单里真正需要 SMTP 去敲的,只是过完前两层之后剩下的那一小部分。

顺带提一句,有人喜欢直接拿一个正则把邮箱校验糊弄过去。W3C HTML5 规范那个正则规范自己都注明"刻意违反 RFC 5322",它抓不到超长地址、本地部分连续点、域名结尾带点这些情况,而且只能给你一个 true/false,告诉不了你为什么挂。如果你想自己调试一段邮箱匹配的规则,可以拿正则测试器把边界用例一条条跑过,比凭感觉写靠谱得多。

Made by Toolora · Updated 2026-06-13