邮箱格式校验
整批先看汇总表，再逐段拆解本地部分与域名，指出违反的具体规则而非只给通过与否。
这一页只做一件事：按 RFC 5321 与 RFC 5322 的 ASCII 语法子集判断一个地址写得对不对。它会剥掉圆括号注释、识别 Foo <a@b.com> 与 "Foo Bar" <a@b.com> 两种显示名形式、把本地部分按 dot-atom 与 quoted-string 两支分别检查、按标签逐个检查域名，并给出违规清单（区分 error 与 warn）。本地部分受 §4.5.3.1.3 的 64 字节上限与点号位置约束（首尾不能是点、不能有连续点）；字符集按 RFC 5322 §3.2.3 的 atext。域名按 LDH 规则逐标签检查（标签 ≤63 字节、连字符不在首尾）。
它不做的事同样是设计决定：不联网、不查 MX、不查域名是否存在、不发送任何请求，也不做去重或分组统计，因此「通过」只表示语法读得通，永远不表示这个邮箱存在或能收到信；生产邮件列表粘贴在这里，得到的也只是字符串判定结果。所有比较都在浏览器本地完成，输入不出本机；页面上没有复制到剪贴板的按钮，只有把当前可见行导成 .txt 的下载入口。
邮箱格式校验怎么用
- 先看汇总表，再点行展开明细：多行输入按非空行计数（空行与纯空白行不占额度），一批最多 200 行，超了整批不判定并在提示条里写当前行数。汇总表一行一个地址给 6 个读数：地址、结论、违规条数（错与警分开）、域名形态、别名特征、拼错猜测；该地址的结构、显示名与注释段数、本地部分与域名的分段读数、逐条违规与逐条别名特征都在这一行的 details 里，点行就地展开，也可以用「展开全部行明细 / 收起全部行明细」批量切；打字或切开关触发重算后，之前展开的行按行号继续展开。规则口径写在代码注释里，每条判定的规则名、error 还是 warn、以及规范依据都逐行列在该地址的明细中。圆括号注释会被剥掉并单独记一次 warn，因为规范允许但绝大多数站点表单不接受。
- 只看通过或只看不通过：汇总表上方那三档（全部地址 / 只看通过 / 只看不通过）默认「全部地址」，过滤只决定表里显示哪些行；读数条里的地址数、通过数、不通过数始终是这一批的全量口径，面板标题旁另写「当前显示几行」，两处数字来自同一次计算，切开关时一起刷新。
- 三个开关各自改掉哪块 DOM：「按 RFC 5321 更严的口径」默认关：打开后引号本地部分、单标签域名（a@localhost）、地址字面量、圆括号注释、下划线标签、数字开头标签从 warn 改判 error，结论、违规条数与读数条的通过/不通过跟着一起重算。「提示疑似拼错的域名」默认开：关掉后明细里不再给拼错建议，汇总表那一列写「未开」。「列出该地址可用的正则」默认关：关掉时两条正则与「不要用的写法」对照整块不进 DOM；打开后每个地址的明细里多 3 行，并对该行地址实测一次匹配结果。输入内容切换开关时全部保留，下载 .txt 只导当前过滤可见的那些行（含逐条违规与别名说明）；本页没有复制到剪贴板按钮。
- 默认记 warn、严格口径改判 error 的那几条：带引号的本地部分（"a b"@example.com）在规范里合法，页面默认按 warn 标记并在严格口径下判错，非 ASCII 的本地部分（用户@example.com）属于 RFC 6531 SMTPUTF8 扩展，本站一律按 ASCII 口径拒绝并在说明里点出这条 RFC。RFC 1123 §2.1 允许标签以数字开头，这点与更早的 RFC 952 不同，默认口径按放宽后的处理（记 warn），打开严格口径开关后改判 error。保留域按 RFC 6761 的特殊用途 TLD 加上 RFC 2606 保留的 example.com/.net/.org 判定，命中时给 warn 并说明「永远不可能投递成功」。
- 拼错猜测、别名特征与正则清单：两个附带功能各自绑定工具条上的一个开关：一是把常见拼错的域名对着 32 个常用域名表做编辑距离猜测（gmial.com → gmail.com，阈值 2，域名不足 6 字符时只接受距离 1），这个开关默认开着，汇总表那一列因此要么是「→ 某个常见域（差几处）」、要么是「无」、「不适用」（没有域名或地址字面量时）；把它关掉之后那一列如实写成「未开」，明细里也不再给拼错建议，而不是留一片空白让人误以为没有。二是标出别名特征（plus 后缀、点号折叠、noreply 之类、一次性邮箱服务名表里那 15 项），汇总表给项数与名称、明细给每条的理由；这些只是字符串层面的标记，不查服务商是否仍支持该行为。「列出该地址可用的正则」默认关着，两条正则整块不进 DOM；开着时每个地址的明细里多出 3 行（宽松实用版、严格版、以及「不要用的写法」那条对照），并且前两行会真的在浏览器里对这一行拆出的地址跑一次 test() 给出匹配/不匹配——只有超过 256 字符（RFC 5321 的路径上限）的行不跑，页面会写明原因，避免在超长输入上触发回溯。
常见问题
为什么不提供 SMTP 检查
那是有意不做的。要确认一个邮箱真实存在，只能连对方的 MX 发起 SMTP 会话并发 RCPT TO，这需要服务器侧的网络与 IP 信誉，还会把地址送到第三方主机上；在一个纯前端的静态页面里做不到，也不该做。此外大量收件人检查会被人当作验证工具，属于滥用面很广的功能。本页的口径是：语法与结构在本地判完就走，存在性由你自己的发送日志或退信处理来判断。
a@192.168.1.1 语法是合法的吗
拆开看有两半。「192.168.1.1」作为一个点分标签序列，每个标签都满足 LDH 规则、总长也合法，按 RFC 5322 §3.2.3.2 的 dot-atom-text 读得通，所以语法层面它是个域名；这也是为什么它看起来「能过」——汇总表那一栏的域名形态会写成「点分数字」而不是「IP 字面量」，两者是两回事。但 RFC 5321 §4.5.3.1.6 明确地址字面量要写成 [192.168.1.1] 这种方括号形式，不带括号时收件域会被当作主机名去解析；而这个私有网段地址没有 MX、也不可能被公网投递，所以永远收不到信。这一页因此把它判成不通过（顶级标签全是数字、单字符 TLD 都不合法），方括号形式则给 warn 并说明它不是域名。按 §4.5.3.1.6 它只适合没有域名注册的场景，主流服务商基本不接受，严格口径会拒绝它。前者来自 RFC 5322 的语法定义，后者来自 RFC 5321 的传输规则与 RFC 1918 的地址范围，两条结论不在同一层。
xn-- 域名是怎么还原成中文的
页面里自带一个 RFC 3492 解码器：先按最后一个连字符把基本码位段与扩展段分开，再用推广的整数编码逐段算出插入位置与偏移，用 adapt 函数（§6.1）更新 bias，把码位逐个插进输出串。它做的是纯解码与展示，不执行 IDNA2008 的 A-label 校验，也不做大小写折叠、禁止码位检查，所以能解出一个「看起来是中文」的标签不等于这个域名在注册局那里合法。解出来的标签会在那一行明细里以 warn 说明「解码为什么」，并同时在「域名」那一行给出解码后的写法；解不出来的（空负载、非法字符、溢出、变长编码段读到一半就断）不会另列清单，而是变成该地址明细里一条 error 级、规则名为「punycode 解码失败」的违规行，这一行的结论因此读作不通过。注意汇总表的「域名形态」列只看有没有 xn-- 开头的标签：解得开解不开都写 punycode，所以那一列是形态读数，不是合法性判定。
对应功能编号 #137无需安装，手机端同样可用按 Ctrl + K 换工具