Email verification updates, October 2026

Rowan Merewood

Published: October 5, 2026

As the Email Verification origin trial continues, we have made further updates based on your feedback. We don't anticipate further breaking changes and are preparing to ship the feature. We have also launched a new documentation section for Email Verification with dedicated sections for verifiers and issuers.

The Email Verification origin trial started in Chrome 150 on desktop. Following developer feedback and testing across the ecosystem, we are continuing to refine the implementation. This post covers updates from Chrome 154, including Android support, third-party origin trials, key discovery handling during token validation, and a header update for email providers.

User-facing updates

Changes in the user interface or user-facing behavior.

Chrome on Android support

Starting in Chrome 154, Chrome for Android supports email verification. Verifiers or providers don't need to make any changes because the API or protocol remains the same. The same prerequisites apply, including the requirement that the user must be signed in to their email provider in the browser.

Users can access their settings under Settings > Addresses and more > Verified Email.

Verifier updates

Changes for sites collecting and verifying emails.

Third-party origin trials

From Chrome 154, third-party origin trials are supported for email verification (See issue 534377131). If you provide an embedded script or identity SDK, you can now register for a third-party trial token and inject it into pages hosting your script. Websites embedding your script don't need to register separate origin trial tokens.

There is an important caveat: the origin trial registrant and the issuer must be same-site. Specifically, the origin registered for the trial must match the issuer domain.

Supported configuration:

  • Issuer domain: issuer.example
  • OT registrant: https://issuer.example
  • JavaScript origin: https://issuer.example (or https://app.issuer.example with subdomain matching)

Unsupported configurations:

  • Subdomain registrant: Issuer domain is issuer.example, but the OT registrant is https://app.issuer.example.
  • Cross-site registrant: Issuer domain is issuer.example, but the OT registrant is https://different.example.

Handle optional kid in EVT

When validating the Email Verification Token (EVT), your server fetches the provider's JSON Web Key Set (JWKS) to verify the issuer's cryptographic signature. The keys optionally include a kid key identifier which is also optionally included in the JWT indicating which key was used to sign the token. If the token does not include the kid claim (for example, with Gmail) iterate through the keys to find the correct one. The documentation and demo show the code to do this.

Returning the email claim exactly as provided

Starting in Chrome 156, the email address in the token will be returned exactly as provided in the form submission (see issue 549217427). Previously, issuers might have returned the account's canonical email address (for example, returning First.Last@example.com when the form submission contained first.last@example.com). Note that it is always a good practice to use a case-insensitive comparison on the returned email, so this shouldn't be a breaking change.

Provider updates

Changes for email providers.

Returning the email claim exactly as provided

From the provider side, this requirement is more strict: if the provider does not return the email exactly as provided, Chrome will reject the token. This avoids exposing more data than would be revealed by sending a confirmation email. Validate the incoming email against the signed-in user for a match in the same way you would handle email delivery.

Renaming Sec-Fetch-Dest to email-verification

From Chrome 154, the Sec-Fetch-Dest header sent on token issuance requests has been updated to use a hyphen:

  • Chrome 154+: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

This change standardizes the fetch destination identifier with web platform naming conventions (see issue 546618576).

If your issuance endpoint validates the Sec-Fetch-Dest header (recommended to protect against CSRF and unintended request contexts), update your check to accept email-verification. To avoid disruption during browser rollouts, accept both values during the transition.

Resources and feedback