AuthKit 测试邮箱域名：哪些能通过送达性检查？

AuthKit 在用户注册和邀请环节会校验邮箱域名的送达性，无法接收邮件的域名会被直接拒绝。对于使用种子数据的环境和持续集成（CI）测试套件来说，这一机制意味着不能随意填写测试邮箱——一旦域名被判定为不可送达，注册和邀请流程就会中断。本文梳理 AuthKit 的校验逻辑，并给出能让测试环境保持通过的保留测试域名选择思路。

AuthKit 为什么要做域名送达性检查

AuthKit 的核心判断很简单：一个邮箱域名如果根本无法接收邮件，那么基于该邮箱的注册和邀请就没有实际意义。系统会在注册和邀请流程中拦截这类域名，避免无效账号进入系统，也减少后续邮件投递失败带来的噪音。

这一设计对生产环境是合理的防护，但对测试环境提出了额外要求。种子数据和 CI 套件通常需要批量创建用户、发送邀请，如果使用的邮箱域名被 AuthKit 拒绝，测试就会在第一步失败。因此，选择能够稳定通过检查的保留测试域名，是搭建可重复测试环境的前提。

邮箱域名送达性检查通常包含几个层次：语法校验（是否符合 RFC 5322 格式）、DNS 层面的 MX 记录查询（域名是否声明了邮件交换服务器）、以及可选的 SMTP 探测（尝试连接服务器验证收件人是否存在）。AuthKit 的判断重点落在后两者，即域名是否具备接收邮件的实际能力，因此单纯格式合法的地址仍可能被拒绝。这类检查在业界常被称为 email verification 或 email deliverability validation，多数身份认证服务会把它作为反滥用与数据质量治理的一环。

从实现角度看，DNS 查询存在缓存与超时问题，SMTP 探测则可能被目标服务器限流或拒绝，因此校验结果并非绝对稳定。这也是测试环境需要固定使用已知可通过的域名、而非依赖随机域名的重要原因。

保留测试域名的作用

保留测试域名（reserved test domains）是专门为测试场景预留的域名，它们不指向真实的邮件接收系统，但在送达性检查中被视为可用。使用这类域名的好处在于：

• 可预测性：域名状态稳定，不会因为 DNS 配置或邮件服务商策略变化而突然失效
• 隔离性：测试流量不会误发到真实用户邮箱，避免污染真实数据
• 可重复性：CI 套件每次运行都能得到一致结果，减少偶发失败

需要说明的是，原始素材并未逐一列出 AuthKit 认可的具体域名清单，因此在实际项目中应以 AuthKit 官方文档或控制台提示为准，而不是依赖社区流传的域名列表。

保留域名（reserved domain names）是 RFC 2606 与 RFC 6761 中定义的一类特殊域名，包括 .test、.example、.invalid、.localhost 以及 example.com/example.net/example.org。这些域名被保留用于文档示例与测试，永远不会被注册为真实域名，因此不会误发邮件到真实用户。它们的定位是「安全但通常不可送达」——是否被某个服务的送达性检查放行，取决于该服务是否对保留域名做了白名单处理。

与之相关的是 一次性邮箱域名（disposable email domains）黑名单机制：许多服务会主动拒绝 Mailinator、10minutemail 等临时邮箱域名以防止滥用。测试时若使用此类域名，往往会被与「不可送达」一并拦截。因此选择测试域名时需要区分三类状态：保留域名、一次性邮箱域名、真实可送达域名，AuthKit 对它们的态度可能各不相同。

在 CI 与种子环境中落地

把测试邮箱域名纳入工程实践，可以从几个方面入手。首先，在种子脚本和测试夹具中统一使用保留测试域名，而不是随手拼接随机字符串。其次，在 CI 配置中把邮箱域名作为环境变量管理，便于在不同环境间切换。

另一个容易被忽略的点是邀请流程。AuthKit 对注册和邀请都做校验，如果测试只覆盖注册而忽略邀请，可能在邀请相关用例上踩坑。建议在测试套件中同时覆盖这两条路径，确保域名选择在两种场景下都成立。

测试夹具（test fixtures）指在测试运行前预置的固定数据集合，包括用户记录、邀请令牌等。在涉及邮箱的夹具中，把域名部分抽成常量或环境变量（例如 TEST_EMAIL_DOMAIN），可以让同一套夹具在不同环境复用，也便于在 AuthKit 调整校验策略时集中修改。

种子数据（seed data）则是为开发或演示环境初始化数据库的脚本，通常包含若干示例账号。种子脚本若硬编码随机邮箱，一旦域名被拒就会导致整个初始化流程回滚。更稳健的做法是让种子脚本幂等——重复执行不产生重复记录，并在域名校验失败时给出明确错误提示，而不是静默中断。此外，可在 CI 中增加一个最小化的「冒烟」用例，先验证测试域名能成功完成一次注册，再运行完整测试套件，从而把域名问题与业务逻辑失败区分开。

常见误区

一个典型误区是认为任意格式合法的邮箱都能通过检查。AuthKit 的判断依据是域名能否接收邮件，而非邮箱字符串是否符合 RFC 格式。使用 example.com 这类保留域名时，需要确认其在 AuthKit 的判定中是否被视为可送达，而不是想当然地认为格式正确就万事大吉。

另一个误区是在生产配置中混入测试域名。测试域名应当严格限定在开发、测试和 CI 环境，避免真实用户注册时使用无效域名，导致后续通知邮件无法送达。

小结

AuthKit 的送达性检查是一道务实的产品防线，但它要求测试环境在邮箱域名选择上更加谨慎。使用保留测试域名、统一管理配置、同时覆盖注册与邀请路径，可以让种子环境和 CI 套件保持稳定通过，而不必反复排查因域名被拒导致的失败。具体可用域名请以 AuthKit 官方信息为准。