Chrome’s Email Verification Protocol Does Not Replace Email Validation

Chrome 150 is testing a new way to verify email ownership without sending an OTP or magic link. The browser asks the email provider for a signed token, binds it to the site and form session, then submits it with the email address.

So does this replace email validation? No.

The Email Verification Protocol proves a user had an active session with an issuer for an address during the flow. It does not prove mail reaches the inbox, classify the address as disposable or role-based, or show the user will retain access.

I think the proposal is useful. I also think the name invites teams to combine two separate jobs into one checkbox (email infrastructure loves doing this to us).

What did Chrome launch?

Chrome published its Email Verification Protocol origin-trial guide on July 8, 2026. The trial started with Chrome 150, and Gmail is participating as an email provider.

The protocol work sits in an individual IETF Internet-Draft updated July 7, 2026. It has no formal standing in the IETF standards process. Chrome also warns trial participants to expect backwards-incompatible issuer API changes.

In other words, this is an experiment worth testing, not a new production baseline everyone must adopt.

What happens during an EVP signup?

The current Chrome trial needs three conditions:

• The user is signed in to the email provider or issuer in the same browser profile.
• The relying site has enrolled in the origin trial and placed its trial token on the form page.
• The user selects the address from Chrome autofill or autocomplete. Support for manually typed addresses is planned for a later release.

The relying site adds an ordinary email input and a hidden field with a fresh, session-bound nonce:

<input
  name="email"
  type="email"
  autocomplete="email">

<input
  name="email_verification_token"
  type="hidden"
  nonce="SESSION_BOUND_RANDOM_VALUE"
  autocomplete="email-verification-token">

When the user selects an address, Chrome looks up a DNS TXT record under _email-verification.<email-domain>. The record delegates verification to an issuer. Chrome then asks the issuer for an Email Verification Token, or EVT, for the signed-in address.

The browser binds the EVT to a temporary key, the relying site’s origin, and the nonce from the form. The site receives the token only when the form is submitted.

What must the server verify?

A token appearing in the request is not enough. Chrome’s guide gives the relying server five checks:

1. Parse the EVT package.
2. Match the email, nonce, audience, verification flag, and issue time to the current form session.
3. Verify the key-bound JWT with the temporary public key in the EVT.
4. Resolve the email domain’s _email-verification TXT record and confirm the delegated issuer.
5. Load the issuer metadata, retrieve its current keys, and verify the EVT signature.

Skipping the nonce or audience check creates a token-reuse problem. Skipping DNS delegation means accepting an issuer the email domain never authorized. Skipping signature verification turns a signed proof into decorative JSON.

The draft also requires uniform authentication errors from issuers so attackers cannot probe whether particular addresses exist. This requirement deserves attention from anyone implementing the issuer side.

What does a valid EVT prove?

A fully verified EVT supports a narrow claim: the issuer vouched for the address, and the browser proved possession of the transaction key for this site and nonce.

For the Chrome trial, this means the user had an active session with the provider for the selected address. It is stronger than accepting text from an email field. It also avoids waiting for a message to arrive.

What about inbox ownership?

“Ownership” is convenient shorthand, but I would store a more precise state such as provider_control_confirmed_at. The proof describes control during one protocol flow. It does not establish legal identity, permanent ownership, or future account access.

What does EVP leave unanswered?

The proposal itself draws the important boundary: it verifies control of an address, not whether the address receives mail.

A user with a valid provider session still might select a disposable address. A role address might have several legitimate operators. A provider might issue an identity token for an address whose mail routing is disabled.

None of those facts makes the EVT false. They answer different questions.

Should EVP replace your confirmation email?

For a supported browser, participating provider, and low-risk flow, a valid EVT might replace the ownership-confirmation step. Chrome presents EVP as a progressive enhancement and tells sites to retain their existing fallback.

I would keep the fallback for four reasons:

• The token is optional and there is no separate feature-detection step.
• The current trial requires an autofill or autocomplete selection.
• Provider participation is limited.
• The origin trial and issuer API are still changing.

If the EVT is missing or invalid, send the normal confirmation message. Do not convert an unsupported browser or provider into a failed signup.

There is a fair objection here: if the provider confirmed control, asking for a confirmation link adds friction without adding the same evidence twice.

I agree. Skip the extra link when current control is the only requirement and the EVT passes. Keep a real delivery step when your product depends on future email, such as account recovery, legal notices, receipts, or security alerts.

Where does address verification fit?

Run address verification when the cost comes from bad routing, temporary inboxes, shared addresses, likely typos, or inconclusive mailbox responses.

The emailverifier.dev API keeps four outcomes separate: deliverable, risky, undeliverable, and unknown. The domain reports also distinguish free mailbox providers from disposable services.

The distinction matters beside EVP. A provider-control proof should not erase a disposable-domain risk signal. A mailbox timeout should not erase a valid ownership proof. Store both results and let your product policy decide.

How I would test the origin trial

1. Enroll only a small test cohort and keep the existing confirmation path intact.
2. Generate a fresh nonce on the server, bind it to the session, and consume it once.
3. Treat the EVT field as optional. Validate every component when present.
4. On any verification failure, fall back to confirmation instead of rejecting the address.
5. Store ownership evidence separately from deliverability and risk results.
6. Measure completed signups, fallbacks, token failures, confirmation delivery, and later bounce outcomes as separate events.
7. Recheck the Chrome guide and IETF draft before each trial update because the wire format is still moving.

EVP is an ownership signal. Address verification is a reachability and risk signal.

Keep both labels honest.