Email Verification API 为何选 DNS TXT 做发现与 .well-known 方案全对比【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verificationEmail Verification API邮件验证 API简称 EVP正在改变邮箱验证码的玩法用户不必再去邮箱里翻找 OTP 验证码浏览器会直接出示一封由邮件服务商签名、可加密验证的邮箱验证令牌EVT。而这套流程有一个关键前置问题——浏览器如何知道谁有权为这个邮箱域名签发令牌规范最终选择了DNS TXT 记录来做发现Discovery而不是业界常见的.well-known文件方案。这篇文章讲清楚两者各自动作以及规范为什么这样选。先看懂发现要解决什么问题一次自动邮箱验证的完整链路在 README.md 中画成了一条时序图核心步骤是用户已登录邮件服务商服务商通过 Login Status API 向浏览器上报logged-in状态网站表单里埋一个带nonce的隐藏输入框autocompleteemail-verification-token用户在自动填充候选项里选中一个邮箱地址浏览器发现该邮箱域名对应的签发者Issuer← 本文主角校验用户确实在该签发者处登录请求签发 EVT 令牌提交表单时令牌自动填入隐藏框网站完成验证第 4 步就是发现输入usercorp.example浏览器要回答应该向哪个网站要验证令牌。答案有两种形态——签发者就是邮箱域本身或者被委托给另一个站例如 Gmail 把gmail.com的令牌签发委托给accounts.google.com。规范原文见 README.md 的 3.2 Issuer Discovery 一节。DNS TXT 发现机制是怎么工作的规范约定的做法极简邮件服务商提前在邮箱域名的 DNS 里放一条 TXT 记录声明自己的签发者_email-verification.email-domain.example TXT ississuer.example浏览器选中邮箱后对该邮箱域名发起一次 DNS 查询拿到iss值发现即完成。整个过程的特点是不需要运行任何 Web 服务不需要访问邮箱域名的 HTTP 站点天然支持邮箱域 ≠ 签发者的**委托delegation**场景查询结果可被各级 DNS 按 TTL 缓存服务商几乎没有额外负载.well-known 方案为何落选做发现.well-known是 Web 上通用的约定路径https://域名/.well-known/...很多协议用它暴露元数据。用它做发现看似顺理成章在https://邮箱域/.well-known/email-verification里写明签发者即可。但有四个硬伤1. 先有鸡还是先有蛋的信任问题.well-known文件放在邮箱域名的 Web 服务器上。可问题是在发现之前你并不信任这个站点——它只是自称拥有该邮箱域名的服务器。你要先无条件信任一个 HTTPS 响应才能知道该信任谁。而 DNS TXT 可以把信任锚定在域名解析层必要时叠加 DNSSEC信任链更短。2. 很多邮箱域名根本没有 Web 服务器大量邮箱域是纯邮件域只有 MX 记录没有指向任何网站的记录。要求它们额外部署一个.well-known端点等于强迫邮件团队去做 Web 运维而 DNS 记录本来就是他们的日常操作加一条 TXT 记录的成本接近于零。3. 邮件生态的既有先例SPF、DKIM、DMARC、MTA-STS 这些邮件安全标准全部基于 DNS 记录。邮件服务商对这些操作早已驾轻就熟EVP 沿用同一模式学习和运维成本最低。4. 隐私与可观测面每次获取.well-known文件都是一次完整的 HTTPS 请求携带 TLS 指纹、请求头等可观测信息。规范对隐私要求极严见 index.bs 的 Blinding the Issuer 一节获取 well-known 文件不得泄露验证方网站的来源约束面更大。DNS 查询只向解析器暴露查了哪个域且可配合 DoH/DoT 加密——index.bs 的 DNS Security 一节明确建议浏览器使用 DNS-over-HTTPS/TLS并在可用时校验 DNSSEC 签名。关键反转两种机制其实都用上了 读完整份规范会发现一个有趣的细节——EVP 并没有抛弃.well-known而是让它与 DNS TXT 分层分工步骤机制回答的问题① 发现签发者DNS TXTiss这个邮箱域名归哪个签发者管② 拉取签发者元数据https://{issuer}/.well-known/email-verification令牌发放端点和支持的签名算法是什么③ 拉取账号列表https://{issuer}/.well-known/web-identity该用户在此签发者下登录了哪些账号逻辑很直白谁负责是委托问题交给最擅长表达委托的 DNS怎么对接是端点问题交给最擅长描述服务的 Web 路径。元数据获取的具体约定见 README.md 的 3.5 Issuance Request 一节。DNS TXT 与 .well-known 全对比表维度DNS TXT.well-known 文件信任锚可叠加 DNSSEC信任链短依赖对邮箱域 Web 服务器的既有信任委托支持原生iss可指向任意签发者需先建立对邮箱域站点的信任前置条件只需 DNS 管理权邮箱域必须有可用的 Web 服务器缓存与负载各级 DNS 按 TTL 缓存近乎零请求每个浏览器都要发起 HTTPS 请求生态先例SPF / DKIM / DMARC / MTA-STSOAuth、WebFinger 等 Web 标准隐私暴露面仅暴露查询的域名可加密完整 HTTPS 请求特征运维成本加一条 TXT 记录部署并维护一个 Web 端点适用定位委托与发现第一层服务元数据第二层结论单看发现这一层DNS TXT 在信任模型、委托表达、运维成本和生态惯性上全面占优而 EVP 的最终答案不是二选一而是各放各的层。对三类角色分别意味着什么 邮件服务商一条 TXT 记录 两个.well-known元数据端点签发者元数据、web-identity即可完成接入网站开发者表单里加一行带nonce的隐藏输入框即可令牌拿不到时自动退回传统 OTP 流程用户行为零变更想动手体验按 HOWTO.md 的指引在 Chrome Canary 145 中启用Email Verification Protocolflag 即可实测更多设计细节可查阅 QUESTIONNAIRE.md安全与隐私自审问卷和 CONTRIBUTING.md参与贡献指南。一句话总结Email Verification API 用DNS TXT 记录做签发者发现、用.well-known做端点元数据前者解决归谁管后者解决怎么连。这套分层设计让邮箱域名以零 Web 运维成本接入同时复用了 SPF/DMARC 时代积累的 DNS 信任经验——这正是 DNS TXT 在发现之争中胜出、又与.well-known和平共处的真正原因。【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考