邮箱验证跳出了二十年的邮件往返——Chrome 把这件事彻底原生化了

配了多年前端，你大概没想过这个问题：用户点完邮件里的链接，这个链接到底能不能防住重放？

邮箱注册流程跑了二十年，大家默认这套机制是安全的。但掰开来看，它有个一直没被认真对待的设计漏洞：服务器生成的那串随机 token，本质上只是一串没有身份绑定的字符串——谁拿到都能用，绑不绑域名、绑不绑 IP，全看实现心情。

今天 Chrome 把它从根上换了。

新旧两套验证流程，差在哪里

传统魔法链接（Magic Link）：

用户输入邮箱 → 服务器生成随机 token → 发送含 token 的邮件
→ 用户点击链接 → 服务器校验 token → 完成注册

这套流程里，token 是纯随机字符串，和用户的浏览器、所在的网站 origin 没有任何密码学绑定。截获邮件的攻击者把链接转发给自己，一样能完成验证。

Chrome Email Verification API（新流程）：

用户选择邮箱 → 浏览器向邮箱域名的 DNS 记录发起查询
→ 邮箱提供商（issuer）签发一个绑定了 site origin + nonce 的 SD-JWT
→ 浏览器把 token 随表单一起提交 → 服务器只验证签名，不查数据库

SD-JWT 里面嵌了三个东西：签发方身份（邮箱提供商）、目标网站 origin（防钓鱼）、一次性 nonce（防重放）。攻击者截到 token 也转发不了，因为 origin 绑定在 token 里面。

十月这次更新，加了三个关键能力

Email Verification API 的 October 2026 更新（Origin Trial）带来了三个实质变化：

① Android 支持

之前只覆盖桌面端 Chrome，现在 Android Chrome 也加入了 origin trial。用户在手机浏览器里注册，流程和桌面完全一致——不再需要切到邮箱 App 查链接。

② 第三方 origin trial（third-party matching）

这次真正打开了一个有意思的局面：第三方网站不用自己对接每个邮箱服务商，而是直接注册参与 Google 的 origin trial。只要网站加载的 JavaScript 里声明了对应的 token，浏览器就会自动走 EVP 流程。相当于邮箱验证变成了一个平台级基础设施。

③ Sec-Fetch-Dest header 语义扩展

新增 Sec-Fetch-Dest: email-verification 这个请求头，服务器可以用来识别「这条请求是浏览器原生 EVP 发出的」而不是脚本或爬虫直接伪造的。这是 W3C 规范里的新指纹，可用于 WAF 层的识别与限流。

开发者怎么接？四步落地

第一步：注册 Origin Trial

到 Email Verification Origin Trial 页面 申请 token。第一方网站填自己域名；第三方网站要勾选 “third-party matching”，并且 token 要通过 <script> 外部引用方式注入（不支持 meta 标签和内联脚本）。

第二步：改造表单，加一个 hidden 字段

<form method="post" action="/register">
  <input type="email" name="email" autocomplete="email">
  <!-- EVP 必填字段：type + nonce + autocomplete -->
  <input type="hidden" name="email_verification_token" 
         data-email-verification-type="issuer-response"
         nonce="服务器生成的随机字符串（每请求一次）"
         autocomplete="one-time-code">
  <button type="submit">注册</button>
</form>

nonce 每表单调一次，存会话里用于最终校验。

第三步：后端验证五步走

// 伪代码
async function verifyEVTToken(token, expectedOrigin, nonce) {
  // 1. 解析 token（JWT 结构）
  const { header, payload, signature } = parseJWT(token);

  // 2. 检查 issuer 是否在信任列表（gmail.com、outlook.com 等）
  if (!TRUSTED_ISSUERS.includes(payload.iss)) throw 'unknown issuer';

  // 3. 校验 key binding：token 里嵌入的 origin 必须等于本站
  if (payload.aud !== expectedOrigin) throw 'origin mismatch';

  // 4. 校验 nonce：防止重放
  if (payload.nonce !== nonce) throw 'nonce mismatch';

  // 5. 验签：使用 issuer 的公钥（从 DNS TXT 记录拉取）
  await verifySignature(token, await fetchIssuerPublicKey(payload.iss));

  return { email: payload.email, valid: true };
}

第四步：保留兜底逻辑

规范明确建议：任何一步失败（浏览器不支持、用户拒绝授权、服务商不支持），浏览器会静默回退到传统验证邮件流程。网站不需要单独处理降级——只要现有的邮件验证流程还在线，整个流程就能完成。

什么时候该切换？

三个信号出现一个，就值得评估：

大多数场景下，魔法链接还会存在很长时间。但移动端优先的产品、EVP 覆盖邮箱服务商（Google、Microsoft 账户体系）的场景，现在就可以接了。

下一步： 去 Chrome Email Verification Demo 跑通最小流程，把 token 校验逻辑接进你们的注册端点。验证通过后把降级逻辑的注释删掉，正式上线。