1. 邮箱格式验证到底在验什么先啃下RFC 5322这段语法先说一个我自己的真实经历。早几年做用户注册模块邮箱验证正则用的是网上流传最广的那条经典款^[a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,}$。当时觉得挺稳直到有一天一个用户提交了usertagexample.co正则可以过后来又有人提交quoted stringexample.com直接被拦在门外。我去跟同事争论“带引号的邮箱到底合不合法”谁也说服不了谁最后翻到RFC 5322原文才意识到我们一直在用一条“看着差不多”的正则冒充标准而真正该做的是理解邮箱地址的语法树。1.1 地址语法addr-spec到底长什么样RFC 5322Internet Message Format是定义邮件消息格式的基础文档里面关于邮箱地址的核心定义是addr-spec也就是我们常说的“形如local-partdomain的完整邮箱地址”。用语法树表示大致是这样addr-spec local-part domain local-part dot-atom / quoted-string / obs-local-part domain dot-atom / domain-literal / obs-domain注意一个关键点local-part并不是只有“字母数字加点号”这一种形态标准语法里它是dot-atom或quoted-string二选一。很多开发者的第一道坑就出在这里正则只覆盖了dot-atom里最普通的那一部分遇到quoted-string就直接误杀。而obs-local-part和obs-domain是RFC 5322为了兼容老协议保留的“过时语法”实际开发中不建议支持这里先不展开。domain部分同样不只是普通域名还有一种domain-literal写法即用方括号包起来的IP地址字面量例如user[192.168.1.1]。这类地址在现实中几乎见不到但标准确实允许。你可能会想这些边界案例支持了又有什么用我的观点是格式校验的目标不是“允许尽可能多”而是在“遵循标准”和“贴合业务”之间找平衡。标准规定要明白但业务上可以主动拒绝quoted-string和domain-literal。1.2 本地部分合法字符比你想的多得多把dot-atom展开看它的基本组成单元是atom而atom由atext组成。RFC 5322规定的atext包含这些字符ALPHA : A-Z a-z DIGIT : 0-9 特殊字符 : ! # $ % * - / ? ^ _ { | } ~也就是说在标准眼里!、#、$、%、、、*、、-、/、、?、^、_、、{、|、}、~都属于合法字符。网上很多正则完全没考虑这些东西直接一刀切只放行字母数字和._%-。这带来的直接后果是像customer/departmentshippingexample.com这种严格符合RFC 5322的地址会被你的正则误判为非法。虽然这种地址在实际业务里很少见但一旦出现用户就会觉得你的系统“有毒”。再说点号的规则。在dot-atom里点号.只能作为atom之间的分隔符不能出现在local-part的开头或结尾也不能连续出现。abc..defexample.com和.abcexample.com都是不合法的。这条规则我在初版代码里就漏了后来用测试用例跑出来才补上。还有一个很容易被忽略的概念性区别local-part在标准语法里是区分大小写的Userexample.com和userexample.com理论上是两个不同的地址。但在实际互联网生态里绝大多数邮件服务商都会把收件人地址做归一化处理大小写混用基本都能收到信你甚至见过有人故意用UPPERCASEexample.com来展示个性。落到自己的业务里我建议做法是格式校验允许大小写存储和发送时统一转小写域名部分强制小写本地部分按需保留这样可以避免很多无谓的“用户明明输对了却提示不存在”的纠纷。1.3 域名部分与“看起来不合法但确实合法”的边界情况domain部分的dot-atom规则类似于普通域名由多个标签用点号连接标签由字母、数字和连字符组成连字符不能出现在标签首位。此外还要注意域名对大小写完全不敏感EXAMPLE.COM和example.com在DNS解析层面完全等价。边界情况里最有趣的是单标签域名。按照RFC 5322的语法userlocalhost这种地址并未被语法层禁止因为domain允许单个dot-atom但现实中几乎没有邮件系统会为它提供服务。实际项目里如果允许用户填写内网地址或内部开发环境地址userlocalhost是有可能出现的你需要决定是放行并让它走内网邮箱还是干脆拒绝。我见过的多数SaaS系统会做额外限制要求域名必须包含至少一个点号也就是至少二级域名这样可以在格式层挡掉一批无效输入。另一个值得注意的点是“域名尾部点号”。userexample.com.在DNS语义上是合法的根域名的相对表示RFC 5322语法也没禁止但普通用户几乎不可能这么填。我的建议是在格式校验阶段直接拒绝尾部带点号的域名没必要为了理论上的严谨给用户增加困惑。最后是长度限制。RFC 5322本身没有直接规定邮箱地址总长度上限但RFC 5321SMTP协议和RFC 3696给出了实际操作约束local-part最长64字符domain部分最长253字符整个邮箱地址在“路径”环境里含尖括号最长256字符因此裸邮箱地址实际不能超过254字符。这个长度你要是真用正则去匹配写起来会很痛苦所以放到之后的校验逻辑里单独判断即可。2. 别急着搜正则先搞清楚成熟方案的真实水平讲完标准来聊聊最常见的坑网上流传的正则到底错在哪以及为什么我建议你宁可用标准库也别自己雕花。2.1 网上流行正则的两个典型问题我随手能列出一堆“看起来很强大”的邮箱正则但它们的问题高度相似。第一类问题误杀合法地址。经典款^[a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,}$会把带!、#、$等字符的合法地址全部拦掉也会误杀quoted-string格式。另一个变体要求顶层域名必须是2到6位字母这在遇到新顶级域名如.technology、.company时就会误杀更不用说今后可能出现更新的顶级域。只要你在正则里对TLD长度做了硬编码就必然要面对“今天看起来正确明天被新顶级域名打脸”的局面。第二类问题放行非法地址。比如有人用^\S\S$这种松弛到离谱的表达式它居然只要求“非空白字符串非空白字符串”连userin valid.com都能通过。稍微严谨一点的人会把正则写成^[^\s][^\s]\.[^\s]$但依然会放行a..bexample.com这类违法的连续点号地址。从本质上说RFC 5322的地址语法带有递归和上下文约束用正则去完整表达非常困难网上那些“超长终极版正则”几乎都是未经大规模测试的产物真的上线了反而成为维护噩梦。2.2 各语言成熟校验方案横向对比既然自研正则不靠谱那不同语言生态有哪些相对成熟的方案我整理了一张表是基于我实际用过或读过源码后的判断语言/环境推荐方案说明Pythonemail-validator库严格按RFC 5322/6531实现自动做归一化还能检查域名是否可达可选JavaScript/Nodevalidator.js的isEmail社区使用量极大支持quoted-string配置项丰富JavaApache Commons Validator的EmailValidator老牌实现稳定且覆盖大部分边界Gonet/mail.ParseAddress配合net.ParseIP和更强的手写逻辑标准库自带解析器但比较宽松需要二次判断RubyMail::Address.new解析严谨能区分name与addr但用法稍绕PHPfilter_var($email, FILTER_VALIDATE_EMAIL)能用但历史上出现过边界bug需做好回归测试这表不是让你无脑选“最严格的”而是说比起自己维护一堆正则会漏掉quoted-string和特殊字符成熟库经过了无数社区用户的边界测试至少在“看懂RFC”这件事上比你靠谱得多。我个人的偏好是Python项目直接上email-validator因为它在RFC兼容性和易用性之间平衡得最好还能输出标准化后的邮箱省去自己写normalize逻辑。2.3 何时该自己封装何时直接用库有人可能会问那我是不是可以用标准库email.utils.parseaddr不装第三方依赖答案是“可以但要接受它的宽松”。email.utils.parseaddr做的事情是从邮件头文本里提取“显示名 邮箱地址”它从来不是为了“判断一个字符串是不是合法邮箱地址”设计的。实测下来它会把很多明显非法的输入解析出“看起来像那么回事”的地址比如testexample.com, anotherexample.com这种用逗号分隔的列表它会截出第一段当作合法地址。所以在“严格校验用户输入”的场景里parseaddr只能算辅助工具不能作为唯一判断依据。我的建议是格式层用库email-validator或validator.js业务层再叠加自己的规则比如拒绝quoted-string、拒绝domain-literal、强制域名至少有一个点号。这样既跟上了标准又贴合真实产品诉求。3. 从语法合法到真实可用一条完整的验证链路应该怎么搭格式校验只是第一层。把邮箱验证拆开看它其实是一个四层的漏斗格式与长度校验、域名可收信性检查、SMTP会话级探测、所有权验证。每一层解决不同问题也有不同的成本和误判率。下面我把这四层串成一条链路讲清楚。3.1 第一层格式与长度校验第一层最简单也最基础核心目标是“把完全不像邮箱的输入挡在外面”。我用Python的email-validator来演示from email_validator import validate_email, EmailNotValidError def check_email_format(raw: str) - tuple[bool, str]: raw raw.strip() if len(raw) 254: return False, 邮箱地址过长 try: result validate_email(raw, check_deliverabilityFalse) return True, result.email # 归一化后的邮箱 except EmailNotValidError as e: return False, str(e)注意check_deliverabilityFalse这个参数。email-validator默认开启“可达性检查”会去查DNS和做SMTP探测这会让校验变得很慢不适合放在注册表单的即时校验里。我建议在注册/登录这种需要毫秒级响应的入口关闭这项把网络校验放到后续异步流程。另外result.email返回的是归一化后的地址域名部分会被转成小写这样做的好处是后续存储、去重、发信都不会因为大小写问题产生歧义。如果你用的是JavaScript技术栈validator.js对应的写法是const validator require(validator); function checkEmailFormat(raw) { if (!validator.isEmail(raw, { allow_utf8_local_part: false })) { return { ok: false, reason: invalid format }; } return { ok: true, email: raw.toLowerCase() }; }这里allow_utf8_local_part: false是为了暂时不支持国际化邮箱RFC 6531先把范围控制在ASCII范围内符合大多数国内业务初期的定位。3.2 第二层DNS查询确认域名可收信格式合法不等于能收到信。一个邮箱地址的域名可能根本不存在也可能域名存在但邮箱服务器没有配置MX记录。这一层要做的就是“确认这个域在互联网上存在并且愿意收邮件”。MXMail Exchange记录是DNS里专门用于邮件路由的记录它指明这个域名的邮件应该投递到哪台服务器。如果查询一个域名返回NXDOMAIN域名不存在那这个邮箱地址基本可以断定是无效的如果域名存在但没有任何MX记录按照RFC 5321的兜底逻辑发件方可以尝试使用该域名的A/AAAA记录直接投递但实际成功率很低在业务侧也可以直接判为不可达。下面是用dnspython做MX检查的参考实现import dns.resolver from functools import lru_cache from datetime import timedelta lru_cache(maxsize512, ttltimedelta(hours24).total_seconds()) def domain_can_receive_mail(domain: str) - bool: if len(domain) 253: return False try: answers dns.resolver.resolve(domain, MX, lifetime5) return len(answers) 0 except dns.resolver.NXDOMAIN: return False except dns.resolver.NoAnswer: try: answers dns.resolver.resolve(domain, A, lifetime5) return len(answers) 0 except Exception: return False except Exception: return False这段代码有两个我自己踩坑后加上的细节。一个是缓存。DNS查询是网络IO会有几十到几百毫秒的延迟如果每次注册都同步查一次MX接口响应会明显变慢还会被DNS服务商限流。用lru_cache加TTL缓存后同一个域名在24小时内只会查一次性能提升非常明显。注意lru_cache(ttl)是Python 3.9才有的参数老版本可以用cachetools库或自己写简单的字典缓存。另一个是兜底逻辑。很多小域名只有A记录没有MX记录虽然发信成功率不高但作为格式阶段的辅助判断可以放行让后续邮件发送流程去处理真实失败。这里需要根据业务容忍度来决定策略如果是注册临时邮箱、低价值账号可以直接判为不可达体验更快如果是核心用户注册建议放行到下一层避免误伤。3.3 第三层SMTP对话级探测能别用就别用网上有些教程会教“用SMTP协议直接连接邮件服务器发送RCPT TO命令探测邮箱是否存在”听起来很酷实际隐患不少。技术原理是这样的import smtplib def smtp_verify(email: str, mx_host: str, timeout: int 10) - bool: try: server smtplib.SMTP(timeouttimeout) server.connect(mx_host, 25) server.ehlo(mail.example.com) server.mail(noreplyexample.com) code, _ server.rcpt(email) server.quit() return code 250 except Exception: return False如果邮件服务器返回250说明它表示“我接受这封邮件”邮箱存在的概率很高如果返回550说明服务器明确表示“用户不存在”。但这里有几个很现实的问题很多反垃圾邮件策略会对这种探测请求统一返回“用户不存在”你根本得不到真实结果。大量邮件服务器会禁用25端口出站连接尤其是云服务器公网IP默认封禁25端口在国内相当常见。高频SMTP探测很容易被目标服务器拉黑结果就是你的应用服务器被列入垃圾邮件黑名单将来正常发信都受影响。我的结论是SMTP探测只适合做低频的“人工后台复查”或“注册后异步复核”千万不要放在用户请求同步链路里。即便要放在后台也得严格控制速率单IP对单域名的探测频率建议不要超过每小时几次最好配合随机小延迟。真想提高送达率靠的是把下一层的“所有权验证”做到位而不是在注册时暗戳戳探测。3.4 第四层所有权验证也就是激活邮件格式、域名、SMTP探测都只是“看起来像是能被送达”真正最有说服力的验证是“用户确实能收到邮件并做出响应”。这就是大家最熟悉的激活邮件注册后往用户邮箱发送一封带唯一链接的邮件只有收件人能点开链接点了这个链接才会触发服务端标记“邮箱已验证”。激活邮件的设计里最容易被忽略但至关重要的一环是token。不要用自增ID来做验证令牌否则攻击者可以枚举链接批量验证他人邮箱。推荐做法是生成一次性随机token服务端存储过期时间用户点击后置为已使用。也可以走无状态HMAC签名方案省去存储import hmac import hashlib import time SECRET_KEY byour-secret-key-dont-put-this-in-code def issue_email_token(email: str, issued_at: int) - str: msg f{email}:{issued_at}.encode(utf-8) digest hmac.new(SECRET_KEY, msg, hashlib.sha256).hexdigest() return f{issued_at}.{digest} def verify_email_token(email: str, token: str, max_age: int 24 * 3600) - bool: try: issued_at_str, digest token.rsplit(., 1) issued_at int(issued_at_str) except Exception: return False if time.time() - issued_at max_age: return False expected hmac.new( SECRET_KEY, f{email}:{issued_at}.encode(utf-8), hashlib.sha256 ).hexdigest() return hmac.compare_digest(digest, expected)但要提醒一句无状态token的缺点是“旧token无法主动撤销”。如果一个用户重复请求发送验证邮件你没办法让前一条链接立刻失效只能靠过期时间兜底。所以更稳妥的方式是服务端存储token用户重新请求时主动作废旧token这样安全性和体验都能兼顾。另外验证邮件发送的时机也值得琢磨。很多团队把“发送激活邮件”做成用户点击“发送验证邮件”按钮才触发这没什么不对但更好的做法是在注册成功后立即异步发送一封同时在页面提供“重新发送”按钮按钮做60秒倒计时防刷。邮件里除了链接最好带上收件人邮箱的前几位部分脱敏这样用户能确认这是发给自己。验证链接后的落地页务必避免两件事一是不要把“验证成功”和“验证失败”的页面差异做得太明显否则攻击者可以批量探测哪些地址已经被注册二是对失败请求返回通用提示例如“链接无效或已过期”不要区分“token不存在”和“token已过期”防止信息泄露。4. 实战踩坑记录合法却收不到、垃圾箱、批量探测被拉黑理论说完了分享几个我真实踩过的坑。这些坑不是书上看来的是上线后一个一个炸出来的。4.1 第一坑格式合法域名也能解析但就是收不到信现象是后台一堆未验证用户用户反馈说自己提交的邮箱“绝对是对的”。排查后发现几种典型情况用户填了类似testexample.com这种保留域名RFC 2606规定的示例域名格式合法、MX查询也有响应但它就是不会真的送达。用户填了useroutlook.con这种拼写错误DNS查不出来因为.con后缀确实存在解析记录格式层完全没法识别。这种只能通过发送激活邮件后“对方没收到”的非同步反馈来兜底。一次性邮箱又称临时邮箱域名比如mailinator.com这类地址能通过所有格式和DNS校验但它只是被当垃圾邮件地址用的。针对前两种一次性邮件发送失败后可以在后台发告警针对第三种业务团队如果坚决不允许临时邮箱注册可以维护一份已知临时邮箱域名黑名单但要注意黑名单维护成本不低而且用户很容易找到新的临时域名。4.2 第二坑激活邮件进了垃圾箱用户找不到邮箱格式和链路全对但激活率就是上不去。后来抽样问了几十个用户统一回答是“我没收到邮件”。翻邮件日志又发现投递都显示成功最后意识到是激活邮件被收件方归类到了垃圾箱。这里面有发送方信誉的问题。邮件服务商判断垃圾邮件的因素很多比如域名是否配置了SPF、DKIM、DMARC记录发件IP是否有过垃圾邮件历史邮件内容是不是满屏促销词和链接。我自己排序的排查方向是发件域名需要配置SPF记录能说明“只有我们的服务器能用这个域名发邮件”。DKIM签名要打开它提供内容完整性校验。DMARC策略要加虽然它在长期提升信誉里更重要但尽早配上没有坏处。邮件正文尽量朴素只有一个验证链接和一句说明不要堆砌颜色、图片、夸张文案。落页页引导用户“如果收件箱没有请检查垃圾箱”这句话能救回不少激活率。如果是小团队使用成熟的事务邮件服务商如SendGrid、Mailgun等比自己搭建邮件服务器要靠谱得多虽然会花点钱但换来的是反垃圾信誉管理和专业投递通道划算。4.3 第三坑批量SMTP探测把发信服务商投诉到暂停有一次用第三方的“邮箱验证服务”批量校验线上存量邮箱结果服务商把目标域名的MX服务器当成了垃圾来源投诉导致我们正常的邮件发送配额被暂停了一个多小时。那次之后我把所有“探测类”操作都改成了手动触发并且加了两条铁律任何批量SMTP探测都必须经过主账号管理员二次确认并且限制每小时最多跑多少条。探测结果只作为参考标签不直接决定账号状态最终以激活邮件点击为准。说到底邮箱验证的正确顺序是把“成本从低到高”排好先格式、再DNS、再发送激活邮件。SMTP探测这个东西定位永远是“辅助工具”不是“核心武器”。如果哪个供应商告诉你“百分百判断邮箱是否存在”那基本是吹牛因为邮件服务器出于反垃圾考虑经常返回假信息它只能做一个概率判断。最后再分享一个体会邮箱验证从来不是一个正则能解决的事它是一个分层决策的系统工程。格式层解决“像不像邮箱”DNS层解决“能不能送达”发送激活邮件解决“是不是你的邮箱”。你把这三层分开设计每一层都配上对应的代码和监控后面邮箱相关的投诉才会少很多。稍微夸张点说我后来接手的很多项目里邮箱问题频出基本都是这三层混在了一起、试图一步到位导致的。你先想清楚自己在哪一层再动手写代码。
1. 邮箱格式验证到底在验什么先啃下RFC 5322这段语法先说一个我自己的真实经历。早几年做用户注册模块邮箱验证正则用的是网上流传最广的那条经典款^[a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,}$。当时觉得挺稳直到有一天一个用户提交了usertagexample.co正则可以过后来又有人提交quoted stringexample.com直接被拦在门外。我去跟同事争论“带引号的邮箱到底合不合法”谁也说服不了谁最后翻到RFC 5322原文才意识到我们一直在用一条“看着差不多”的正则冒充标准而真正该做的是理解邮箱地址的语法树。1.1 地址语法addr-spec到底长什么样RFC 5322Internet Message Format是定义邮件消息格式的基础文档里面关于邮箱地址的核心定义是addr-spec也就是我们常说的“形如local-partdomain的完整邮箱地址”。用语法树表示大致是这样addr-spec local-part domain local-part dot-atom / quoted-string / obs-local-part domain dot-atom / domain-literal / obs-domain注意一个关键点local-part并不是只有“字母数字加点号”这一种形态标准语法里它是dot-atom或quoted-string二选一。很多开发者的第一道坑就出在这里正则只覆盖了dot-atom里最普通的那一部分遇到quoted-string就直接误杀。而obs-local-part和obs-domain是RFC 5322为了兼容老协议保留的“过时语法”实际开发中不建议支持这里先不展开。domain部分同样不只是普通域名还有一种domain-literal写法即用方括号包起来的IP地址字面量例如user[192.168.1.1]。这类地址在现实中几乎见不到但标准确实允许。你可能会想这些边界案例支持了又有什么用我的观点是格式校验的目标不是“允许尽可能多”而是在“遵循标准”和“贴合业务”之间找平衡。标准规定要明白但业务上可以主动拒绝quoted-string和domain-literal。1.2 本地部分合法字符比你想的多得多把dot-atom展开看它的基本组成单元是atom而atom由atext组成。RFC 5322规定的atext包含这些字符ALPHA : A-Z a-z DIGIT : 0-9 特殊字符 : ! # $ % * - / ? ^ _ { | } ~也就是说在标准眼里!、#、$、%、、、*、、-、/、、?、^、_、、{、|、}、~都属于合法字符。网上很多正则完全没考虑这些东西直接一刀切只放行字母数字和._%-。这带来的直接后果是像customer/departmentshippingexample.com这种严格符合RFC 5322的地址会被你的正则误判为非法。虽然这种地址在实际业务里很少见但一旦出现用户就会觉得你的系统“有毒”。再说点号的规则。在dot-atom里点号.只能作为atom之间的分隔符不能出现在local-part的开头或结尾也不能连续出现。abc..defexample.com和.abcexample.com都是不合法的。这条规则我在初版代码里就漏了后来用测试用例跑出来才补上。还有一个很容易被忽略的概念性区别local-part在标准语法里是区分大小写的Userexample.com和userexample.com理论上是两个不同的地址。但在实际互联网生态里绝大多数邮件服务商都会把收件人地址做归一化处理大小写混用基本都能收到信你甚至见过有人故意用UPPERCASEexample.com来展示个性。落到自己的业务里我建议做法是格式校验允许大小写存储和发送时统一转小写域名部分强制小写本地部分按需保留这样可以避免很多无谓的“用户明明输对了却提示不存在”的纠纷。1.3 域名部分与“看起来不合法但确实合法”的边界情况domain部分的dot-atom规则类似于普通域名由多个标签用点号连接标签由字母、数字和连字符组成连字符不能出现在标签首位。此外还要注意域名对大小写完全不敏感EXAMPLE.COM和example.com在DNS解析层面完全等价。边界情况里最有趣的是单标签域名。按照RFC 5322的语法userlocalhost这种地址并未被语法层禁止因为domain允许单个dot-atom但现实中几乎没有邮件系统会为它提供服务。实际项目里如果允许用户填写内网地址或内部开发环境地址userlocalhost是有可能出现的你需要决定是放行并让它走内网邮箱还是干脆拒绝。我见过的多数SaaS系统会做额外限制要求域名必须包含至少一个点号也就是至少二级域名这样可以在格式层挡掉一批无效输入。另一个值得注意的点是“域名尾部点号”。userexample.com.在DNS语义上是合法的根域名的相对表示RFC 5322语法也没禁止但普通用户几乎不可能这么填。我的建议是在格式校验阶段直接拒绝尾部带点号的域名没必要为了理论上的严谨给用户增加困惑。最后是长度限制。RFC 5322本身没有直接规定邮箱地址总长度上限但RFC 5321SMTP协议和RFC 3696给出了实际操作约束local-part最长64字符domain部分最长253字符整个邮箱地址在“路径”环境里含尖括号最长256字符因此裸邮箱地址实际不能超过254字符。这个长度你要是真用正则去匹配写起来会很痛苦所以放到之后的校验逻辑里单独判断即可。2. 别急着搜正则先搞清楚成熟方案的真实水平讲完标准来聊聊最常见的坑网上流传的正则到底错在哪以及为什么我建议你宁可用标准库也别自己雕花。2.1 网上流行正则的两个典型问题我随手能列出一堆“看起来很强大”的邮箱正则但它们的问题高度相似。第一类问题误杀合法地址。经典款^[a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,}$会把带!、#、$等字符的合法地址全部拦掉也会误杀quoted-string格式。另一个变体要求顶层域名必须是2到6位字母这在遇到新顶级域名如.technology、.company时就会误杀更不用说今后可能出现更新的顶级域。只要你在正则里对TLD长度做了硬编码就必然要面对“今天看起来正确明天被新顶级域名打脸”的局面。第二类问题放行非法地址。比如有人用^\S\S$这种松弛到离谱的表达式它居然只要求“非空白字符串非空白字符串”连userin valid.com都能通过。稍微严谨一点的人会把正则写成^[^\s][^\s]\.[^\s]$但依然会放行a..bexample.com这类违法的连续点号地址。从本质上说RFC 5322的地址语法带有递归和上下文约束用正则去完整表达非常困难网上那些“超长终极版正则”几乎都是未经大规模测试的产物真的上线了反而成为维护噩梦。2.2 各语言成熟校验方案横向对比既然自研正则不靠谱那不同语言生态有哪些相对成熟的方案我整理了一张表是基于我实际用过或读过源码后的判断语言/环境推荐方案说明Pythonemail-validator库严格按RFC 5322/6531实现自动做归一化还能检查域名是否可达可选JavaScript/Nodevalidator.js的isEmail社区使用量极大支持quoted-string配置项丰富JavaApache Commons Validator的EmailValidator老牌实现稳定且覆盖大部分边界Gonet/mail.ParseAddress配合net.ParseIP和更强的手写逻辑标准库自带解析器但比较宽松需要二次判断RubyMail::Address.new解析严谨能区分name与addr但用法稍绕PHPfilter_var($email, FILTER_VALIDATE_EMAIL)能用但历史上出现过边界bug需做好回归测试这表不是让你无脑选“最严格的”而是说比起自己维护一堆正则会漏掉quoted-string和特殊字符成熟库经过了无数社区用户的边界测试至少在“看懂RFC”这件事上比你靠谱得多。我个人的偏好是Python项目直接上email-validator因为它在RFC兼容性和易用性之间平衡得最好还能输出标准化后的邮箱省去自己写normalize逻辑。2.3 何时该自己封装何时直接用库有人可能会问那我是不是可以用标准库email.utils.parseaddr不装第三方依赖答案是“可以但要接受它的宽松”。email.utils.parseaddr做的事情是从邮件头文本里提取“显示名 邮箱地址”它从来不是为了“判断一个字符串是不是合法邮箱地址”设计的。实测下来它会把很多明显非法的输入解析出“看起来像那么回事”的地址比如testexample.com, anotherexample.com这种用逗号分隔的列表它会截出第一段当作合法地址。所以在“严格校验用户输入”的场景里parseaddr只能算辅助工具不能作为唯一判断依据。我的建议是格式层用库email-validator或validator.js业务层再叠加自己的规则比如拒绝quoted-string、拒绝domain-literal、强制域名至少有一个点号。这样既跟上了标准又贴合真实产品诉求。3. 从语法合法到真实可用一条完整的验证链路应该怎么搭格式校验只是第一层。把邮箱验证拆开看它其实是一个四层的漏斗格式与长度校验、域名可收信性检查、SMTP会话级探测、所有权验证。每一层解决不同问题也有不同的成本和误判率。下面我把这四层串成一条链路讲清楚。3.1 第一层格式与长度校验第一层最简单也最基础核心目标是“把完全不像邮箱的输入挡在外面”。我用Python的email-validator来演示from email_validator import validate_email, EmailNotValidError def check_email_format(raw: str) - tuple[bool, str]: raw raw.strip() if len(raw) 254: return False, 邮箱地址过长 try: result validate_email(raw, check_deliverabilityFalse) return True, result.email # 归一化后的邮箱 except EmailNotValidError as e: return False, str(e)注意check_deliverabilityFalse这个参数。email-validator默认开启“可达性检查”会去查DNS和做SMTP探测这会让校验变得很慢不适合放在注册表单的即时校验里。我建议在注册/登录这种需要毫秒级响应的入口关闭这项把网络校验放到后续异步流程。另外result.email返回的是归一化后的地址域名部分会被转成小写这样做的好处是后续存储、去重、发信都不会因为大小写问题产生歧义。如果你用的是JavaScript技术栈validator.js对应的写法是const validator require(validator); function checkEmailFormat(raw) { if (!validator.isEmail(raw, { allow_utf8_local_part: false })) { return { ok: false, reason: invalid format }; } return { ok: true, email: raw.toLowerCase() }; }这里allow_utf8_local_part: false是为了暂时不支持国际化邮箱RFC 6531先把范围控制在ASCII范围内符合大多数国内业务初期的定位。3.2 第二层DNS查询确认域名可收信格式合法不等于能收到信。一个邮箱地址的域名可能根本不存在也可能域名存在但邮箱服务器没有配置MX记录。这一层要做的就是“确认这个域在互联网上存在并且愿意收邮件”。MXMail Exchange记录是DNS里专门用于邮件路由的记录它指明这个域名的邮件应该投递到哪台服务器。如果查询一个域名返回NXDOMAIN域名不存在那这个邮箱地址基本可以断定是无效的如果域名存在但没有任何MX记录按照RFC 5321的兜底逻辑发件方可以尝试使用该域名的A/AAAA记录直接投递但实际成功率很低在业务侧也可以直接判为不可达。下面是用dnspython做MX检查的参考实现import dns.resolver from functools import lru_cache from datetime import timedelta lru_cache(maxsize512, ttltimedelta(hours24).total_seconds()) def domain_can_receive_mail(domain: str) - bool: if len(domain) 253: return False try: answers dns.resolver.resolve(domain, MX, lifetime5) return len(answers) 0 except dns.resolver.NXDOMAIN: return False except dns.resolver.NoAnswer: try: answers dns.resolver.resolve(domain, A, lifetime5) return len(answers) 0 except Exception: return False except Exception: return False这段代码有两个我自己踩坑后加上的细节。一个是缓存。DNS查询是网络IO会有几十到几百毫秒的延迟如果每次注册都同步查一次MX接口响应会明显变慢还会被DNS服务商限流。用lru_cache加TTL缓存后同一个域名在24小时内只会查一次性能提升非常明显。注意lru_cache(ttl)是Python 3.9才有的参数老版本可以用cachetools库或自己写简单的字典缓存。另一个是兜底逻辑。很多小域名只有A记录没有MX记录虽然发信成功率不高但作为格式阶段的辅助判断可以放行让后续邮件发送流程去处理真实失败。这里需要根据业务容忍度来决定策略如果是注册临时邮箱、低价值账号可以直接判为不可达体验更快如果是核心用户注册建议放行到下一层避免误伤。3.3 第三层SMTP对话级探测能别用就别用网上有些教程会教“用SMTP协议直接连接邮件服务器发送RCPT TO命令探测邮箱是否存在”听起来很酷实际隐患不少。技术原理是这样的import smtplib def smtp_verify(email: str, mx_host: str, timeout: int 10) - bool: try: server smtplib.SMTP(timeouttimeout) server.connect(mx_host, 25) server.ehlo(mail.example.com) server.mail(noreplyexample.com) code, _ server.rcpt(email) server.quit() return code 250 except Exception: return False如果邮件服务器返回250说明它表示“我接受这封邮件”邮箱存在的概率很高如果返回550说明服务器明确表示“用户不存在”。但这里有几个很现实的问题很多反垃圾邮件策略会对这种探测请求统一返回“用户不存在”你根本得不到真实结果。大量邮件服务器会禁用25端口出站连接尤其是云服务器公网IP默认封禁25端口在国内相当常见。高频SMTP探测很容易被目标服务器拉黑结果就是你的应用服务器被列入垃圾邮件黑名单将来正常发信都受影响。我的结论是SMTP探测只适合做低频的“人工后台复查”或“注册后异步复核”千万不要放在用户请求同步链路里。即便要放在后台也得严格控制速率单IP对单域名的探测频率建议不要超过每小时几次最好配合随机小延迟。真想提高送达率靠的是把下一层的“所有权验证”做到位而不是在注册时暗戳戳探测。3.4 第四层所有权验证也就是激活邮件格式、域名、SMTP探测都只是“看起来像是能被送达”真正最有说服力的验证是“用户确实能收到邮件并做出响应”。这就是大家最熟悉的激活邮件注册后往用户邮箱发送一封带唯一链接的邮件只有收件人能点开链接点了这个链接才会触发服务端标记“邮箱已验证”。激活邮件的设计里最容易被忽略但至关重要的一环是token。不要用自增ID来做验证令牌否则攻击者可以枚举链接批量验证他人邮箱。推荐做法是生成一次性随机token服务端存储过期时间用户点击后置为已使用。也可以走无状态HMAC签名方案省去存储import hmac import hashlib import time SECRET_KEY byour-secret-key-dont-put-this-in-code def issue_email_token(email: str, issued_at: int) - str: msg f{email}:{issued_at}.encode(utf-8) digest hmac.new(SECRET_KEY, msg, hashlib.sha256).hexdigest() return f{issued_at}.{digest} def verify_email_token(email: str, token: str, max_age: int 24 * 3600) - bool: try: issued_at_str, digest token.rsplit(., 1) issued_at int(issued_at_str) except Exception: return False if time.time() - issued_at max_age: return False expected hmac.new( SECRET_KEY, f{email}:{issued_at}.encode(utf-8), hashlib.sha256 ).hexdigest() return hmac.compare_digest(digest, expected)但要提醒一句无状态token的缺点是“旧token无法主动撤销”。如果一个用户重复请求发送验证邮件你没办法让前一条链接立刻失效只能靠过期时间兜底。所以更稳妥的方式是服务端存储token用户重新请求时主动作废旧token这样安全性和体验都能兼顾。另外验证邮件发送的时机也值得琢磨。很多团队把“发送激活邮件”做成用户点击“发送验证邮件”按钮才触发这没什么不对但更好的做法是在注册成功后立即异步发送一封同时在页面提供“重新发送”按钮按钮做60秒倒计时防刷。邮件里除了链接最好带上收件人邮箱的前几位部分脱敏这样用户能确认这是发给自己。验证链接后的落地页务必避免两件事一是不要把“验证成功”和“验证失败”的页面差异做得太明显否则攻击者可以批量探测哪些地址已经被注册二是对失败请求返回通用提示例如“链接无效或已过期”不要区分“token不存在”和“token已过期”防止信息泄露。4. 实战踩坑记录合法却收不到、垃圾箱、批量探测被拉黑理论说完了分享几个我真实踩过的坑。这些坑不是书上看来的是上线后一个一个炸出来的。4.1 第一坑格式合法域名也能解析但就是收不到信现象是后台一堆未验证用户用户反馈说自己提交的邮箱“绝对是对的”。排查后发现几种典型情况用户填了类似testexample.com这种保留域名RFC 2606规定的示例域名格式合法、MX查询也有响应但它就是不会真的送达。用户填了useroutlook.con这种拼写错误DNS查不出来因为.con后缀确实存在解析记录格式层完全没法识别。这种只能通过发送激活邮件后“对方没收到”的非同步反馈来兜底。一次性邮箱又称临时邮箱域名比如mailinator.com这类地址能通过所有格式和DNS校验但它只是被当垃圾邮件地址用的。针对前两种一次性邮件发送失败后可以在后台发告警针对第三种业务团队如果坚决不允许临时邮箱注册可以维护一份已知临时邮箱域名黑名单但要注意黑名单维护成本不低而且用户很容易找到新的临时域名。4.2 第二坑激活邮件进了垃圾箱用户找不到邮箱格式和链路全对但激活率就是上不去。后来抽样问了几十个用户统一回答是“我没收到邮件”。翻邮件日志又发现投递都显示成功最后意识到是激活邮件被收件方归类到了垃圾箱。这里面有发送方信誉的问题。邮件服务商判断垃圾邮件的因素很多比如域名是否配置了SPF、DKIM、DMARC记录发件IP是否有过垃圾邮件历史邮件内容是不是满屏促销词和链接。我自己排序的排查方向是发件域名需要配置SPF记录能说明“只有我们的服务器能用这个域名发邮件”。DKIM签名要打开它提供内容完整性校验。DMARC策略要加虽然它在长期提升信誉里更重要但尽早配上没有坏处。邮件正文尽量朴素只有一个验证链接和一句说明不要堆砌颜色、图片、夸张文案。落页页引导用户“如果收件箱没有请检查垃圾箱”这句话能救回不少激活率。如果是小团队使用成熟的事务邮件服务商如SendGrid、Mailgun等比自己搭建邮件服务器要靠谱得多虽然会花点钱但换来的是反垃圾信誉管理和专业投递通道划算。4.3 第三坑批量SMTP探测把发信服务商投诉到暂停有一次用第三方的“邮箱验证服务”批量校验线上存量邮箱结果服务商把目标域名的MX服务器当成了垃圾来源投诉导致我们正常的邮件发送配额被暂停了一个多小时。那次之后我把所有“探测类”操作都改成了手动触发并且加了两条铁律任何批量SMTP探测都必须经过主账号管理员二次确认并且限制每小时最多跑多少条。探测结果只作为参考标签不直接决定账号状态最终以激活邮件点击为准。说到底邮箱验证的正确顺序是把“成本从低到高”排好先格式、再DNS、再发送激活邮件。SMTP探测这个东西定位永远是“辅助工具”不是“核心武器”。如果哪个供应商告诉你“百分百判断邮箱是否存在”那基本是吹牛因为邮件服务器出于反垃圾考虑经常返回假信息它只能做一个概率判断。最后再分享一个体会邮箱验证从来不是一个正则能解决的事它是一个分层决策的系统工程。格式层解决“像不像邮箱”DNS层解决“能不能送达”发送激活邮件解决“是不是你的邮箱”。你把这三层分开设计每一层都配上对应的代码和监控后面邮箱相关的投诉才会少很多。稍微夸张点说我后来接手的很多项目里邮箱问题频出基本都是这三层混在了一起、试图一步到位导致的。你先想清楚自己在哪一层再动手写代码。
