邮件验证 API 在你发送之前检查邮箱地址的格式是否正确、是否真实存在，以及是否可能接收邮件。你传入一个地址，API 会执行一系列检查（语法、域名、邮箱、风险信号）并返回判定结果。目的是在采集环节就拦截无效地址，而不是等到退信时才发现。
邮件验证 API 检查哪些内容？
验证分层进行，从低成本快速检查到更深入更耗时的检查：
- 语法。 地址的结构是否符合邮件格式规则？此步骤可以捕获缺少
@或多余空格之类的拼写错误。 - 域名和 MX。 域名是否存在？是否发布了 MX 记录？没有邮件服务器的域名无法接收邮件。
- 邮箱存在性。 SMTP 探测会与接收服务器建立会话，检查特定邮箱是否接受邮件，但不会实际投递消息。部分服务商会接受所有地址（catch-all），这会限制此步骤的确定性。
- 一次性邮箱检测。 标记来自临时收件箱服务的一次性地址，这类地址在注册滥用中很常见。
- 角色邮箱检测。 标记
info@或admin@等共享地址，这类地址不绑定到个人，通常不应接收营销邮件。 - 拼写错误检测。 识别可能的拼写错误（例如
gmial.com），并可以建议修正。 - 可送达性评分。 将各项信号综合为一个风险评分或建议，帮助你决定是接受、拒绝还是标记该地址。
为什么要验证地址？
无效地址的代价很高。每次向失效邮箱发送都会产生一次退信，而高退信率会让邮箱服务商认为你没有维护列表，从而拉低你的发件人信誉，并将更多正常邮件推向垃圾邮件文件夹。验证从源头解决这个问题：
- 减少退信。 在发送前拒绝不可送达的地址，使退信率保持在低水平。
- 保护信誉。 干净的列表向服务商表明你发送的对象是活跃的真实收件人，有助于让你远离垃圾邮件文件夹。
- 更干净的注册表单。 在表单中进行实时验证，可以在用户仍在页面上时捕获拼写错误，确保你采集到他们真正想输入的地址。
实时验证还是批量清洗？
有两种使用方式，大多数团队两者都用。
实时验证在采集环节运行，通常是注册或结账表单。用户提交时你验证单个地址，内联显示拼写修正建议，并在明显无效或一次性地址进入数据库之前将其拒绝。这样从第一天起就保持列表的干净。
批量验证针对你已有的列表。如果你导入了联系人、继承了旧列表，或者某个分群很长时间未发送过邮件，就可以在下次活动之前对整个列表运行验证，移除或抑制风险地址。这是对早于实时检查的列表所做的清理。
常见问题
验证能保证邮件一定送达吗？
不能。验证通过移除格式错误、域名失效或明显伪造的地址，大幅降低退信概率，但无法承诺送达。邮箱状态会随时间变化，catch-all 域名会接受所有地址，而收件箱投递还取决于认证和信誉。应将验证视为风险降低手段，而非保证。
验证（validation）和验证（verification）有什么区别？
在大多数产品中，这两个术语可以互换使用。两者都是根据语法、域名、邮箱和风险信号检查地址，以判断是否可以安全发送。如果某个服务商做了区分，请阅读其具体定义，而不是凭假设判断。
SMTP 探测会发送测试邮件吗？
不会。探测会打开一个 SMTP 会话，询问接收服务器该邮箱是否接受邮件，然后在投递任何消息之前断开连接。收件人不会看到任何内容。但 catch-all 服务器会接受所有地址，因此探测并不总能确认特定邮箱是否存在。