在注册会员或咨询表单中输入电子邮箱地址后，页面提示「验证码已发送」，要求你查看收件箱——这样的一次往返，是 Web 身份验证中广泛使用的步骤。2026 年 7 月 8 日，Chrome 面向开发者的博客宣布，一项直接取消这次往返的提案「Email Verification Protocol（EVP）」的源试用（origin trial，一种可在正式站点上限时参与实验的 Chrome 机制）正式启动。本文以 Chrome 官方博客、规范草案及各浏览器厂商的官方立场为依据，梳理 EVP 的概要、用户体验将如何改变、当前浏览器的支持现状，并探讨现阶段是否应引入该技术（文中所述状况均于 2026 年 7 月 12 日确认）。

先说结论 —— 正式引入为时尚早，「持续关注」为妥

先给出判断。**现阶段，EVP 尚未达到应作为正式验证流程引入的阶段。**理由如下。

  1. 目前可用的仅有桌面版 Chrome 的源试用，覆盖 Chrome 150～153。该实验为限时性质，大约持续到 2026 年 9 月上旬
  2. 规范仍在制定中，已正式预告不向后兼容的变更
  3. 该机制必须依赖邮件服务提供商一侧的支持，但公开宣布参与的提供商仅有 Gmail
  4. 其他浏览器尚未跟进：Mozilla 标记为「defer」（暂缓判断），WebKit（Safari）未表明立场

另一方面，EVP 被设计为「叠加式」（渐进增强）：若未收到令牌，便退回到传统验证流程，因此仅仅尝试它的风险被控制得很小。对于验证码环节的流失已成为课题的服务而言，在保留回退机制的前提下参与实验是有合理性的。下面逐一说明。

什么是 Email Verification Protocol

Chrome 官方博客对该提案作如下说明。

The Email Verification API is a proposal that allows the browser to communicate directly with the email provider to verify that the user owns the email address. Users select an email from the browser’s autofill or autocomplete suggestion, submit the form, and the site verifies the email address with the provider without sending an email or interrupting the user’s flow.

（Email Verification API 是一项提案，允许浏览器直接与邮件服务提供商通信，以验证用户拥有该电子邮箱地址。用户从浏览器的自动填充或自动完成候选中选择一个邮箱地址并提交表单，站点便在不发送邮件、不打断用户流程的情况下，与提供商之间验证该地址。）

也就是说，这是一项提案：把此前通过「发送验证邮件并在收件箱中操作」完成的所有权验证，替换为浏览器与邮件服务提供商之间的密码学交互。在收到 W3C TAG（技术架构委员会）的反馈后，规范被拆分为两部分：浏览器一侧的 API 在 WICG（Web Incubator Community Group）中提出，提供商一侧的协议则作为 IETF 的 Internet-Draft 提出。

涉及的三方

  • Verifier（验证者） —— 收集邮箱地址并希望验证它的站点
  • Email Provider（邮件服务提供商） —— 该地址的邮件服务（例如 gmail.com）
  • Issuer（发行者） —— 管理该邮箱账户的服务（例如 accounts.google.com）

验证流程

Email Verification Protocol 的时序图。Verifier site、Browser、Issuer 三方并列。用户登录 Issuer 后，登录状态会通知给浏览器。用户访问 Verifier site，在包含邮箱地址与 nonce 的表单中选择地址后，浏览器与 Issuer 之间通过 DNS 进行 issuer 探索、账户确认与令牌发行，组装出完整的 EVT。用户提交表单后，EVT 被传递给 Verifier site，验证成功并显示「Email validated!」

图 1：Email Verification Protocol 的整体流程（来源：Chrome for Developers 博客，CC BY 4.0）

  1. 用户在表单的邮箱栏中，从自动填充／自动完成候选里选择自己的地址。表单包含一个隐藏字段，携带站点准备的一次性值（nonce）
  2. 浏览器查询该地址域名的 DNS 记录（_email-verification.<域名> 的 TXT 记录）以确定 Issuer，并确认 Issuer 是否持有该地址的有效会话
  3. Issuer 为该地址发行 Email Verification Token（EVT）。浏览器在 EVT 中加入站点的来源（origin）与表单的 nonce，打包成带密钥的 JWT（SD-JWT+KB，RFC 9901）
  4. 提交表单时，该令牌进入隐藏字段并传递给站点，站点一侧对地址、nonce、浏览器与 Issuer 的签名等进行验证

Issuer 一侧的探索与账户确认，复用了既有 FedCM（Federated Credential Management）API 的基础设施——.well-known/web-identity、accounts 端点、Login Status API。

隐私设计

在交互过程中，各方所获知的信息是有限的。官方博客表述如下。

These requests don’t reveal any additional information about the user. The verifier site does not receive information during this step. The issuer only sees a request to verify the user exists; it does not see which site initiated the request.

（这些请求不会泄露有关用户的任何额外信息。在此步骤中，验证者站点不会收到任何信息。发行者只能看到一个确认用户是否存在的请求，看不到是哪个站点发起了该请求。）

此外，当某个地址首次用于验证时，会仅显示一次授权提示，已验证的地址可从 Chrome 的设置（chrome://settings/contactInfo）中管理。

它保证什么，不保证什么

需要注意的是，EVP 所确认的是「用户与该地址的提供商之间持有有效会话」，而非邮件的可达性。

Email verification confirms that the user has an active session with the provider of their email address. It does not verify that your email reached the user.

（邮件验证所确认的是，用户与其电子邮箱地址的提供商之间持有有效会话。它并不验证你的邮件已送达用户。）

欢迎邮件或其后的通知是否送达是另一回事，如有需要，仍将像以往一样通过发送邮件来确认。

用户体验将如何改变

传统的邮件验证大致是以下步骤。

  1. 在表单中输入邮箱地址并提交
  2. 站点发送验证邮件
  3. 用户离开站点，打开收件箱（切换到别的应用或标签页；有时还需在垃圾邮件文件夹中搜寻）
  4. 转抄验证码（OTP），或点击链接（魔术链接）
  5. 返回原站点继续操作

官方博客将这一步骤的问题描述为离开站点的风险。

Existing verification methods, like one-time passwords (OTPs) or email verification links (magic links), require the user to navigate away from your site. This disruptive process can increase the risk of the user, whether a human or an agent, abandoning their session entirely and never completing their authentication process.

（一次性密码（OTP）或验证链接（魔术链接）等既有验证手段，要求用户离开你的站点。这一打断式的流程，无论对方是人还是代理，都可能提高用户彻底放弃会话、最终未能完成验证的风险。）

在 EVP 生效的环境中，这五个步骤将变为以下两步。

  1. 在表单中从自动填充候选里选择自己的邮箱地址（仅在首次使用该地址时，对授权提示应答一次）
  2. 提交表单。提交后，显示「提供商已验证该地址」的小型通知

用户全程一次也不离开站点，也不会发送验证邮件。打开收件箱、转抄验证码、搜寻垃圾邮件文件夹这些工序将从体验中消失。

不过，这一体验有前提条件。

  • **需在同一浏览器配置文件中已登录邮件服务提供商（Issuer）。**若为 Gmail，则需登录该 Google 账户
  • **需从自动填充／自动完成候选中选择地址。**对手动输入地址的支持据称计划在未来版本中提供，现阶段不在范围内

从站点实现方来看，入口是两行 HTML。

<input name="email-address" type="email" autocomplete="email">
<input type="hidden" name="token" nonce="rAnD0m-VaLuE"
       autocomplete="email-verification-token">

只有当支持的浏览器、支持的提供商与登录状态三者齐备时，令牌才会进入隐藏字段；若未进入，站点便像以往一样发送验证邮件。官方未提供功能检测（feature detection）的 API，其正式指引是按「若令牌到达则验证，未到达则回退」来处理。这是一种不破坏既有流程即可叠加的设计。

另外，官方还提供了公开演示（文章作者制作的验证方演示与模拟提供商演示），可在参与源试用前先体验流程。据称，即便是 Gmail 地址，只要登录了 Google 账户便可试用。

当前的支持现状（截至 2026 年 7 月 12 日）

对象状况
Chrome源试用进行中。覆盖 Chrome 150～153（计划），仅限桌面版
邮件服务提供商Gmail 参与。官方博客中未能确认其他公开宣布参与的提供商
Firefox（Mozilla）官方立场为「defer」（暂缓判断，2026 年 1 月）
Safari（WebKit）官方立场未表明（征求立场的 issue 仍处于开放状态）
标准化WICG 的提案＋IETF 的 Internet-Draft。既非 W3C 建议标准，也非 RFC

Chrome —— 名为源试用的「限时实验」

据 blink-dev 邮件列表中的 Intent to Experiment（实施实验的正式提案），源试用覆盖 Chrome 150 至 153，首先仅限桌面版，Android 计划随后跟进（在 WebView 中的提供据称尚未确定）。Chrome 153 的稳定版发布计划于 2026 年 9 月 8 日（Chromium Dash），因此实验期约为两个半月。

重要的是，源试用被设计为「防止对发布前功能产生依赖」。官方博客本身即明确指出：存在流量限制，且应预期 Issuer 一侧的 API 会有不向后兼容的变更（请求格式改为 application/json、切换到 HTTP Message Signatures、Chrome 一侧 UX 的变更）。

Mozilla（Firefox）—— 「defer」

在 Mozilla 的标准化立场中，2025 年 11 月提出了征求立场的请求，并于 2026 年 1 月被归为「defer」（暂缓判断）。负责人给出的理由是：explainer 在问题设定，以及与其他解决方案（如 OpenID Connect、Passkey 等）的比较上缺乏细节，无法作出定性判断。这既不是反对表态，也不是支持。Google 其后更新了 explainer 与规范，并在 Intent to Experiment 中表示计划再次请求评审。

WebKit（Safari）—— 未表明立场

WebKit 的标准化立场 issue 自 2025 年 11 月起一直处于开放状态，截至 2026 年 7 月 12 日，Apple 一侧尚未写入官方立场。另外，Google 的 Intent to Experiment 中记载，在 TPAC（W3C 的年度全体会议）上，WebKit 一侧曾给出非正式反馈，大意是「相比邮件服务提供商，更倾向于扩展 WebOTP 或利用 IMAP 客户端」，但这是 Google 一侧的记述，并非 WebKit 的官方立场，这一点需要注意。

标准化的阶段

浏览器 API 一侧是 WICG（相当于 W3C 正式标准化前置阶段的孵化组织）的草案，提供商一侧的协议是 IETF 中以个人名义提交的 Internet-Draft（draft-hardt-email-verification-00）。Google 报告称，W3C TAG 早期评审的结果为「ambivalent」（对赞成与反对均予保留）。二者都尚未达到作为多浏览器实现的标准而达成一致的阶段。

现阶段是否应引入该技术

综合以上作出判断。在采用决策中应关注的，不仅是「现在能否运作」，还有实验结束后能否持续运作、规范是否稳定、能否预期多方实现。

**作为正式验证流程引入（以废除或削减验证邮件为前提的设计变更）为时尚早。**理由如结论部分所列，但其中尤为沉重的是以下两点。第一，源试用有截至 2026 年 9 月上旬（Chrome 153）的期限，并附有流量限制，是一场「为避免造成依赖而设计的实验」。第二，其生效条件目前相当狭窄。只有在同时满足以下全部条件时才会运作：桌面版 Chrome、使用 Gmail（或受支持的提供商）地址、已登录该账户、且从自动填充中选择——而移动端不在范围内。在通过智能手机使用占比很高的日本面向大众的站点上，能够受益的用户就更为有限。

**另一方面，在保留回退机制的前提下「参与实验」则是另一种判断。**EVP 被设计为对传统流程的叠加，且若未收到令牌便什么也不会发生，因此引入它几乎没有什么可失去的。对于在注册会员或购买引导环节实际测量到验证码所致流失的服务而言，注册源试用并在 A/B 测试框架内测量效果是有合理性的（官方博客也介绍了将其纳入 A/B 测试基础设施的做法）。当下正处于反馈被反映进规范的阶段，欢迎持有实际数据的运营方参与。

后续动向可通过官方的 evp-announce 邮件列表与 Chrome Platform Status 追踪。

小结

  • Email Verification Protocol（EVP）是一项提案：浏览器直接与邮件服务提供商交互以验证电子邮箱地址的所有权，从而使验证码（OTP）与魔术链接变得不必要
  • 用户的操作变为「从自动填充中选择地址并提交」而已，不再需要离开站点。但所验证的是「与提供商之间的有效会话」，而非邮件的可达性
  • 截至 2026 年 7 月 12 日，可运作的仅有桌面版 Chrome 的源试用（计划为 Chrome 150～153），公开宣布参与的提供商仅有 Gmail。Mozilla 标记为「defer」，WebKit 未表明立场，且规范已预告不向后兼容的变更
  • 因此，作为正式验证流程采用为时尚早。对于验证码环节流失成为课题的服务，在保留回退机制的前提下参与实验是合理的

参考资料

  1. Test the Email Verification Protocol with an origin trial — Chrome for Developers（2026 年 7 月 8 日） —— 本文的主要来源。图 1 引用自该文（正文为 CC BY 4.0，代码示例采用 Apache 2.0 许可）
  2. Modernize authentication with passkeys, digital credentials, and more — Chrome for Developers
  3. Email Verification explainer — WICG
  4. Email Verification API（Draft Community Group Report）— WICG
  5. The Email Verification Protocol（draft-hardt-email-verification-00）— IETF Internet-Draft
  6. RFC 9901: Selective Disclosure for JSON Web Tokens — IETF
  7. Intent to Experiment: Email Verification Protocol — blink-dev（2026 年 5 月 19 日）
  8. Email Verification Protocol — Chrome Platform Status
  9. Email Verification Protocol — mozilla/standards-positions #1316
  10. Email Verification Protocol — WebKit/standards-positions #578
  11. Getting started with origin trials — Chrome for Developers
  12. Chrome release schedule — Chromium Dash
  13. evp-announce — chromium.org 邮件列表