格式检查排在最前面，但它本身什么也证明不了
验证首先把 @ 前的本地部分与之后的域名拆开，再用实际的格式规则检查这个结构。缺失域名、非法字符、断裂的分隔符，都会在触网之前就被拒绝。
格式通过是必要的，但并不能证明邮箱确实存在——任何看起来合理的字符串都能通过。如果你只需要格式和域名这两项，更轻量的邮箱校验器就止步于这一阶段和下一阶段，不会消耗完整的 SMTP 查询。
邮箱验证工具
验证邮箱地址
在 2 秒内验证任意邮箱地址的语法、域名健康状况、MX 记录与 SMTP 送达能力。99.9% 准确率，每月 600 个免费积分，另外每天登录还可再得 20 积分。
验证邮箱地址究竟意味着什么？
验证邮箱地址，就是在你依赖这个地址之前，先证明发往那里的邮件确实有机会送达。一个看起来像邮箱的字符串——@ 符号正确、域名看似合理——仍然可能是拼写错误、已注销的账户，或者根本没有邮件服务器的域名。
BillionVerify 对单个地址执行完整检查：语法与结构、域名与 MX 解析、针对真实邮箱的实时 SMTP 握手，以及一次性邮箱、角色账户、Catch-All 等风险标记。结果告诉你应该发送、跳过还是复核——而不只是文本格式是否正确。
这与只做语法检查完全不同。通过格式规则并不能证明服务器会接受发往该地址的邮件——只有实时的 SMTP 通信才能证明这一点。本页面的免费使用已包含这一真实的 SMTP 步骤，无需账号。
邮箱地址验证的工作原理
您提交的每个地址都会自动执行四个验证步骤。
格式检查
验证邮箱语法，检测常见拼写错误或格式异常的地址。
域名查询
检查域名是否存在，并解析 MX 记录，确认可以投递邮件。
SMTP 握手
连接邮件服务器，测试邮箱是否接受入站邮件。
风险评分
对地址的一次性邮箱、角色账户、Catch-All 与垃圾邮件陷阱风险进行评分。
什么时候需要验证邮箱地址
当地址错误的代价是退信、域名信誉受损或消息浪费时，快速的单地址检查就物有所值。
在发送重要邮件之前
经过验证的地址可以避免账单、密码重置邮件或必须送达的一次性消息出现硬退信。发送前先检查一次。
用户注册或提交表单之后
拼写错误和一次性邮箱都能躲过格式检查。在提交时进行验证，能让你的用户表和 CRM 从第一天起就保持干净。
导入旧名单或购买名单之前
存放时间较久的联系人名单几乎总会包含已注销的邮箱。在启动完整的批量运行之前，先在这里抽样检查一下。
在构建注册流程或 CRM 集成时
在本页面预演完整的验证结果——语法、MX、SMTP、一次性邮箱、角色账户——待逻辑确认无误后，再通过 Email Verification API 调用同一套验证流程。
单个地址验证与其他邮箱验证工具有何不同
本页面用于交互式单地址检查——不是批量任务、不是 API、也不是免费工具（DNS / SPF / DKIM）。
需要即时结果时，在这里验证单个地址；如果你要解决的问题不同，请使用下方的专用工具或批量工具。
| 工具 | 功能说明 | 适用场景 |
|---|---|---|
| 电子邮件验证器 | SMTP 邮箱全面检查及所有风险标记 | 当送达率和发送安全至关重要时 |
| 邮箱检测器 | 同样是完整的 SMTP 与风险标记引擎，以诊断面板的形式呈现 | 希望在一个结果页面看到全部信号时使用 |
| 免费邮箱检测器 | 标记 Gmail、Yahoo 等免费个人网页邮箱提供商 | 用于线索评分与 B2B 域名检查，而非「免费验证」本身 |
| 邮箱校验器 | 仅做格式与 MX 检查，不进行 SMTP 握手 | 只需要快速筛查语法与域名时使用 |
| 一次性邮箱检测 | 标记临时和一次性邮箱 | 适用于注册表单与线索采集，一次性邮箱会拉低数据质量 |
| 退信邮箱检测器 | 专注于不可送达与硬退信风险 | 发送前的名单清理，用于控制退信率 |
| Catch-All 验证器 | 检测接受任意本地部分邮件的域名 | 当 SMTP 接受结果本身不足以证明邮箱真实存在时使用 |
| 角色账户检测 | 识别 info@、support@ 等通用地址 | 个人收件箱转化率更高的 B2B 外联名单 |
| 邮箱列表清洗 | 对粘贴或 CSV 上传的名单运行同一套验证流程 | 当一个地址不够用，需要一份清洗后的文件时使用 |
| 反向电子邮件查找 | 从电子邮件地址查找上市公司所有者和公司背景信息 | 线索研究和未知发件人审核 |
| 电话号码验证器 | 验证电话格式、国家/地区、类型和 E.164 输出 | CRM 外联前电话清理 |
如何解读验证结果
Valid（有效）表示邮箱接受了 SMTP 探测——在大多数情况下可以放心发送。Invalid（无效）表示存在永久性失败，如格式错误、没有邮件路由或邮箱被拒绝——不要发送。Catch-all 表示该域名接受任意本地部分，因此 SMTP 无法证明这个特定的人确实存在。
Disposable（一次性）和 role（角色账户）标记描述的是「是否合适」，而不是「能否送达」——一个临时邮箱或共享的 info@ 地址仍然可能接受邮件，但并不适合作为长期联系人。请把 Unknown（未知）当作「稍后重试」，绝不要当作「可以放心发送」。
从地址到答案
验证一个地址时，究竟检查了什么
一个可信的答案是分层构建起来的。每一层消除一种不确定性，前面的层级不能宣称拥有只有后面网络检查才能提供的证明。
MX 记录证明该域名至少能够接收邮件
接下来，会解析该域名的邮件路由（MX）记录。它告诉任何发件方，哪台服务器负责处理入站邮件。没有可用的 MX 记录，就意味着无论地址本身写得多么正确，该域名都无法接收正常邮件。
这是域名级别的证据，而非邮箱级别的证据。一条 MX 记录背后可能挂着成千上万个真实收件箱、别名和已废弃的账户——因此一条正常的邮件路由只是「允许继续」，而不是最终结论。
SMTP 是唯一真正测试具体邮箱的步骤
决定性的一步是与接收服务器建立真实的 SMTP 会话，就你提交的确切地址进行询问——不发送任何消息、链接或会落入收件箱的内容。它会充分解读服务器的响应，从而区分「已接受的收件人」与「永久拒绝」或「结论不明的临时拒绝」。
这正是为什么加入 SMTP 的验证能回答一个比单纯格式或 MX 更精确的问题：接收系统当前是否接受发往这个地址的邮件？临时封锁、灰名单和服务商策略会被标记为「未知」，而不会被强行归入错误的有效或无效。
风险标记与状态并行，而不是替代状态
结果状态
把验证结果转化为决策
验证结果不是一个单一的质量分数，而是一份精简的证据摘要，用来支持发送、跳过、重试或复核的决策。
Valid（有效）：可以正常放心发送
Valid（有效）结果表示邮箱在检查时接受了 SMTP 探测。只要没有其他风险标记与你的受众策略冲突，就可以支持正常发送——但它并不能保证收件人会打开邮件，也不能保证对方同意接收。
把 Valid 当作一个「路由事实」，再在此基础上应用你自己的同意与分群规则。
Invalid（无效）：发送前先停下
Invalid（无效）源自确定性的失败——结构错误、没有可用的邮件路由，或收到接收服务器的永久拒绝。仍然发送只会带来本可避免的硬退信，以及 CRM 或用户表中的一条脏记录。
只有在能从源头确认正确地址时，才去修正明显的拼写错误。如果整份文件充满失败结果，保留原始值，改用邮箱列表清洗来处理，而不是逐个地址去猜。
Risky（风险）：邮箱可能接受邮件，但需要复核原因
Risky（风险）涵盖 Catch-All 域名、确认过的滥用记录等情形——在这些状态下，SMTP 可以接受探测，却无法证明背后确实有一个具体的人。Catch-All 验证器解释了为什么 Catch-All 接受是域名层面的行为，而不是对个人的证明。
正确的应对方式取决于你最初为什么收集这个地址。注册表单可能会直接拒绝它；B2B 名单则可能把它留在待复核的分组，而不是与已确认的联系人混在一起。
Unknown（未知）：诚实地承认「无法判断」
Unknown（未知）表示接收方服务商超时、推迟了请求，或返回了一个既不能证明接受、也不能证明拒绝的响应。它绝不会被悄悄升级为 Valid。
请稍后重试；如果某个域名的 Unknown 结果不断累积，可以用邮件送达率测试检查发件方的整体配置。
实用工作流
验证邮箱地址的简单工作流
验证最好被当作一小串决策，而不是复制进表格后就被遗忘的一个标签。
- 1
在即将使用地址时再验证
邮箱状态会变化——员工离职、域名更换服务商、临时故障恢复。地址进入重要流程时就检查一次；在发起活动之前，也要重新检查旧记录，而不是信任一个过时的结果。
对于单个联系人，本页面就是完整的免费诊断工具。对于实时的注册表单或 CRM 事件，邮箱验证 API可以在你自己的应用内返回同样的决策字段。
- 2
不要把「可送达」和「想要」混为一谈
先判断这个地址能否接收邮件，再单独判断它是否适合这个特定的受众群体——一个可送达的 Gmail 地址，可能同时是一个优质的消费者线索，也是一个较弱的企业域名线索。
把技术状态和业务决策存成两个独立字段，这样定向策略的调整就不会覆盖原始证据。
- 3
为不确定的结果分流，而不是靠猜
至少保留三个分组：发送、屏蔽、复核。没有禁用标记的 Valid 地址进入发送流程；永久性失败进入屏蔽；Catch-all、一次性和 Unknown 结果则保持可见，直到有其他信号解决它们。
这能同时保护决策的两端——既避免发给已知失败的地址，也不会删掉那些只是返回了不确定结果的联系人。
- 4
上线前，以整份名单为规模重新验证
单地址检查非常适合排查和抽样。而活动准备是一项名单级别的工作，每一行都需要一致地应用同一套规则。
当同一套验证需要跑在成千上万条记录、而不是一条记录上时，把 CSV 上传到批量邮箱验证。
能力边界
邮箱地址验证无法告诉你的事
清晰的边界能让验证结果更有用——它告诉你这个结果支持哪些决策，哪些决策还需要别的证据来源。
验证不是身份确认
一个接受邮件的邮箱，并不能证明 CRM 中关联的姓名真正掌控这个邮箱、确实在记录所写的地方工作，或者同意被联系。共享别名和被回收的邮箱都可能通过验证，却被错误地归属到某个人身上。
「反向邮箱查询」可以为已知地址补充公开背景信息，但它会区分「观察到的事实」与「推断出的结论」，无法替代同意或归属权的证明。
验证不能保证进入收件箱
SMTP 接受结果描述的是检查那一刻的收件路径。之后的营销活动仍然可能因为发件人信誉、身份认证或内容问题而落入垃圾邮件——这些都不是单地址验证工具所衡量的内容。
在发送前用验证来剔除地址层面的失败情况；如果问题实际出在收件箱送达上，再用邮件送达率测试检查发件方的配置。
Catch-All 接受是域名行为，不是对某个人的证明
Catch-All 域名几乎会接受任意本地部分的邮件，这使得 SMTP 无法证明像 jane@company.com 这样的具体邮箱是一个真实分配的收件箱——该域名可能在接受邮件后，在内部对消息进行路由或直接丢弃。
把 Catch-All 保留为独立的复核状态，而不是直接归入 Valid。具体的检测与报告方式，参见Catch-All 验证器。
验证结果存在时效边界
本页面报告的是检查运行那一刻所能确定的结果——它无法保证地址明天依然有效，也无法保证每个发送网络都会从服务商那里得到相同的响应。
在进行高价值发送之前，重新检查沉寂的联系人；同时避免在短时间内反复探测同一个 Unknown 地址，这样做只会让服务商的响应更加含糊，而不是更清晰。
技术基础
地址验证背后的标准
BillionVerify 保留了互联网邮件本身内建的这种分层：地址结构、域名路由、邮箱接受，是三种不同层级的证据，彼此之间不能相互替代。
RFC 5322 定义的是合法地址，而不是一个存活的邮箱
IETF 的RFC 5322《互联网邮件格式》定义了地址必须遵循的语法规则。通过这套语法只能说明这段输入可以被解释为一个邮箱地址——它从不会联系接收系统。
这也是为什么格式在这里只被呈现为一个信号，而不是被称作完整验证；也是为什么更轻量的邮箱校验器依然适合用来做快速预筛，同时不会被误认为是 SMTP 级别的证明。
RFC 5321 定义了发件方实际测试收件人的方式
IETF 的RFC 5321《简单邮件传输协议》描述了发送与接收系统之间的信封交换过程。收件人的响应比单纯的格式或 DNS 检查携带更有力的证据，但临时状态码和服务商策略仍然需要谨慎解读，而不是被强行归为「是」或「否」。
BillionVerify 保留了这种细微差别，而不是把每个响应都简化成「绿色」或「红色」，因此可重试的 Unknown 状态会与永久性失败明确区分开来。
一个问题，多个专用页面
更多验证方式
准确率相同，入口不同——根据你要检查的地址数量，以及希望如何使用结果，选择合适的工具。
常见问题
1. 邮箱地址验证如何工作？
验证经过四层：语法检查发现格式错误，域名查询确认域名已注册，MX 记录解析验证域名可接收邮件，以及直接 SMTP 连接确认邮箱接受入站消息——全部在 2 秒内完成。
2. 邮箱地址验证的准确率如何？
BillionVerify 通过结合语法验证、DNS 查询、MX 记录检查与直接 SMTP 验证，实现 99.9% 的准确率。这种多层方式能发现基础验证工具遗漏的无效、不活跃与高风险地址。
3. 什么是邮箱地址验证？
邮箱地址验证是确认邮箱地址格式正确、属于具备可用邮件服务器的已注册域名，以及特定邮箱存在并可接收邮件的过程。BillionVerify 会自动运行全部四项检查。
4. 验证器能否检测一次性邮箱地址？
可以。BillionVerify 会将每个地址与 10,000+ 已知一次性与临时邮箱服务数据库交叉比对。即使邮箱技术上可接收邮件，一次性地址仍会被标记为高风险。
5. 邮箱地址验证是否免费？
是。免费计划每月可获得 600 个积分，另外每天登录还可再得 20 个积分，无需信用卡。每次验证均包含完整 SMTP 验证、MX 记录检查与一次性邮箱检测。
6. 你们会存储我验证的邮箱地址吗？
不会。所有验证实时进行，我们从不存储您提交的地址。数据在传输中加密，处理完成后立即删除。
验证邮箱地址
免费验证邮箱地址
每月 600 个免费积分，另外每天登录还可再得 20 个积分。SMTP 验证在 2 秒内确认邮箱是否有效。
每月 600 个免费积分 · 每天登录再得 20 积分 · 2 秒内出结果
99.9%
准确率
Real-time
API 速度
$0.00014
每封邮件
600/mo
永久免费