无效、缺失或校验不通过的令牌都不能证明邮箱所有权：服务端应拒绝该令牌，并回退到你已有的邮件确认流程。只适用于你在自家产品或获授权环境中验收注册与账号安全，不要把令牌验证通过、账号状态正确、回退邮件可读这三项合并成一个结果。
审核账号安全或灰度发布的技术负责人，应确认试验功能失败时不会绕过原有验证要求。
如果你是开发者或 QA，本文按失败场景提供验收步骤与状态检查点。
最后更新于 2026 年 10 月 28 日；核对自 Chrome Email Verification 文档、服务端验证指南 与 WICG 提案。
Chrome Email Verification API 无效令牌测试的通过线
这项提案证明的是：在邮件提供方会话参与的流程中，用户对某个邮箱地址具有控制权。它不证明你的应用已经发送邮件，也不证明邮件已到达或能被读取。令牌通过校验，可以按你的业务规则确认地址；但是否进入已验证账号状态，仍应由服务端校验结果决定。
截至本文核对日期，官方将该功能列为 Origin Trial，而非稳定、不会变化的通用能力。当前官方说明列出的试验范围是桌面版 Chrome 150 至 160、Android 版 Chrome 154 至 160；更早注册的试验令牌需注意 2026 年 11 月 17 日的失效日期。范围和日期请以官方功能说明为准。提案仍可能演进，别把未说明的错误码、重试行为或令牌寿命写成协议保证。
| 验收对象 | 通过条件 | 失败时的处理 |
|---|---|---|
| EVT 与 Key Binding JWT | 声明、签名和密钥绑定符合当前服务端校验要求 | 拒绝令牌，不把账号标记为已验证 |
| 账号状态 | 仅在通过校验或完成既有邮件确认后更新 | 保持待确认，禁止进入需要验证的功能 |
| 邮件回退 | 测试环境能读取本次应用发出的确认邮件 | 记录发送、收件和状态变化；不要据此推断生产必达 |
以下步骤只用于测试自家产品。先在隔离环境准备测试账号、可追踪的请求标识和可查询的账号状态；不要使用真实用户资料或生产账户来构造失败令牌。若测试场景涉及邮箱与个人信息，先参照注册隐私检查清单隔离测试数据。
令牌缺失：确认流程没有误放行
在表单提交中移除 EVT，模拟浏览器或提供方未签发令牌、用户未完成验证等情况。检查服务端不能把“没有令牌”当作“令牌有效”，也不能仅凭邮箱格式正确就跳过确认。
服务端指南明确指出，令牌字段为空时应使用现有验证方式，例如发送验证码或确认链接。验收时同时记录页面提示、请求结果、账号状态，以及是否触发自家邮件确认流程；只检查接口响应码，可能漏掉账号已被错误写成“已验证”的情况。
声明不匹配：逐项验证邮箱与表单绑定
不要一次性篡改多项声明。对 email、aud、nonce、iat、exp 分别准备错配用例：例如令牌邮箱与提交邮箱不同、受众不是当前站点、nonce 来自另一个表单实例，或时间声明不符合当前校验要求。每个用例单独提交，便于定位是哪项检查失效。
aud 与 nonce 用于把令牌绑定到预期验证方和具体表单流程；exp 的判定细节应以当前官方流程及你的实现为准。WICG 提案要求验证受众与表单 nonce；服务端验证指南列出了 EVT 的预期声明。若邮箱大小写或规范化可能造成差异，也应按当前实现明确比较规则，而不是通过放宽所有声明检查来消除测试失败。
签名或密钥校验失败：确认服务端拒绝
在隔离环境中构造签名无效的 EVT，并单独测试 Key Binding JWT 签名无法验证的情况。不要在生产密钥或真实用户请求上做破坏性测试。每次只注入一种故障，并保留请求关联信息、校验阶段日志和账号状态证据。
SD-JWT 规范 RFC 9901说明：若验证方要求 Key Binding，呈现内容缺少有效绑定时应拒绝。Chrome 的当前服务端指南也要求分别验证发行方签名与密钥绑定。实际错误响应和日志名称由应用实现决定，官方资料没有定义所有服务端都必须返回同一个错误码。
| 注入场景 | 应观察的校验结果 | 必留证据 |
|---|---|---|
| EVT 签名不匹配 | 发行方签名校验失败，令牌不通过 | 校验阶段、请求关联信息、账号状态 |
| Key Binding JWT 签名不匹配 | 密钥绑定校验失败，令牌不通过 | 绑定公钥来源、签名校验结果、账号状态 |
DNS 发现与 iss 不一致 |
不接受不匹配的发行方链路 | 发现记录、令牌发行方声明、元数据获取结果 |
发行方发现异常：区分协议拒绝与依赖故障
模拟邮箱域名的发现记录与令牌 iss 不对应，或发行方元数据、公开密钥无法完成预期校验。核对服务端是否拒绝令牌，并转入原有确认流程。官方验证流程包含 DNS 委派、发行方元数据与公钥获取、签名校验；发生失败时，应能找到具体失败环节，而不是只留下“验证失败”。
密钥或元数据获取错误也可能来自临时网络故障。分别记录 DNS 发现结果、元数据和密钥获取结果、签名校验结果与账号状态。单次依赖请求失败不足以说明浏览器或邮箱提供方有问题；也不要把某个固定重试次数当作统一协议行为。
常见验收疑点
字段为空时可以直接创建已验证账号吗？
不可以。按你的业务逻辑创建待确认账号，并继续走既有邮件流程。空字段表示当前请求没有可验证令牌，不表示邮箱所有权已经得到确认。
email、aud、nonce 或 exp 不匹配时如何判断拒绝有效？
逐项改变输入，确认服务端拒绝令牌、账号保持待确认，且来自其他表单实例的 nonce 不会被接受。检查响应码之外，还要核对数据库状态和权限边界。
Key Binding JWT 签名失败要留下什么证据？
记录请求关联信息、密钥绑定校验阶段和账号状态。测试应确认签名错误不会被忽略，也不会因进入错误处理分支而放行账号。不要假定所有实现都使用相同错误码。
邮件回退：用受控收件闭合验收
在测试环境触发令牌缺失或校验失败的回退。用受控地址检查邮件正文、目标环境和确认链接；完成链接操作后，再确认应用端账号状态发生预期变化。不要在真实用户邮箱上测试，也不要把收件成功等同于生产送达率。
MyTempBox 首页说明可免注册打开临时收件箱并读取来信，因此可以作为这类测试中的受控收件方式之一；实际是否收到仍以本次测试结果为准。收到测试邮件只证明本次邮件可读取，不证明 API 令牌有效，也不证明生产链路必达。遇到延迟或未到达时，可参照邮件到达时间窗排障指南，区分应用发送、邮件传递与收件箱读取环节。
条件分支：决定本次验收是否通过
- 若令牌缺失、声明不匹配、签名失败或发行方校验失败均被服务端拒绝，账号仍待确认，并触发既有邮件流程，则负向安全验收通过。
- 若令牌校验通过，但账号状态没有按预期更新，检查应用状态转换与业务规则；不要把邮件收件结果拿来替代令牌校验结论。
- 若账号没有误验证，但邮件未到或链接无法完成确认，则令牌拒绝可能正确，回退链路仍未验收通过。继续排查测试环境的发送与收件环节。
- 若未验证账号仍能使用受保护功能，则无论页面提示或邮件发送是否正常，本轮都不通过。
对 Key Binding JWT 的验收重点是绑定签名与当前请求上下文，不是只确认令牌结构可解析。RFC 9901 说明了 Key Binding 在 SD-JWT+KB 中的验证作用；RFC 9421则定义了 HTTP 消息签名机制。两者对应不同校验对象，不要把 HTTP 请求签名和 EVT 的令牌签名混为一谈。
如果你只需要隔离一次注册确认邮件，MyTempBox 的免注册临时收件箱可以作为测试收件方案之一，避免把测试邮件送进主邮箱；但它不能替代服务端的令牌校验，也不适合银行、支付、政务等需要长期找回的重要账户。开始前可从 MyTempBox 临时收件箱打开地址，再以实际收件结果验收邮件回退链路。
常见问题
表单提交时 EVT 是空的，账号可以直接注册成功吗？
不可以把空令牌当作邮箱已验证。先确认账号状态仍处于待确认，再按自家既有流程发送确认邮件或验证码。浏览器、提供方不支持，用户未完成授权，或令牌尚未生成，都可能导致字段为空；记录具体原因有助于区分功能回退与前端配置问题。
EVT 里的 email、aud、nonce 或 exp 不匹配，该检查什么？
把表单提交的邮箱与令牌声明对照，并分别核对受众是否指向你的 HTTPS 源、nonce 是否属于当前表单实例，以及 exp 是否符合当前实现的有效性要求。每次只改变一个条件，确认请求被拒绝且账号没有进入已验证状态；不要只看响应码，也要检查数据库状态和后续邮件路径。
Key Binding JWT 签名失败后，怎样确认账号没有误通过？
在隔离测试环境提交签名被破坏的令牌，确认服务端的 Key Binding 校验失败，并核查账号仍未验证、受保护功能仍不可用。再检查日志是否能关联到本次请求及失败阶段。令牌格式、日志字段和错误响应属于应用实现细节，不应把某个固定错误码当成协议要求。
API 校验失败后，如何验收邮件回退确实可用？
在自家测试环境触发回退，只使用受控收件地址。确认应用发送了预期环境的邮件，链接指向测试环境，并且完成链接操作后账号状态才变为已验证。收到一封测试邮件，只能证明这次测试收件可读取；它不能证明生产邮件必达，也不能替代对令牌拒绝和账号状态的检查。