在做用户系统这些年邮箱验证被我翻来覆去折腾过好几轮。第一版是个正则表达式从网上抄的号称“最全”测了几个样例就上线了。结果某天用户反馈注册不了一看日志有个带号的邮箱被当成非法地址还有个用户用了126邮箱带下划线也过了但之后发送验证邮件永远失败。后来我认真读了一遍RFC 5322才发现“验证邮箱格式”这件事远没有想象中那么简单。这篇文章不是RFC的翻译版我会从实际工程出发先把RFC 5322里跟邮箱格式相关的规则讲明白再给出我目前在生产环境使用的验证方案包括正则、DNS检查、SMTP连通性测试的取舍以及一堆你在网上搜不到的坑。内容适合后端开发、主站系统负责人和任何需要自己写注册模块的人读完至少能让你少踩几个坑。1. 邮箱格式验证为什么这么难1.1 从RFC 5322的基本定义说起先看一个最简单的邮箱userexample.com。我们习惯把这个字符串拆成“前面是用户名后面是域名”但在RFC 5322里它定义的是两个东西local-part本地部分和domain域名部分合起来叫addr-spec。整个规范对addr-spec的定义非常宽泛宽泛到很多用正则做校验的人压根没意识到。local-part在理论上可以是dot-atom也可以是quoted-string中间还允许出现obs-local-part这种历史遗留格式。dot-atom允许的字符集合比大多数人想象的大得多除了字母数字和!#$%*-/?^_{|}~之外还可以包含点号但点号不能出现在开头或结尾也不能连续出现。quoted-string则更宽双引号里几乎什么都能放包括空格、、括号、甚至中文字符。域名部分也不只是“字母数字加点”。RFC 5322允许点分字符串也允许用方括号包起来的IP地址字面量比如user[192.168.1.1]也是合法格式。如果严格按规范完美校验最终你会发现自己不是在写“邮箱格式校验函数”而是在写一个完整的状态机。1.2 常规正则的常见错误网上流传最广的邮箱正则基本长这样^[a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,}$这个正则拦住了一堆合法邮箱也放行了一堆不该放行的地址。拿它去匹配john..doeexample.com这种带引号的地址直接判非法其实这是合规的反过来它允许a..bexample.com这却是非法格式因为连续点号在dot-atom里不被允许。再比如.usernameexample.com有些实现在前面加了个.就放过去了但local-part以点开头是不合法的。还有user-example.com、userexample-.com域名以连字符开头或结尾也不符合域名解析规则但很多正则根本没检查。更麻烦的是长度。RFC 5321SMTP协议那个RFC规定了邮箱地址整体长度不能超过254个字符local-part最长64个字符域名部分最长255个字符但整体加起来仍有254限制。常见正则完全没有长度概念。事实是格式验证只应该是一道最低门槛它的目的是“快速排除明显非法输入”不是“精确判断邮箱是否能收到邮件”。你花一整天写一个100%符合RFC 5322的校验器对业务几乎没有收益。我见过有人用真正的Byacc生成一个巨大的解析器来解析邮箱结果上线一个月它拦下的用户还没它误杀的邮箱多。2. 解析RFC 5322的核心规则2.1 基本语法元素atext、dot-atom、quoted-stringRFC 5322的定义用ABNF写读起来比较费劲。我帮你梳理几个关键术语。首先是atext。这是组成dot-atom的最小单元可选的字符是A-Z a-z 0-9 ! # $ % * - / ? ^ _ { | } ~注意里面没有空格、没有双引号、没有括号、没有逗号、没有冒号和分号。点号本身也不是atext它是dot-atom里的分隔符。dot-atom由一串atext或者用点号分隔的多串atext组成规则要求点号不能出现在开头或结尾也不能连续。所以a.b.c合法a..b非法.a非法a.非法。quoted-string就自由多了。它由双引号包起来可以是qcontent几乎包含任何可打印ASCII字符包括空格和唯一需要转义的是反斜杠和双引号。举例来说john doeexample.com是合法格式a..bexample.com也合法。但是注意绝大部分邮件系统并不希望你真的用这种地址注册因为很多服务端程序不兼容它。范例如下john doeexample.com very.(),:;[]\.VERY.\very\\ \very\.unusualstrange.example.com后面这个例子是RFC 3696里给出的传统合法地址虽然奇葩但语法上成立。2.2 域名部分和地址字面量域名部分有两种写法点分域名和地址字面量。点分域名就是常见的example.com每一段叫sub-domain由字母数字和连字符组成但连字符不能出现在段的开头或结尾。域名部分的最后一个顶层域一般要求至少两个字符但RFC 5322并不强制直接写usermachine也是符合本地网络命名规范的只是现实里几乎不会用。地址字面量是方括号内直接写IP或IPv6地址比如user[127.0.0.1] user[IPv6:::1]RFC 5322对IPv6字面量有完整规定需要在方括号里加IPv6:前缀。这类地址在普通网站注册里几乎不会出现但如果你想做一个严格的解析器就得处理。后端校验时通常会对域名部分使用IDNAInternationalized Domain Names in Applications规则。用户输入中文域名用户例子.中国需要先转成punycode形式再做校验。如果直接拿例子.中国匹配传统的域名正则基本全灭。SMTPUTF8扩展允许UTF-8邮箱地址但那是另一个复杂话题后面再讲。2.3 实际应用中我们该验证哪些规则我个人的工程观点是邮箱格式校验分三层绝大多数业务只需要第一层。第一层是基础语法层检查是否符合addr-spec的大致形态包括local-part字符集、、域名基本结构、长度限制。这是必做的用正则或标准库解析都行。第二层是域名实时校验层解析后面的域名查DNS的MX记录没有MX就查A/AAAA记录。这一步能拦截大量随手乱填的地址比如userasdfghjk123.com格式合法但域名根本不存在。第三层是邮箱存在性校验层通过网络协议去查邮箱是否真的存在常见做法是连接邮件服务器发送RCPT TO命令看服务器是否接受。这一层最不可靠也很容易触发风控或造成性能问题不建议自己做。这个分层思想在后面的实战中会非常有用。你不需要第一层就把所有非法都拦掉那只会把第二、第三层该干的事提前做了还做得特别差。3. 实战实现一个可用的邮箱验证方案3.1 推荐策略分层验证我的方案分三步在生产环境跑了很多年误杀率很低语法检查长度 基础格式。这一步目的是剔除明显垃圾输入。域名检查解析MX或A记录。这一步的目的是验证域名真实存在并且有收件能力。可选的“送达性”提示如果是注册场景通常在发送激活邮件后根据退信结果来标记无效邮箱而不是在用户提交时做昂贵的SMTP检查。先讲语法检查这是本篇文章的核心。3.2 一个足够好又不会过度严格的正则我自己写了不少版本最终留下的实用正则长这样Python风格但可迁移到其它语言import re email_valid_re re.compile( r^(?Plocal[a-zA-Z0-9!#$%*/?^_{|}~\.-]) r(?Pdomain[a-zA-Z0-9-](?:\.[a-zA-Z0-9-])*)$ )这个正则允许的local字符集和atext一致另外允许点号但因为它用的是[...]没有对点号的起始位置做特殊判断。我会在后面的代码里补两个检查local不能以点开头或结尾local不能出现连续两个点域名部分则是每段都要求字母数字连字符且段间用点号分隔。但连字符不能开头或结尾这个规则也需要额外检查。我用一个函数把这些规则串起来def validate_email_syntax(email: str) - bool: if not isinstance(email, str) or len(email) 254: return False match email_valid_re.fullmatch(email) if not match: return False local match.group(local) domain match.group(domain) if len(local) 64: return False if local.startswith(.) or local.endswith(.): return False if .. in local: return False for label in domain.split(.): if len(label) 63: return False if label.startswith(-) or label.endswith(-): return False if not label: return False return True这个函数里加上了RFC 5321对local-part和域名label的长度限制。实测下来它能覆盖绝大多数合法邮箱同时拦截掉a..bexample.com、.aexample.com、a.example.com、-aexample.com这类非法地址。3.3 标准库解析与正则的配合Python标准库email.utils.parseaddr是一个轻量的解析工具但它并不能用来做“验证”它只会尽力拆出名字和邮箱。跑一下你就知道它有多宽松from email.utils import parseaddr print(parseaddr(Not An Email not-an-email)) # (, not-an-email) print(parseaddr(a..bexample.com a..bexample.com)) # (a..bexample.com, a..bexample.com)它把a..bexample.com也当作合法地址返回了这就是为什么不能直接用parseaddr做校验。正确用法是先用它切掉显示名display name再对我们关心的addr-spec部分做正则校验比如from email.utils import parseaddr def extract_email(raw: str) - str: _, addr parseaddr(raw) return addr如果你处理的表单也是“名字 邮箱地址”一起传过来的可以先用parseaddr提取地址再走validate_email_syntax这样用户输入“张三 zhangsanexample.com ”这种带显示名的字符串也能正确处理。3.4 Ruby、JavaScript等其他语言的正则怎么迁移如果你用Ruby正则语法几乎一样EMAIL_REGEX /\A[a-zA-Z0-9!#$%*\/?^_{|}~.-][a-zA-Z0-9-](?:\.[a-zA-Z0-9-])*\z/JavaScript里要注意两点一是\A和\z不支持要用^和$并且记得用u标志处理unicode二是某些环境下\w会匹配中文所以不要用\w做字符类必须显式列出[a-zA-Z0-9_]。普通的/在正则字面量里需要转义成\/其它通用。在Java/Go/C#里也是类似需要注意反斜杠转义。强烈建议把正则编译成常量放在类或模块里不要每次校验都重新编译。3.5 国际化邮箱怎么办用户填张三example.com或者user例子.中国很多老系统直接拒绝了这会让一批真实用户流失。IDN域名的处理思路是先把域名部分用idna库转成ASCII再套用之前的正则。Python里这样处理def to_ascii_domain(domain: str) - str: try: return domain.encode(idna).decode(ascii) except UnicodeError: return def validate_email_with_idn(email: str) - bool: if not in email: return False local, _, domain email.rpartition() if not local or not domain: return False ascii_domain to_ascii_domain(domain) if not ascii_domain: return False return validate_email_syntax(f{local}{ascii_domain})rpartition很关键因为local部分理论上也可能包含比如在引号字符串里但现实情况下我们几乎不会要求支持引号字符串所以从右侧切第一个即可。如果用户输入的是abexample.com这个函数会把local当成ab然后继续校验会让引号字符串通过吗不会因为正则的字符集合里没有双引号所以ab会直接判定非法。这是我故意做的取舍虽然RFC说引号字符串合法但在用户注册这种业务场景下我们并不希望真的启用这种地址支持它只会徒增兼容成本。对于local部分出现中文的情况比如张三example.comRFC 6531/SMTPUTF8允许但现实里很多邮件服务商不支持。我的态度是如果用户填了这类地址可以先允许提交发送激活邮件后等待退信不要在前端把它一刀切掉因为拦截的代价是永远丢了一个用户。当然具体是否支持取决于你的目标用户群体。4. 从验证到送达把好域名这道关4.1 为什么只验证格式不够很多在注册页乱填的人输入的不是随机字符串而是类似asdfqwer.com这样格式完全合法的地址但qwer.com这个域名可能压根不存在。语法校验对此毫无办法。你只能通过域名解析去判断这个域名是不是真实存在的。判断标准很简单查询这个域名的MX记录。MX记录是邮件交换记录指定了哪个主机负责接收该域名的邮件。如果MX记录存在说明该域名至少配置了接收邮件的服务器。如果MX不存在再查A/AAAA记录因为有些小型域名只配置了A记录也照样接收邮件用A记录做MX fallback是不规范但存在的做法。4.2 DNS MX 记录检查Python里可以用dnspython库也可以用标准库直接做系统级DNS查询。dnspython更可控我一般这么写import dns.resolver def has_mail_exchanger(domain: str, timeout: float 3.0) - bool: resolver dns.resolver.Resolver() resolver.timeout timeout resolver.lifetime timeout try: answers resolver.resolve(domain, MX) except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer): try: resolver.resolve(domain, A) except Exception: return False return True except Exception: return False return len(answers) 0如果你不想引入dnspython在Unix系统上也可以直接调用nslookup或dig命令但解析输出很繁琐而且容易受到系统配置影响。我更推荐直接用库。注册场景中我通常把这个检查做成异步任务而不是同步卡在注册接口里。因为DNS查询一般几十毫秒但特殊情况下可能超时到秒级同步会拖慢注册速度。但如果你的注册量不大直接同步查也没问题最多在异常时放行把判断推后到发邮件阶段。4.3 SMTP连通性测试的陷阱有些人会进一步尝试连接MX主机发送RCPT TO命令来判断用户邮箱是否存在。思路是HELO example.com MAIL FROM: testexample.com RCPT TO: targetexample.com如果返回250说明邮箱存在返回550则不存在。听起来很好用但实操下来全是坑第一很多邮件服务器在收到陌生IP的RCPT TO探测时会直接拒绝或启动慢响应比如Gmail会返回“421 Too many errors”或者干脆不响应误判率很高。第二有些服务器为了反垃圾邮件会对所有RCPT TO返回250俗称“catch-all”你会得到假阳性。第三频繁连接会导致你的服务器IP被列入黑名单影响正常邮件发送。第四SMTP协议本身还规定VRFY命令用于验证用户但绝大多数服务器为了避嫌都禁用了它。我的建议是不要自己写SMTP探测逻辑。如果业务确实需要判断邮箱是否有效建议使用经过市场验证的第三方邮箱验证服务它们维护了大量的域名频率控制、动态IP池和黑名单策略准确率高很多。4.4 邮箱验证服务怎么选第三方服务一般通过API一次性批量验证会返回valid、invalid、catch_all、unknown等状态。选型时注意几个指标指标关注点准确率是否区分真的邮箱和catch-all域名下的随机地址延迟单条验证的响应时间是否可接受成本按次计费还是包月无效条数是否扣费数据安全是否允许传输用户邮箱是否有加密和合规承诺我见过不少团队在注册流程里同步调用第三方验证接口导致注册链路多了几百毫秒。更合理的方案是先做基础语法域名检查保留一个email_status字段注册成功后后台调用第三方慢慢验证再根据结果标记“已确认有效”或“可能无效”。这样用户体验最好。5. 常见问题与排查技巧实录5.1 真实场景里的诡异输入我把自己多年踩过的坑整理成了表格供你快速排查用户输入常见错误判断正确处理usertagexample.com被误判非法很多老正则不支持合法是atext字符user.nameexample.com合法但要注意user..nameuser.example.com被部分正则放过非法local以点结尾.userexample.com被部分正则放过非法local以点开头user-example.com被部分正则放过非法域名段不能以连字符开头userexample-.com被部分正则放过非法域名段不能以连字符结尾userexample.c多数正则拦截理论上允许但实际可要求至少两位顶级域user[192.168.1.1]被正则拦截格式合法但现实注册基本不会出现quotedlocalexample.com被正则拦截RFC合法但建议不开放用户例子.中国被正则拦截需IDN转换后校验userexample.com.被正则拦截末尾多一个点用户手误不建议硬放行空字符串 / 只含空格被正则拦截直接拒绝并提示必填usercom域名只有单个标签现实中很少有效建议要求至少包含一个点仔细看这个表你会发现很多边界情况的处理取决于产品策略而不是纯粹的技术对错。例如userexample.c虽然语法上不算错但我建议在注册系统里拒绝因为它没有常用顶级域极大概率是误填。5.2 前端校验和后端校验的角色分工前端校验只是提升用户体验后端的校验才是安全底线。我在项目里通常这样配合前端JavaScript失去焦点时快速校验格式并提示“邮箱格式似乎不正确”让用户及时修改。后端则要重新做完整的语法检查和域名检查因为攻击者可以绕开前端直接POST。后端如果只依赖一个正则等于把整个注册接口的安全寄托在客户端代码上这是大忌。另外建议在服务端对邮箱做规范化处理使用小写保存虽然local-part理论上是大小写敏感的但绝大多数邮件服务不区分统一小写更容易查重去除首尾空格对于Gmail这类支持点号无感的服务不建议做复杂归一化避免误伤后端保存时统一小写但要注意理论上UserExample.com和userexample.com可能不是同一个邮箱实际几乎可以等同处理。如果为了100%严谨可以在代码注释里说明这个取舍但不要真的去区分大小写建两套用户否则用户会迷惑。5.3 验证逻辑的测试用例模板每次写完邮箱校验函数我至少会跑下面这些用例。你可以直接抄走作为单元测试valid_cases [ simpleexample.com, very.commonexample.com, userfilterexample.com, user-1example.org, user.nametagsortingexample.com, xexample.com, example-indeedstrange-example.com, test3com.com, userexample.c, ] invalid_cases [ abc, abc, example.com, .userexample.com, user.example.com, user..nameexample.com, user-example.com, userexample-.com, user.example.com, userexample..com, userexample.com., , , ]这里我把userexample.c放在valid里是为了测试你的校验器是否可以灵活配置顶级域策略。生产环境我通常会加一个TLD白名单或黑名单而不是死板地要求2位以上因为现在顶级域有几百种.tech、.top、.icu等新顶级域也能收邮件。5.4 实现决策树最后给一个我在团队分享时画过无数次的决策树写成文字版输入为空是提示必填。长度超过254是拒绝。没有或个数大于1是拒绝。用右侧第一个切分开local和domain。local超过64或包含非法字符/点号使用错误是拒绝。domain包含非法字符或标签长度超标是拒绝。域名能否解析出MX/A记录否拒绝或标记“可能无效”。最终提交后发送验证邮件根据退信情况兜底。按照这个顺序做逻辑清晰排查起来也方便。千万不要把DNS检查、SMTP检查全部塞进一个正则里那不是工程那是行为艺术。5.5 一个容易被忽略的细节验证邮件的发送逻辑如果你只做格式校验最后发给用户的邮件被退信那前面所有校验都白搭。我建议在发送验证邮件时记录发送状态并且维护一个“邮箱无效”的重试策略。常见做法是首次发送失败后在用户表中标记email_verification_failed次日或第3天自动重试一次如果连续3次失败就向用户展示“更换邮箱或重新发送”的入口。另外要注意某些邮件服务商对号地址可能不支持比如有的企业邮箱会把usertagexample.com拒收这种情况不是我们的格式问题而是对方服务器问题。碰到个别用户反馈收不到验证邮件时查一下退信日志而不是怀疑自己的正则写错了。我自己踩过最离谱的一个坑是某用户邮箱是testlocalhost格式真的通过了域名单标签DNS检查也直接跳过了查询localhost会报错我们默认放行结果系统给localhost发了封邮件自然石沉大海。后来我在域名检查前先拦截了保留域名和裸主机名才解决这个问题。像localhost、test这类特殊域建议直接加入拒绝名单。这套验证体系跑到现在注册页的无效提交率下降了大概30%最主要功劳其实是DNS检查而不是正则。我一直在跟团队强调格式验证是必要的但不应该是唯一的验证手段邮件验证码/退信监控才是最终的确认机制。真正确认这个邮箱归用户所有唯一的办法是发送带一次性链接或验证码的邮件让用户回点/回填。在这一点上省事后续的账号安全、触达率、数据质量都会出问题。再分享一个小技巧在保存邮箱的数据库表里给邮箱列加上唯一索引但统一存小写。你可能会问如果用户执意要区分大小写怎么办在真实业务里99%的用户不会故意区分这个索引会帮你拦住大量重复注册的脏数据。邮箱验证这条线从格式到解析从DNS到SMTP每个环节都有妥协和取舍搞明白RFC 5322的原始定义能让你做出更清醒的决策而不是死记一个正则。希望我的这些经验能帮你少走弯路。 邮箱格式验证工程实践：从RFC 5322到分层校验方案
在做用户系统这些年邮箱验证被我翻来覆去折腾过好几轮。第一版是个正则表达式从网上抄的号称“最全”测了几个样例就上线了。结果某天用户反馈注册不了一看日志有个带号的邮箱被当成非法地址还有个用户用了126邮箱带下划线也过了但之后发送验证邮件永远失败。后来我认真读了一遍RFC 5322才发现“验证邮箱格式”这件事远没有想象中那么简单。这篇文章不是RFC的翻译版我会从实际工程出发先把RFC 5322里跟邮箱格式相关的规则讲明白再给出我目前在生产环境使用的验证方案包括正则、DNS检查、SMTP连通性测试的取舍以及一堆你在网上搜不到的坑。内容适合后端开发、主站系统负责人和任何需要自己写注册模块的人读完至少能让你少踩几个坑。1. 邮箱格式验证为什么这么难1.1 从RFC 5322的基本定义说起先看一个最简单的邮箱userexample.com。我们习惯把这个字符串拆成“前面是用户名后面是域名”但在RFC 5322里它定义的是两个东西local-part本地部分和domain域名部分合起来叫addr-spec。整个规范对addr-spec的定义非常宽泛宽泛到很多用正则做校验的人压根没意识到。local-part在理论上可以是dot-atom也可以是quoted-string中间还允许出现obs-local-part这种历史遗留格式。dot-atom允许的字符集合比大多数人想象的大得多除了字母数字和!#$%*-/?^_{|}~之外还可以包含点号但点号不能出现在开头或结尾也不能连续出现。quoted-string则更宽双引号里几乎什么都能放包括空格、、括号、甚至中文字符。域名部分也不只是“字母数字加点”。RFC 5322允许点分字符串也允许用方括号包起来的IP地址字面量比如user[192.168.1.1]也是合法格式。如果严格按规范完美校验最终你会发现自己不是在写“邮箱格式校验函数”而是在写一个完整的状态机。1.2 常规正则的常见错误网上流传最广的邮箱正则基本长这样^[a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,}$这个正则拦住了一堆合法邮箱也放行了一堆不该放行的地址。拿它去匹配john..doeexample.com这种带引号的地址直接判非法其实这是合规的反过来它允许a..bexample.com这却是非法格式因为连续点号在dot-atom里不被允许。再比如.usernameexample.com有些实现在前面加了个.就放过去了但local-part以点开头是不合法的。还有user-example.com、userexample-.com域名以连字符开头或结尾也不符合域名解析规则但很多正则根本没检查。更麻烦的是长度。RFC 5321SMTP协议那个RFC规定了邮箱地址整体长度不能超过254个字符local-part最长64个字符域名部分最长255个字符但整体加起来仍有254限制。常见正则完全没有长度概念。事实是格式验证只应该是一道最低门槛它的目的是“快速排除明显非法输入”不是“精确判断邮箱是否能收到邮件”。你花一整天写一个100%符合RFC 5322的校验器对业务几乎没有收益。我见过有人用真正的Byacc生成一个巨大的解析器来解析邮箱结果上线一个月它拦下的用户还没它误杀的邮箱多。2. 解析RFC 5322的核心规则2.1 基本语法元素atext、dot-atom、quoted-stringRFC 5322的定义用ABNF写读起来比较费劲。我帮你梳理几个关键术语。首先是atext。这是组成dot-atom的最小单元可选的字符是A-Z a-z 0-9 ! # $ % * - / ? ^ _ { | } ~注意里面没有空格、没有双引号、没有括号、没有逗号、没有冒号和分号。点号本身也不是atext它是dot-atom里的分隔符。dot-atom由一串atext或者用点号分隔的多串atext组成规则要求点号不能出现在开头或结尾也不能连续。所以a.b.c合法a..b非法.a非法a.非法。quoted-string就自由多了。它由双引号包起来可以是qcontent几乎包含任何可打印ASCII字符包括空格和唯一需要转义的是反斜杠和双引号。举例来说john doeexample.com是合法格式a..bexample.com也合法。但是注意绝大部分邮件系统并不希望你真的用这种地址注册因为很多服务端程序不兼容它。范例如下john doeexample.com very.(),:;[]\.VERY.\very\\ \very\.unusualstrange.example.com后面这个例子是RFC 3696里给出的传统合法地址虽然奇葩但语法上成立。2.2 域名部分和地址字面量域名部分有两种写法点分域名和地址字面量。点分域名就是常见的example.com每一段叫sub-domain由字母数字和连字符组成但连字符不能出现在段的开头或结尾。域名部分的最后一个顶层域一般要求至少两个字符但RFC 5322并不强制直接写usermachine也是符合本地网络命名规范的只是现实里几乎不会用。地址字面量是方括号内直接写IP或IPv6地址比如user[127.0.0.1] user[IPv6:::1]RFC 5322对IPv6字面量有完整规定需要在方括号里加IPv6:前缀。这类地址在普通网站注册里几乎不会出现但如果你想做一个严格的解析器就得处理。后端校验时通常会对域名部分使用IDNAInternationalized Domain Names in Applications规则。用户输入中文域名用户例子.中国需要先转成punycode形式再做校验。如果直接拿例子.中国匹配传统的域名正则基本全灭。SMTPUTF8扩展允许UTF-8邮箱地址但那是另一个复杂话题后面再讲。2.3 实际应用中我们该验证哪些规则我个人的工程观点是邮箱格式校验分三层绝大多数业务只需要第一层。第一层是基础语法层检查是否符合addr-spec的大致形态包括local-part字符集、、域名基本结构、长度限制。这是必做的用正则或标准库解析都行。第二层是域名实时校验层解析后面的域名查DNS的MX记录没有MX就查A/AAAA记录。这一步能拦截大量随手乱填的地址比如userasdfghjk123.com格式合法但域名根本不存在。第三层是邮箱存在性校验层通过网络协议去查邮箱是否真的存在常见做法是连接邮件服务器发送RCPT TO命令看服务器是否接受。这一层最不可靠也很容易触发风控或造成性能问题不建议自己做。这个分层思想在后面的实战中会非常有用。你不需要第一层就把所有非法都拦掉那只会把第二、第三层该干的事提前做了还做得特别差。3. 实战实现一个可用的邮箱验证方案3.1 推荐策略分层验证我的方案分三步在生产环境跑了很多年误杀率很低语法检查长度 基础格式。这一步目的是剔除明显垃圾输入。域名检查解析MX或A记录。这一步的目的是验证域名真实存在并且有收件能力。可选的“送达性”提示如果是注册场景通常在发送激活邮件后根据退信结果来标记无效邮箱而不是在用户提交时做昂贵的SMTP检查。先讲语法检查这是本篇文章的核心。3.2 一个足够好又不会过度严格的正则我自己写了不少版本最终留下的实用正则长这样Python风格但可迁移到其它语言import re email_valid_re re.compile( r^(?Plocal[a-zA-Z0-9!#$%*/?^_{|}~\.-]) r(?Pdomain[a-zA-Z0-9-](?:\.[a-zA-Z0-9-])*)$ )这个正则允许的local字符集和atext一致另外允许点号但因为它用的是[...]没有对点号的起始位置做特殊判断。我会在后面的代码里补两个检查local不能以点开头或结尾local不能出现连续两个点域名部分则是每段都要求字母数字连字符且段间用点号分隔。但连字符不能开头或结尾这个规则也需要额外检查。我用一个函数把这些规则串起来def validate_email_syntax(email: str) - bool: if not isinstance(email, str) or len(email) 254: return False match email_valid_re.fullmatch(email) if not match: return False local match.group(local) domain match.group(domain) if len(local) 64: return False if local.startswith(.) or local.endswith(.): return False if .. in local: return False for label in domain.split(.): if len(label) 63: return False if label.startswith(-) or label.endswith(-): return False if not label: return False return True这个函数里加上了RFC 5321对local-part和域名label的长度限制。实测下来它能覆盖绝大多数合法邮箱同时拦截掉a..bexample.com、.aexample.com、a.example.com、-aexample.com这类非法地址。3.3 标准库解析与正则的配合Python标准库email.utils.parseaddr是一个轻量的解析工具但它并不能用来做“验证”它只会尽力拆出名字和邮箱。跑一下你就知道它有多宽松from email.utils import parseaddr print(parseaddr(Not An Email not-an-email)) # (, not-an-email) print(parseaddr(a..bexample.com a..bexample.com)) # (a..bexample.com, a..bexample.com)它把a..bexample.com也当作合法地址返回了这就是为什么不能直接用parseaddr做校验。正确用法是先用它切掉显示名display name再对我们关心的addr-spec部分做正则校验比如from email.utils import parseaddr def extract_email(raw: str) - str: _, addr parseaddr(raw) return addr如果你处理的表单也是“名字 邮箱地址”一起传过来的可以先用parseaddr提取地址再走validate_email_syntax这样用户输入“张三 zhangsanexample.com ”这种带显示名的字符串也能正确处理。3.4 Ruby、JavaScript等其他语言的正则怎么迁移如果你用Ruby正则语法几乎一样EMAIL_REGEX /\A[a-zA-Z0-9!#$%*\/?^_{|}~.-][a-zA-Z0-9-](?:\.[a-zA-Z0-9-])*\z/JavaScript里要注意两点一是\A和\z不支持要用^和$并且记得用u标志处理unicode二是某些环境下\w会匹配中文所以不要用\w做字符类必须显式列出[a-zA-Z0-9_]。普通的/在正则字面量里需要转义成\/其它通用。在Java/Go/C#里也是类似需要注意反斜杠转义。强烈建议把正则编译成常量放在类或模块里不要每次校验都重新编译。3.5 国际化邮箱怎么办用户填张三example.com或者user例子.中国很多老系统直接拒绝了这会让一批真实用户流失。IDN域名的处理思路是先把域名部分用idna库转成ASCII再套用之前的正则。Python里这样处理def to_ascii_domain(domain: str) - str: try: return domain.encode(idna).decode(ascii) except UnicodeError: return def validate_email_with_idn(email: str) - bool: if not in email: return False local, _, domain email.rpartition() if not local or not domain: return False ascii_domain to_ascii_domain(domain) if not ascii_domain: return False return validate_email_syntax(f{local}{ascii_domain})rpartition很关键因为local部分理论上也可能包含比如在引号字符串里但现实情况下我们几乎不会要求支持引号字符串所以从右侧切第一个即可。如果用户输入的是abexample.com这个函数会把local当成ab然后继续校验会让引号字符串通过吗不会因为正则的字符集合里没有双引号所以ab会直接判定非法。这是我故意做的取舍虽然RFC说引号字符串合法但在用户注册这种业务场景下我们并不希望真的启用这种地址支持它只会徒增兼容成本。对于local部分出现中文的情况比如张三example.comRFC 6531/SMTPUTF8允许但现实里很多邮件服务商不支持。我的态度是如果用户填了这类地址可以先允许提交发送激活邮件后等待退信不要在前端把它一刀切掉因为拦截的代价是永远丢了一个用户。当然具体是否支持取决于你的目标用户群体。4. 从验证到送达把好域名这道关4.1 为什么只验证格式不够很多在注册页乱填的人输入的不是随机字符串而是类似asdfqwer.com这样格式完全合法的地址但qwer.com这个域名可能压根不存在。语法校验对此毫无办法。你只能通过域名解析去判断这个域名是不是真实存在的。判断标准很简单查询这个域名的MX记录。MX记录是邮件交换记录指定了哪个主机负责接收该域名的邮件。如果MX记录存在说明该域名至少配置了接收邮件的服务器。如果MX不存在再查A/AAAA记录因为有些小型域名只配置了A记录也照样接收邮件用A记录做MX fallback是不规范但存在的做法。4.2 DNS MX 记录检查Python里可以用dnspython库也可以用标准库直接做系统级DNS查询。dnspython更可控我一般这么写import dns.resolver def has_mail_exchanger(domain: str, timeout: float 3.0) - bool: resolver dns.resolver.Resolver() resolver.timeout timeout resolver.lifetime timeout try: answers resolver.resolve(domain, MX) except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer): try: resolver.resolve(domain, A) except Exception: return False return True except Exception: return False return len(answers) 0如果你不想引入dnspython在Unix系统上也可以直接调用nslookup或dig命令但解析输出很繁琐而且容易受到系统配置影响。我更推荐直接用库。注册场景中我通常把这个检查做成异步任务而不是同步卡在注册接口里。因为DNS查询一般几十毫秒但特殊情况下可能超时到秒级同步会拖慢注册速度。但如果你的注册量不大直接同步查也没问题最多在异常时放行把判断推后到发邮件阶段。4.3 SMTP连通性测试的陷阱有些人会进一步尝试连接MX主机发送RCPT TO命令来判断用户邮箱是否存在。思路是HELO example.com MAIL FROM: testexample.com RCPT TO: targetexample.com如果返回250说明邮箱存在返回550则不存在。听起来很好用但实操下来全是坑第一很多邮件服务器在收到陌生IP的RCPT TO探测时会直接拒绝或启动慢响应比如Gmail会返回“421 Too many errors”或者干脆不响应误判率很高。第二有些服务器为了反垃圾邮件会对所有RCPT TO返回250俗称“catch-all”你会得到假阳性。第三频繁连接会导致你的服务器IP被列入黑名单影响正常邮件发送。第四SMTP协议本身还规定VRFY命令用于验证用户但绝大多数服务器为了避嫌都禁用了它。我的建议是不要自己写SMTP探测逻辑。如果业务确实需要判断邮箱是否有效建议使用经过市场验证的第三方邮箱验证服务它们维护了大量的域名频率控制、动态IP池和黑名单策略准确率高很多。4.4 邮箱验证服务怎么选第三方服务一般通过API一次性批量验证会返回valid、invalid、catch_all、unknown等状态。选型时注意几个指标指标关注点准确率是否区分真的邮箱和catch-all域名下的随机地址延迟单条验证的响应时间是否可接受成本按次计费还是包月无效条数是否扣费数据安全是否允许传输用户邮箱是否有加密和合规承诺我见过不少团队在注册流程里同步调用第三方验证接口导致注册链路多了几百毫秒。更合理的方案是先做基础语法域名检查保留一个email_status字段注册成功后后台调用第三方慢慢验证再根据结果标记“已确认有效”或“可能无效”。这样用户体验最好。5. 常见问题与排查技巧实录5.1 真实场景里的诡异输入我把自己多年踩过的坑整理成了表格供你快速排查用户输入常见错误判断正确处理usertagexample.com被误判非法很多老正则不支持合法是atext字符user.nameexample.com合法但要注意user..nameuser.example.com被部分正则放过非法local以点结尾.userexample.com被部分正则放过非法local以点开头user-example.com被部分正则放过非法域名段不能以连字符开头userexample-.com被部分正则放过非法域名段不能以连字符结尾userexample.c多数正则拦截理论上允许但实际可要求至少两位顶级域user[192.168.1.1]被正则拦截格式合法但现实注册基本不会出现quotedlocalexample.com被正则拦截RFC合法但建议不开放用户例子.中国被正则拦截需IDN转换后校验userexample.com.被正则拦截末尾多一个点用户手误不建议硬放行空字符串 / 只含空格被正则拦截直接拒绝并提示必填usercom域名只有单个标签现实中很少有效建议要求至少包含一个点仔细看这个表你会发现很多边界情况的处理取决于产品策略而不是纯粹的技术对错。例如userexample.c虽然语法上不算错但我建议在注册系统里拒绝因为它没有常用顶级域极大概率是误填。5.2 前端校验和后端校验的角色分工前端校验只是提升用户体验后端的校验才是安全底线。我在项目里通常这样配合前端JavaScript失去焦点时快速校验格式并提示“邮箱格式似乎不正确”让用户及时修改。后端则要重新做完整的语法检查和域名检查因为攻击者可以绕开前端直接POST。后端如果只依赖一个正则等于把整个注册接口的安全寄托在客户端代码上这是大忌。另外建议在服务端对邮箱做规范化处理使用小写保存虽然local-part理论上是大小写敏感的但绝大多数邮件服务不区分统一小写更容易查重去除首尾空格对于Gmail这类支持点号无感的服务不建议做复杂归一化避免误伤后端保存时统一小写但要注意理论上UserExample.com和userexample.com可能不是同一个邮箱实际几乎可以等同处理。如果为了100%严谨可以在代码注释里说明这个取舍但不要真的去区分大小写建两套用户否则用户会迷惑。5.3 验证逻辑的测试用例模板每次写完邮箱校验函数我至少会跑下面这些用例。你可以直接抄走作为单元测试valid_cases [ simpleexample.com, very.commonexample.com, userfilterexample.com, user-1example.org, user.nametagsortingexample.com, xexample.com, example-indeedstrange-example.com, test3com.com, userexample.c, ] invalid_cases [ abc, abc, example.com, .userexample.com, user.example.com, user..nameexample.com, user-example.com, userexample-.com, user.example.com, userexample..com, userexample.com., , , ]这里我把userexample.c放在valid里是为了测试你的校验器是否可以灵活配置顶级域策略。生产环境我通常会加一个TLD白名单或黑名单而不是死板地要求2位以上因为现在顶级域有几百种.tech、.top、.icu等新顶级域也能收邮件。5.4 实现决策树最后给一个我在团队分享时画过无数次的决策树写成文字版输入为空是提示必填。长度超过254是拒绝。没有或个数大于1是拒绝。用右侧第一个切分开local和domain。local超过64或包含非法字符/点号使用错误是拒绝。domain包含非法字符或标签长度超标是拒绝。域名能否解析出MX/A记录否拒绝或标记“可能无效”。最终提交后发送验证邮件根据退信情况兜底。按照这个顺序做逻辑清晰排查起来也方便。千万不要把DNS检查、SMTP检查全部塞进一个正则里那不是工程那是行为艺术。5.5 一个容易被忽略的细节验证邮件的发送逻辑如果你只做格式校验最后发给用户的邮件被退信那前面所有校验都白搭。我建议在发送验证邮件时记录发送状态并且维护一个“邮箱无效”的重试策略。常见做法是首次发送失败后在用户表中标记email_verification_failed次日或第3天自动重试一次如果连续3次失败就向用户展示“更换邮箱或重新发送”的入口。另外要注意某些邮件服务商对号地址可能不支持比如有的企业邮箱会把usertagexample.com拒收这种情况不是我们的格式问题而是对方服务器问题。碰到个别用户反馈收不到验证邮件时查一下退信日志而不是怀疑自己的正则写错了。我自己踩过最离谱的一个坑是某用户邮箱是testlocalhost格式真的通过了域名单标签DNS检查也直接跳过了查询localhost会报错我们默认放行结果系统给localhost发了封邮件自然石沉大海。后来我在域名检查前先拦截了保留域名和裸主机名才解决这个问题。像localhost、test这类特殊域建议直接加入拒绝名单。这套验证体系跑到现在注册页的无效提交率下降了大概30%最主要功劳其实是DNS检查而不是正则。我一直在跟团队强调格式验证是必要的但不应该是唯一的验证手段邮件验证码/退信监控才是最终的确认机制。真正确认这个邮箱归用户所有唯一的办法是发送带一次性链接或验证码的邮件让用户回点/回填。在这一点上省事后续的账号安全、触达率、数据质量都会出问题。再分享一个小技巧在保存邮箱的数据库表里给邮箱列加上唯一索引但统一存小写。你可能会问如果用户执意要区分大小写怎么办在真实业务里99%的用户不会故意区分这个索引会帮你拦住大量重复注册的脏数据。邮箱验证这条线从格式到解析从DNS到SMTP每个环节都有妥协和取舍搞明白RFC 5322的原始定义能让你做出更清醒的决策而不是死记一个正则。希望我的这些经验能帮你少走弯路。