用 RFC 5322 做邮箱验证崩过的人才懂它的边界做用户中心那阵子新来的同事从 GitHub 上抄了一段“史上最强的邮箱正则”说是完全符合 RFC 5322 标准上线第二天投诉就来了一堆正常用户注册不了有人的邮箱里带加号有人的域名是刚注册的新顶级域还有人填的地址明明能用却被拦成非法格式。那段正则确实够“标准”但现实世界根本不按标准出牌。后来我把邮箱验证从“一条正则定生死”改成了“分层验证”从格式、域名、MX 记录到最终发送验证邮件每一层只解决自己的问题误杀率才真正降下来。这篇就聊一聊 RFC 5322 里到底写了什么、为什么网上那些“官方正则”不能直接抄、以及实战里邮箱验证到底应该怎么做。1. 先搞清楚RFC 5322 到底管的是什么1.1 地址结构只有三个部分RFC 5322 是定义互联网文本消息格式的标准邮件地址只是其中一节《Internet Message Format》里定义的内容它规定了邮件地址由 local-part、“”符号、domain 三部分组成即标准的userexample.com形态。local-part 就是 前面的部分domain 是 后面的部分。这个结构看起来简单但细则极其繁琐。RFC 5322 的地址语法递归定义了 atom、dot-atom、quoted-string、domain-literal 等一堆概念很多地址从语法上是合法的但实际使用者看到会以为填错了。举几个 RFC 5322 认为“合法”的地址例子John Smithexample.com metagexample.com a..bexample.com a.b.c.d.eexample.com example.org注意a..bexample.com连续点号在 RFC 5322 的 dot-atom 规则里其实是被禁止的但如果有引号包裹就是另一回事。规范解释起来很绕实战里我建议你只把 RFC 5322 当作“理解地址边界的参考书”而不是当作“验收标准”后面我会展开说。1.2 local-part 的字符边界RFC 5322 定义了所谓 atext 字符集合也就是不需要引号就能直接出现在 local-part 里的字符A-Z a-z 0-9 ! # $ % * - / ? ^ _ { | } ~再加上“点号”作为分隔符但点号不能出现在 local-part 的开头或结尾也不能连续出现。也就是说abc.defexample.com合法.abcexample.com不合法abc..defexample.com也不合法。还有一类被允许的是 quoted-string也就是用双引号包裹的字符串里面可以放空格、、点号等特殊字符例如hello worldexample.com。这类地址理论上是合法的但实际几乎没有邮件系统会处理这种地址我见过有老系统生成的通配地址会用这样的形式但它在当前的真实发送链路里非常少见。1.3 domain 部分和整体长度不是 RFC 5322 单独定的domain 部分同样支持点分格式也支持 IP 字面量例如user[192.168.1.1]这种写法在 RFC 5322 里是合法的但同样脱离现实场景。绝大多数情况下你只需要考虑标准的点分域名格式也就是各级标签由字母、数字、连字符组成标签不能以连字符开头或结尾整体不超过 253 个字符。长度限制这块容易被搞混。RFC 5322 本身并没有直接规定整个地址的总长度真正把长度限制定下来的是负责邮件传输的 RFC 5321它要求 local-part 最长 64 字节路径包括 两边最长 256 字节去掉尖括号等外围字符实际邮箱地址普遍按 254 个字符来算。这也解释了为什么很多校验库会直接把 254 作为地址总长度的上限。把这三小节总结成一句话RFC 5322 定义了一套“语法上什么是允许的”但它不会告诉你“现实中哪些地址能收信”。搞清楚这一点后面很多坑就都能理解了。2. 为什么“网上流传的 RFC 5322 正则”不能直接用2.1 那条正则的来历网上搜索“RFC 5322 email regex”会找到一份被各种博客转烂了的超长正则英文版来自 EmailRegex.com用 JavaScript 写的长度一百多行。它宣称“根据 RFC 5322 官方语法”实际上是把 RFC 5322 的 ABNF 语法机械转写成了正则逻辑上挑不出语法毛病但工程上是灾难。我见过有人拿着这条正则往注册接口里一贴就上线了结果所有带特定合法字符的地址全部被拒。更讽刺的是真正发信的时候用户那边用的可能是企业邮箱、云服务商、自建邮件系统大家对地址的宽容程度完全不一样。邮件的真实流通靠的不是“符合 RFC 5322”而是“发送方按规范发、接收方愿意收”。标准是描述性的不是强制性的。接收方对格式的检查策略千差万别不能用一条“最严格”的正则去帮所有接收方做决定。2.2 现实中的接收方到底有多“不标准”用一个对比感受一下地址类型RFC 5322GmailQQ 邮箱部分老式企业网关usertagexample.com合法常见可用部分阻止可能拒绝quoted stringexample.com合法少见拒绝拒绝userexample.car合法可用可用可能拒绝userlocalhost不完整不可用不可用不可用注意usertagexample.com加号地址在 Gmail 体系里是核心功能很多人用姓名应用名gmail.com来管理订阅邮件。但有些系统只允许字母、数字、点、下划线遇到加号就报“邮箱格式错误”。这种情况下用户的邮箱其实真实存在是校验规则把它挡在了门外。再说引号地址。RFC 5322 明确允许 local-part 带引号但 Gmail 这样的主流服务基本不给你发这种地址的机会注册环节也不会让你填成这种格式。如果直接用完整标准去校验你等于是在给用户设置现实中根本不存在的门槛。2.3 格式对了邮箱也未必存在比正则误杀更隐蔽的问题是“假阳性”校验通过不代表这个邮箱真实存在、能收信。用户手滑把example.com写成exampel.com格式完全合法正则验不出用户填了一个已经注销的旧邮箱格式也合法正则同样验不出用户随便编了一个no-such-userexample.com格式合法你的系统照样认为“验证通过”。格式校验只能告诉你“这个字符串长得像不像一个邮箱地址”真正的验证需要后面几层来补。这也是我建议所有做用户体系的团队不要抱着一条标准正则不放的原因格式校验要做的只是“过滤掉明显不是邮箱的输入”剩下的工作交给其他手段。3. 实战里的四层邮箱验证方案下面是我在实际项目中收敛出来的一套做法从浅到深一共四层你完全可以按需裁剪。3.1 第一层语法校验用“拆分法”代替超长正则不要再去搜那种一百多行的正则了把任务拆成三步反而更好维护整个地址去除首尾空格后必须恰好包含一个 且 不在开头和结尾。local-part 和 domain 两部分分别做规则校验。local-part 长度不超过 64总长度不超过 254。一个偏保守、适合大多数业务场景的 Java 示例public class EmailSyntaxValidator { private static final int MAX_LOCAL_PART_LENGTH 64; private static final int MAX_ADDRESS_LENGTH 254; // 本地部分字母数字和常见合法特殊字符点号不允许连续或首尾 private static final Pattern LOCAL_PART_PATTERN Pattern.compile(^[A-Za-z0-9!#$%*/?^_{|}~-] (\\.[A-Za-z0-9!#$%*/?^_{|}~-])*$); // 域名部分标准点分域名不校验顶级域是否真实存在 private static final Pattern DOMAIN_PATTERN Pattern.compile(^(?.{1,253}$)(?!-) [A-Za-z0-9-]{1,63}(?!-) (\\.[A-Za-z0-9-]{1,63}(?!-))*$); public static boolean isValid(String email) { if (email null || email.isEmpty()) { return false; } String trimmed email.trim(); if (trimmed.length() MAX_ADDRESS_LENGTH) { return false; } int atIndex trimmed.indexOf(); if (atIndex 0 || atIndex ! trimmed.lastIndexOf()) { return false; } String localPart trimmed.substring(0, atIndex); String domain trimmed.substring(atIndex 1); if (localPart.length() MAX_LOCAL_PART_LENGTH) { return false; } return LOCAL_PART_PATTERN.matcher(localPart).matches() DOMAIN_PATTERN.matcher(domain).matches(); } }这段代码刻意把校验范围限制在“常见合法地址”之内而不是完整 RFC 5322原因前面说过完整标准会把大量现实可用的地址拦在外面。如果你想用现成库Java 的javax.mail.internet.InternetAddress自带了一个相对平衡的校验Python 可以用email.utils.parseaddr加手工判断JavaScript 则可以用 validator.js 的isEmail它默认就比较贴近现实使用场景。3.2 第二层域名与 MX 记录校验语法通过之后下一步是检查域名是否存在、有没有配置邮件交换记录也就是 MX 记录。MX 记录是 DNS 里用来指示“哪个邮件服务器负责接收这个域名的邮件”的记录。查询 MX 记录可以过滤掉一大半随手乱填的地址因为正常邮箱域名的 MX 记录几乎都存在而abcdefghijklmno.com这种瞎编域名通常查不到任何记录。在 Linux 环境下先用命令行验证一下# 查看 example.com 的 MX 记录 dig example.com MX short # 也可以直接指定 DNS 服务器 nslookup -typemx example.com 8.8.8.8用 Java 的话可以借助 dnsjava 库或者直接调用系统命令解析一个基于 dnsjava 的参考实现import org.xbill.DNS.*; public class MxLookup { public static ListString getMxRecords(String domain) { ListString records new ArrayList(); try { Record[] response new Lookup(domain, Type.MX).run(); if (response ! null) { for (Record r : response) { MXRecord mx (MXRecord) r; records.add(mx.getPriority() mx.getTarget()); } } } catch (Exception e) { // 域名不存在或 DNS 解析异常 } return records; } }实际落地时有个细节容易踩坑一个域名没有 MX 记录不代表它不收邮件。RFC 5321 规定如果 MX 记录不存在发送方可以回退到域名的 A/AAAA 记录直接尝试把邮件投递到主机本身。所以查询顺序建议是先查 MX有记录就继续没查到 MX 再查 A 记录A 记录也没有才判定为“该域名不可收信”。另外建议对 MX 查询结果做“等待重试”因为 DNS 偶发超时很常见一次失败就直接判“无法收信”会误伤刚部署完 DNS 的新用户。实测中我会在发验证邮件时做 2 次查询重试每次间隔 1 秒。3.3 第三层SMTP RCPT 探测能不用就别用有的团队想让体验再进一步在用户点击“发送验证码”之前就先跟对方邮件服务器握手确认这个邮箱到底存不存在。原理是连接到域名的 MX 服务器模拟发信动作但不下发邮件正文只发一条RCPT TO根据响应码判断邮箱是否存在。一次典型的 SMTP 探测交互长这样C: HELO verify.example.com S: 250 mx.example.com C: MAIL FROM:noreplyverify.example.com S: 250 2.1.0 Ok C: RCPT TO:real-userexample.com S: 250 2.1.5 Ok C: QUIT S: 221 2.0.0 Bye如果返回 250说明该邮箱很可能存在返回 550说明不存在返回 452说明服务器忙暂时无法验证。Java 里可以用 Socket 模拟这个过程也可以用 Spring 的JavaMailSender配合自定义 Transport 实现但我不建议把它做成用户注册流程里的必备环节。原因有三个第一很多邮件服务商对无认证的RCPT TO探测都做了防护统一返回 550 或者对陌生 IP 直接拒绝连接结果会大量误判。尤其是一些大型企业邮箱你从云服务器 IP 去探测几乎得不到真实答案。第二邮件服务器的RCPT TO响应不一定是实时的很多反垃圾网关启用灰名单机制第一次来自陌生 IP 的连接会返回 451/452要过几分钟重试才给真实结果作为实时校验手段根本等不起。第三频繁探测容易让对方把你所在 IP 的邮件全部加入黑名单你这验证还没做完以后正常发信都被对方拒收。我的建议是这种探测可以用在“审核用户提交的邮箱是否存在”的低频后台任务里绝不要放在注册接口的同步链路上。而且一定要设置短超时连接 5 秒、读响应 5 秒整体控制在 10 秒以内并限制单 IP 每天探测次数。3.4 第四层发送验证邮件它才是最终结论前三层做完剩下的就交给邮件本身。给用户邮箱发送一封带一次性验证码或验证链接的邮件用户收到并点击或填写验证码才说明这个邮箱真实可用。这一层的核心不是正则而是业务逻辑。验证码有效期建议 10-30 分钟一次性使用失败次数限制在 5 次以内防止暴力枚举。验证链接不要拼接明文邮箱地址应该用 token 关联用户 ID 和邮箱整个 token 加上过期时间和使用次数限制。同时要处理好防刷逻辑同一个 IP 对同一个邮箱每天最多发几次同一个邮箱全局也限制次数不然你的邮件就会被对方邮件服务商判定为垃圾邮件源最后连正常用户都收到不验证邮件。发信这块建议不要直接用业务机房 IP 直发先用云厂商的邮件推送服务或者专业 SaaS 平台比如阿里云邮件推送、腾讯云 SES、SendGrid、Mailgun它们的域名信誉和退信处理机制比自己搭建 Postfix 靠谱得多。使用第三方服务时发信域名必须配置好 SPF、DKIM、DMARC 三条 DNS 记录不然高概率进垃圾箱。用 Spring Boot 发送验证邮件的简化示例Service public class EmailService { Autowired private JavaMailSender mailSender; Value(${app.baseUrl}) private String baseUrl; public void sendVerificationCode(String to, String code) { SimpleMailMessage message new SimpleMailMessage(); message.setFrom(noreplyyourdomain.com); message.setTo(to); message.setSubject(验证码); message.setText(您的验证码是 code 10分钟内有效。); mailSender.send(message); } }这层方案看起来最笨却是整个验证链条里唯一真正可靠的一环。格式校验再严格也不如让用户亲自点一下邮件里的链接因为最终用户能不能收到邮件覆盖了他填写的地址格式对不对、域名收不收信、收信服务器有没有把他识别为垃圾邮件等所有问题。4. 高频踩坑场景与排查实录4.1 加号地址和带点地址被误杀这是格式校验最典型的坑。usertagexample.com在 RFC 5322 里合法在 Gmail 里是官方功能但很多初版校验规则只允许字母/数字/._-于是误杀大量用户。处理方式可以灵活一些格式规则尽量放宽只要没有明显非法字符、有一个 、 两侧非空、总长度合理就放行。真正的风控需求放在防刷策略里而不是靠这层卡用户。4.2 临时邮箱和一次性邮箱的处理格式正确、域名有 MX、甚至 SMTP 探测也通过但用户填的是一次性邮箱服务商的地址这种用于收验证码后即弃的邮箱适合做广告注册不适合做真实用户体系。处理临时邮箱的常见手段是维护一个临时邮箱域名黑名单网上有现成的开源列表比如 disposable-email-domains每隔一段时间同步一次。但黑名单永远有不全的时候更可靠的是结合行为特征验证码发送后短时间内未验证、注册信息质量低、常用 IP 段异常等综合判断后进入人工审核池。4.3 国际化邮箱和 IDN 域名非 ASCII 的邮箱地址是存在的比如中文域名邮箱或带 UTF-8 字符的邮件地址传输入靠 SMTPUTF8 扩展这给校验规则带来了新的复杂度。如果你的产品面向国内用户基本用不到非 ASCII 邮箱我建议在语法这一层直接按 ASCII 规则走发现非 ASCII 字符就提示“暂不支持该邮箱格式”对绝大多数用户来说体验反而是平滑的。4.4 开发和测试环境收不到验证邮件本地开发时把验证邮件真正发出去很痛苦尤其是反复调试验证码功能的时候。比较稳的做法是三种方案适用场景说明控制台打印验证码本地开发Spring Boot 里占位发送日志里直接打出来MailHog/Mailpit本地开发本地起假 SMTP邮件进 Web 界面Mailtrap联调测试真实 SMTP 发送进沙箱收件箱我在本地开发时用 Mailpit一条 Docker 命令就能起来docker run -d --name mailpit -p 1025:1025 -p 8025:8025 axllent/mailpit然后把配置文件里的 SMTP 地址改成 localhost:1025打开 http://localhost:8025 就能看到所有发出的邮件验证码一目了然调试效率比真发邮件高得多。4.5 用户常见的“看起来像输错了”的地址实战里还有一种情况经常被忽略用户其实没有输错他填的是gmal.com、qq.com少个数字等非常接近真实域名但实际不存在的地址。这类通过语法和域名查询能查出来没 MX 记录但对用户来说他并不知道自己敲错了。处理建议是不要用“格式错误”这种模糊提示。当地址语法合法但域名查不到 MX 时可以提示“请检查域名是否输入正确”或者在确认界面高亮显示用户输入的整体地址让他确认。还有一种做法是在用户输入完后做一次域名相似度对比如果和 Gmail、QQ 邮箱等主流域名高度相似但又不完全一样弹出确认提示。这个功能做了之后我见过的用户找回成功率明显上升。5. 几个我会一直保留的校验原则把上面所有内容收敛一下我实际遵循的就三条。第一正则只做粗滤。它的职责是把abc、12345、a bc这种明显不是邮箱的输入拦下来不是为了证明这个邮箱 100% 可用。规则往宽了写别怕放过什么奇怪格式后面有更严格的手段兜底。第二每多一层校验就会多一批误杀所以能不用就不用。格式、域名、MX 记录这些查询类校验误杀相对可控SMTP 探测这种实时协商类校验务必放到非同步的低频场景里最终以验证邮件是否送达为唯一权威结论。第三错误提示要比校验规则更友好。用户填gmal.com系统冷冰冰地提示“邮箱格式错误”他不会认为是自己填错了只会觉得你的系统垃圾。把“疑似域名输错”“域名不存在”“收不到验证邮件”区分开分别给出不同提示和引导用户的流失率能低很多。我在实际项目里就遇到过把域名 MX 检查设为硬门槛结果某高校自建邮箱系统因为 DNS 配置特殊大量真实邮箱被拦后来改成“MX 检查失败时提示风险但不阻断”注册成功率立刻恢复。邮箱验证做得好不好永远不是看你校验得多严格而是看你在真正干扰用户之前为这次校验付出了多少精准度。最后再分享一个小技巧每次改动校验规则都要把样本集先过一遍。我会从线上拉一批已经注册成功的用户邮箱再准备一批明显非法的测试邮箱改完规则后先夹具验证确保线上真实用户没有被误杀再去调整接口逻辑。邮箱验证这件事宁可放进来再通过验证邮件筛掉也不要让合法用户连注册的入口都看不到。
邮箱验证实战：从RFC 5322边界到四层校验方案
用 RFC 5322 做邮箱验证崩过的人才懂它的边界做用户中心那阵子新来的同事从 GitHub 上抄了一段“史上最强的邮箱正则”说是完全符合 RFC 5322 标准上线第二天投诉就来了一堆正常用户注册不了有人的邮箱里带加号有人的域名是刚注册的新顶级域还有人填的地址明明能用却被拦成非法格式。那段正则确实够“标准”但现实世界根本不按标准出牌。后来我把邮箱验证从“一条正则定生死”改成了“分层验证”从格式、域名、MX 记录到最终发送验证邮件每一层只解决自己的问题误杀率才真正降下来。这篇就聊一聊 RFC 5322 里到底写了什么、为什么网上那些“官方正则”不能直接抄、以及实战里邮箱验证到底应该怎么做。1. 先搞清楚RFC 5322 到底管的是什么1.1 地址结构只有三个部分RFC 5322 是定义互联网文本消息格式的标准邮件地址只是其中一节《Internet Message Format》里定义的内容它规定了邮件地址由 local-part、“”符号、domain 三部分组成即标准的userexample.com形态。local-part 就是 前面的部分domain 是 后面的部分。这个结构看起来简单但细则极其繁琐。RFC 5322 的地址语法递归定义了 atom、dot-atom、quoted-string、domain-literal 等一堆概念很多地址从语法上是合法的但实际使用者看到会以为填错了。举几个 RFC 5322 认为“合法”的地址例子John Smithexample.com metagexample.com a..bexample.com a.b.c.d.eexample.com example.org注意a..bexample.com连续点号在 RFC 5322 的 dot-atom 规则里其实是被禁止的但如果有引号包裹就是另一回事。规范解释起来很绕实战里我建议你只把 RFC 5322 当作“理解地址边界的参考书”而不是当作“验收标准”后面我会展开说。1.2 local-part 的字符边界RFC 5322 定义了所谓 atext 字符集合也就是不需要引号就能直接出现在 local-part 里的字符A-Z a-z 0-9 ! # $ % * - / ? ^ _ { | } ~再加上“点号”作为分隔符但点号不能出现在 local-part 的开头或结尾也不能连续出现。也就是说abc.defexample.com合法.abcexample.com不合法abc..defexample.com也不合法。还有一类被允许的是 quoted-string也就是用双引号包裹的字符串里面可以放空格、、点号等特殊字符例如hello worldexample.com。这类地址理论上是合法的但实际几乎没有邮件系统会处理这种地址我见过有老系统生成的通配地址会用这样的形式但它在当前的真实发送链路里非常少见。1.3 domain 部分和整体长度不是 RFC 5322 单独定的domain 部分同样支持点分格式也支持 IP 字面量例如user[192.168.1.1]这种写法在 RFC 5322 里是合法的但同样脱离现实场景。绝大多数情况下你只需要考虑标准的点分域名格式也就是各级标签由字母、数字、连字符组成标签不能以连字符开头或结尾整体不超过 253 个字符。长度限制这块容易被搞混。RFC 5322 本身并没有直接规定整个地址的总长度真正把长度限制定下来的是负责邮件传输的 RFC 5321它要求 local-part 最长 64 字节路径包括 两边最长 256 字节去掉尖括号等外围字符实际邮箱地址普遍按 254 个字符来算。这也解释了为什么很多校验库会直接把 254 作为地址总长度的上限。把这三小节总结成一句话RFC 5322 定义了一套“语法上什么是允许的”但它不会告诉你“现实中哪些地址能收信”。搞清楚这一点后面很多坑就都能理解了。2. 为什么“网上流传的 RFC 5322 正则”不能直接用2.1 那条正则的来历网上搜索“RFC 5322 email regex”会找到一份被各种博客转烂了的超长正则英文版来自 EmailRegex.com用 JavaScript 写的长度一百多行。它宣称“根据 RFC 5322 官方语法”实际上是把 RFC 5322 的 ABNF 语法机械转写成了正则逻辑上挑不出语法毛病但工程上是灾难。我见过有人拿着这条正则往注册接口里一贴就上线了结果所有带特定合法字符的地址全部被拒。更讽刺的是真正发信的时候用户那边用的可能是企业邮箱、云服务商、自建邮件系统大家对地址的宽容程度完全不一样。邮件的真实流通靠的不是“符合 RFC 5322”而是“发送方按规范发、接收方愿意收”。标准是描述性的不是强制性的。接收方对格式的检查策略千差万别不能用一条“最严格”的正则去帮所有接收方做决定。2.2 现实中的接收方到底有多“不标准”用一个对比感受一下地址类型RFC 5322GmailQQ 邮箱部分老式企业网关usertagexample.com合法常见可用部分阻止可能拒绝quoted stringexample.com合法少见拒绝拒绝userexample.car合法可用可用可能拒绝userlocalhost不完整不可用不可用不可用注意usertagexample.com加号地址在 Gmail 体系里是核心功能很多人用姓名应用名gmail.com来管理订阅邮件。但有些系统只允许字母、数字、点、下划线遇到加号就报“邮箱格式错误”。这种情况下用户的邮箱其实真实存在是校验规则把它挡在了门外。再说引号地址。RFC 5322 明确允许 local-part 带引号但 Gmail 这样的主流服务基本不给你发这种地址的机会注册环节也不会让你填成这种格式。如果直接用完整标准去校验你等于是在给用户设置现实中根本不存在的门槛。2.3 格式对了邮箱也未必存在比正则误杀更隐蔽的问题是“假阳性”校验通过不代表这个邮箱真实存在、能收信。用户手滑把example.com写成exampel.com格式完全合法正则验不出用户填了一个已经注销的旧邮箱格式也合法正则同样验不出用户随便编了一个no-such-userexample.com格式合法你的系统照样认为“验证通过”。格式校验只能告诉你“这个字符串长得像不像一个邮箱地址”真正的验证需要后面几层来补。这也是我建议所有做用户体系的团队不要抱着一条标准正则不放的原因格式校验要做的只是“过滤掉明显不是邮箱的输入”剩下的工作交给其他手段。3. 实战里的四层邮箱验证方案下面是我在实际项目中收敛出来的一套做法从浅到深一共四层你完全可以按需裁剪。3.1 第一层语法校验用“拆分法”代替超长正则不要再去搜那种一百多行的正则了把任务拆成三步反而更好维护整个地址去除首尾空格后必须恰好包含一个 且 不在开头和结尾。local-part 和 domain 两部分分别做规则校验。local-part 长度不超过 64总长度不超过 254。一个偏保守、适合大多数业务场景的 Java 示例public class EmailSyntaxValidator { private static final int MAX_LOCAL_PART_LENGTH 64; private static final int MAX_ADDRESS_LENGTH 254; // 本地部分字母数字和常见合法特殊字符点号不允许连续或首尾 private static final Pattern LOCAL_PART_PATTERN Pattern.compile(^[A-Za-z0-9!#$%*/?^_{|}~-] (\\.[A-Za-z0-9!#$%*/?^_{|}~-])*$); // 域名部分标准点分域名不校验顶级域是否真实存在 private static final Pattern DOMAIN_PATTERN Pattern.compile(^(?.{1,253}$)(?!-) [A-Za-z0-9-]{1,63}(?!-) (\\.[A-Za-z0-9-]{1,63}(?!-))*$); public static boolean isValid(String email) { if (email null || email.isEmpty()) { return false; } String trimmed email.trim(); if (trimmed.length() MAX_ADDRESS_LENGTH) { return false; } int atIndex trimmed.indexOf(); if (atIndex 0 || atIndex ! trimmed.lastIndexOf()) { return false; } String localPart trimmed.substring(0, atIndex); String domain trimmed.substring(atIndex 1); if (localPart.length() MAX_LOCAL_PART_LENGTH) { return false; } return LOCAL_PART_PATTERN.matcher(localPart).matches() DOMAIN_PATTERN.matcher(domain).matches(); } }这段代码刻意把校验范围限制在“常见合法地址”之内而不是完整 RFC 5322原因前面说过完整标准会把大量现实可用的地址拦在外面。如果你想用现成库Java 的javax.mail.internet.InternetAddress自带了一个相对平衡的校验Python 可以用email.utils.parseaddr加手工判断JavaScript 则可以用 validator.js 的isEmail它默认就比较贴近现实使用场景。3.2 第二层域名与 MX 记录校验语法通过之后下一步是检查域名是否存在、有没有配置邮件交换记录也就是 MX 记录。MX 记录是 DNS 里用来指示“哪个邮件服务器负责接收这个域名的邮件”的记录。查询 MX 记录可以过滤掉一大半随手乱填的地址因为正常邮箱域名的 MX 记录几乎都存在而abcdefghijklmno.com这种瞎编域名通常查不到任何记录。在 Linux 环境下先用命令行验证一下# 查看 example.com 的 MX 记录 dig example.com MX short # 也可以直接指定 DNS 服务器 nslookup -typemx example.com 8.8.8.8用 Java 的话可以借助 dnsjava 库或者直接调用系统命令解析一个基于 dnsjava 的参考实现import org.xbill.DNS.*; public class MxLookup { public static ListString getMxRecords(String domain) { ListString records new ArrayList(); try { Record[] response new Lookup(domain, Type.MX).run(); if (response ! null) { for (Record r : response) { MXRecord mx (MXRecord) r; records.add(mx.getPriority() mx.getTarget()); } } } catch (Exception e) { // 域名不存在或 DNS 解析异常 } return records; } }实际落地时有个细节容易踩坑一个域名没有 MX 记录不代表它不收邮件。RFC 5321 规定如果 MX 记录不存在发送方可以回退到域名的 A/AAAA 记录直接尝试把邮件投递到主机本身。所以查询顺序建议是先查 MX有记录就继续没查到 MX 再查 A 记录A 记录也没有才判定为“该域名不可收信”。另外建议对 MX 查询结果做“等待重试”因为 DNS 偶发超时很常见一次失败就直接判“无法收信”会误伤刚部署完 DNS 的新用户。实测中我会在发验证邮件时做 2 次查询重试每次间隔 1 秒。3.3 第三层SMTP RCPT 探测能不用就别用有的团队想让体验再进一步在用户点击“发送验证码”之前就先跟对方邮件服务器握手确认这个邮箱到底存不存在。原理是连接到域名的 MX 服务器模拟发信动作但不下发邮件正文只发一条RCPT TO根据响应码判断邮箱是否存在。一次典型的 SMTP 探测交互长这样C: HELO verify.example.com S: 250 mx.example.com C: MAIL FROM:noreplyverify.example.com S: 250 2.1.0 Ok C: RCPT TO:real-userexample.com S: 250 2.1.5 Ok C: QUIT S: 221 2.0.0 Bye如果返回 250说明该邮箱很可能存在返回 550说明不存在返回 452说明服务器忙暂时无法验证。Java 里可以用 Socket 模拟这个过程也可以用 Spring 的JavaMailSender配合自定义 Transport 实现但我不建议把它做成用户注册流程里的必备环节。原因有三个第一很多邮件服务商对无认证的RCPT TO探测都做了防护统一返回 550 或者对陌生 IP 直接拒绝连接结果会大量误判。尤其是一些大型企业邮箱你从云服务器 IP 去探测几乎得不到真实答案。第二邮件服务器的RCPT TO响应不一定是实时的很多反垃圾网关启用灰名单机制第一次来自陌生 IP 的连接会返回 451/452要过几分钟重试才给真实结果作为实时校验手段根本等不起。第三频繁探测容易让对方把你所在 IP 的邮件全部加入黑名单你这验证还没做完以后正常发信都被对方拒收。我的建议是这种探测可以用在“审核用户提交的邮箱是否存在”的低频后台任务里绝不要放在注册接口的同步链路上。而且一定要设置短超时连接 5 秒、读响应 5 秒整体控制在 10 秒以内并限制单 IP 每天探测次数。3.4 第四层发送验证邮件它才是最终结论前三层做完剩下的就交给邮件本身。给用户邮箱发送一封带一次性验证码或验证链接的邮件用户收到并点击或填写验证码才说明这个邮箱真实可用。这一层的核心不是正则而是业务逻辑。验证码有效期建议 10-30 分钟一次性使用失败次数限制在 5 次以内防止暴力枚举。验证链接不要拼接明文邮箱地址应该用 token 关联用户 ID 和邮箱整个 token 加上过期时间和使用次数限制。同时要处理好防刷逻辑同一个 IP 对同一个邮箱每天最多发几次同一个邮箱全局也限制次数不然你的邮件就会被对方邮件服务商判定为垃圾邮件源最后连正常用户都收到不验证邮件。发信这块建议不要直接用业务机房 IP 直发先用云厂商的邮件推送服务或者专业 SaaS 平台比如阿里云邮件推送、腾讯云 SES、SendGrid、Mailgun它们的域名信誉和退信处理机制比自己搭建 Postfix 靠谱得多。使用第三方服务时发信域名必须配置好 SPF、DKIM、DMARC 三条 DNS 记录不然高概率进垃圾箱。用 Spring Boot 发送验证邮件的简化示例Service public class EmailService { Autowired private JavaMailSender mailSender; Value(${app.baseUrl}) private String baseUrl; public void sendVerificationCode(String to, String code) { SimpleMailMessage message new SimpleMailMessage(); message.setFrom(noreplyyourdomain.com); message.setTo(to); message.setSubject(验证码); message.setText(您的验证码是 code 10分钟内有效。); mailSender.send(message); } }这层方案看起来最笨却是整个验证链条里唯一真正可靠的一环。格式校验再严格也不如让用户亲自点一下邮件里的链接因为最终用户能不能收到邮件覆盖了他填写的地址格式对不对、域名收不收信、收信服务器有没有把他识别为垃圾邮件等所有问题。4. 高频踩坑场景与排查实录4.1 加号地址和带点地址被误杀这是格式校验最典型的坑。usertagexample.com在 RFC 5322 里合法在 Gmail 里是官方功能但很多初版校验规则只允许字母/数字/._-于是误杀大量用户。处理方式可以灵活一些格式规则尽量放宽只要没有明显非法字符、有一个 、 两侧非空、总长度合理就放行。真正的风控需求放在防刷策略里而不是靠这层卡用户。4.2 临时邮箱和一次性邮箱的处理格式正确、域名有 MX、甚至 SMTP 探测也通过但用户填的是一次性邮箱服务商的地址这种用于收验证码后即弃的邮箱适合做广告注册不适合做真实用户体系。处理临时邮箱的常见手段是维护一个临时邮箱域名黑名单网上有现成的开源列表比如 disposable-email-domains每隔一段时间同步一次。但黑名单永远有不全的时候更可靠的是结合行为特征验证码发送后短时间内未验证、注册信息质量低、常用 IP 段异常等综合判断后进入人工审核池。4.3 国际化邮箱和 IDN 域名非 ASCII 的邮箱地址是存在的比如中文域名邮箱或带 UTF-8 字符的邮件地址传输入靠 SMTPUTF8 扩展这给校验规则带来了新的复杂度。如果你的产品面向国内用户基本用不到非 ASCII 邮箱我建议在语法这一层直接按 ASCII 规则走发现非 ASCII 字符就提示“暂不支持该邮箱格式”对绝大多数用户来说体验反而是平滑的。4.4 开发和测试环境收不到验证邮件本地开发时把验证邮件真正发出去很痛苦尤其是反复调试验证码功能的时候。比较稳的做法是三种方案适用场景说明控制台打印验证码本地开发Spring Boot 里占位发送日志里直接打出来MailHog/Mailpit本地开发本地起假 SMTP邮件进 Web 界面Mailtrap联调测试真实 SMTP 发送进沙箱收件箱我在本地开发时用 Mailpit一条 Docker 命令就能起来docker run -d --name mailpit -p 1025:1025 -p 8025:8025 axllent/mailpit然后把配置文件里的 SMTP 地址改成 localhost:1025打开 http://localhost:8025 就能看到所有发出的邮件验证码一目了然调试效率比真发邮件高得多。4.5 用户常见的“看起来像输错了”的地址实战里还有一种情况经常被忽略用户其实没有输错他填的是gmal.com、qq.com少个数字等非常接近真实域名但实际不存在的地址。这类通过语法和域名查询能查出来没 MX 记录但对用户来说他并不知道自己敲错了。处理建议是不要用“格式错误”这种模糊提示。当地址语法合法但域名查不到 MX 时可以提示“请检查域名是否输入正确”或者在确认界面高亮显示用户输入的整体地址让他确认。还有一种做法是在用户输入完后做一次域名相似度对比如果和 Gmail、QQ 邮箱等主流域名高度相似但又不完全一样弹出确认提示。这个功能做了之后我见过的用户找回成功率明显上升。5. 几个我会一直保留的校验原则把上面所有内容收敛一下我实际遵循的就三条。第一正则只做粗滤。它的职责是把abc、12345、a bc这种明显不是邮箱的输入拦下来不是为了证明这个邮箱 100% 可用。规则往宽了写别怕放过什么奇怪格式后面有更严格的手段兜底。第二每多一层校验就会多一批误杀所以能不用就不用。格式、域名、MX 记录这些查询类校验误杀相对可控SMTP 探测这种实时协商类校验务必放到非同步的低频场景里最终以验证邮件是否送达为唯一权威结论。第三错误提示要比校验规则更友好。用户填gmal.com系统冷冰冰地提示“邮箱格式错误”他不会认为是自己填错了只会觉得你的系统垃圾。把“疑似域名输错”“域名不存在”“收不到验证邮件”区分开分别给出不同提示和引导用户的流失率能低很多。我在实际项目里就遇到过把域名 MX 检查设为硬门槛结果某高校自建邮箱系统因为 DNS 配置特殊大量真实邮箱被拦后来改成“MX 检查失败时提示风险但不阻断”注册成功率立刻恢复。邮箱验证做得好不好永远不是看你校验得多严格而是看你在真正干扰用户之前为这次校验付出了多少精准度。最后再分享一个小技巧每次改动校验规则都要把样本集先过一遍。我会从线上拉一批已经注册成功的用户邮箱再准备一批明显非法的测试邮箱改完规则后先夹具验证确保线上真实用户没有被误杀再去调整接口逻辑。邮箱验证这件事宁可放进来再通过验证邮件筛掉也不要让合法用户连注册的入口都看不到。