发布时间：2026 年 10 月 5 日
随着电子邮件验证源试用活动的继续，我们根据您的反馈进行了进一步更新。我们预计不会再有重大变更，并正准备发布此功能。我们还推出了新的电子邮件验证文档部分，其中包含针对验证方和签发方的专用部分。
电子邮件验证源试用已在桌面版 Chrome 150 中开始。根据开发者的反馈和整个生态系统中的测试结果，我们正在继续完善实现。本文介绍了 Chrome 154 中的更新，包括 Android 支持、第三方源试用、令牌验证期间的关键发现处理，以及针对电子邮件提供商的标头更新。
面向用户的更新
界面或面向用户的行为发生变化。
Android 版 Chrome 支持
自 Chrome 154 起，Android 版 Chrome 支持邮箱验证。验证方或提供方无需进行任何更改，因为 API 或协议保持不变。同样的前提条件适用，包括用户必须在浏览器中登录其电子邮件提供商。
用户可以在设置 > 地址及其他信息 > 已验证的电子邮件地址下访问自己的设置。
验证者更新
对于收集和验证电子邮件地址的网站，此功能有所变化。
第三方来源试用
从 Chrome 154 开始，电子邮件验证支持第三方源试用（请参阅问题 534377131）。如果您提供嵌入式脚本或身份 SDK，现在可以注册第三方试用令牌，并将其注入到托管脚本的网页中。嵌入您脚本的网站无需注册单独的源试用令牌。
但有一点需要特别注意：来源试用注册者和签发者必须是同一网站。具体而言，为试用版注册的来源必须与发布者网域一致。
支持的配置：
- 发卡机构网域：
issuer.example - OT 注册人：
https://issuer.example - JavaScript 来源：
https://issuer.example（或https://app.issuer.example，用于匹配子网域）
不支持的配置：
- 子网域注册者：签发者网域为
issuer.example，但 OT 注册者为https://app.issuer.example。 - 跨网站注册者：发布者网域为
issuer.example，但 OT 注册者为https://different.example。
处理 EVT 中的可选 kid
验证电子邮件验证令牌 (EVT) 时，您的服务器会提取提供方的 JSON Web 密钥集 (JWKS) 以验证签发者的加密签名。密钥可以选择性地包含 kid 密钥标识符，该标识符也可以选择性地包含在 JWT 中，用于指明用于为令牌签名的密钥。
如果令牌不包含 kid 声明（例如，对于 Gmail），请遍历密钥以找到正确的密钥。文档和演示中展示了实现此目的的代码。
完全按照提供的方式返回 email 版权主张
自 Chrome 156 起，令牌中的电子邮件地址将完全按照表单提交中的提供方式返回（请参阅问题 549217427）。以前，提供方可能会返回账号的规范电子邮件地址（例如，当表单提交内容包含 first.last@example.com 时，返回 First.Last@example.com）。请注意，对返回的电子邮件地址使用不区分大小写的比较始终是一种良好的做法，因此这不应是一项重大变更。
提供方更新
针对电子邮件服务提供商的变更。
完全按照提供的方式返回 email 版权主张
从提供方的角度来看，此要求更为严格：如果提供方未完全按照所提供的电子邮件地址返回电子邮件地址，Chrome 将拒绝该令牌。这样可以避免泄露比发送确认电子邮件所泄露的更多数据。验证收到的电子邮件是否与登录用户匹配，验证方式与处理电子邮件传送的方式相同。
将 Sec-Fetch-Dest 重命名为 email-verification
自 Chrome 154 起，在令牌发放请求中发送的 Sec-Fetch-Dest 标头已更新为使用连字符：
- Chrome 154 及更高版本：
Sec-Fetch-Dest: email-verification - Chrome 153：
Sec-Fetch-Dest: emailverification
此变更根据 Web 平台命名惯例（请参阅问题 546618576）对提取目标标识符进行了标准化处理。
如果您的签发端点验证 Sec-Fetch-Dest 标头（建议这样做，以防范 CSRF 和意外的请求上下文），请更新您的检查以接受 email-verification。为避免在浏览器发布期间出现中断，请在过渡期间接受这两个值。