Email Verification Protocol: What Chrome Actually Validates and When It’s Pointless

Should you change your signup form because Chrome can now confirm a Gmail address in one click? On July 8, 2026, Google opened the origin trial for a new protocol, the Email Verification Protocol (EVP): the issuer attests that an active session exists with the mailbox provider, and the browser carries the proof, without sending a confirmation email. In practice, this removes one specific friction point: the one-time code or confirmation link sent by email, the stage where your email tool shows all green while the hard bounce rate climbs silently. What the protocol proves, and what it doesn’t prove, comes down to a grid of 12 collection scenarios.

The EVP protocol mechanism, in 6 steps

The protocol distinguishes 3 roles. The validator collects the email address on its form. The mailbox provider hosts the inbox. The issuer, accounts.google.com for a Gmail address, manages the account session. Owning an address and having an active session with your provider are two different things: the protocol only checks the latter. Two conditions still need to be met. The user must be signed in to their mailbox in the same Chrome profile. They must also select their address from autocomplete rather than typing it manually. Without both, no token is produced. The flow breaks down into 6 steps.

1. The user selects their address from the browser’s autocomplete, never by typing it manually.
2. Chrome queries the domain’s _email-verification DNS record to identify the responsible issuer.
3. The issuer confirms that an active session exists for that account, without revealing any other information about the user.
4. It generates an Email Verification Token in SD-JWT+KB format, a selective-disclosure token bound to an ephemeral public key, signed with EdDSA or ES256.
5. The token travels in a hidden form field at submission time.
6. The site’s server runs 5 checks: JWT decoding, verification of email_verified, the nonce and the audience, key binding validation, a DNS lookup, then signature verification via the dedicated well-known endpoint.

The mechanism echoes BIMI, another protocol that relies on a DNS record and provider-by-provider adoption, never universal from day one. If a check fails or the token is missing, the site falls back to its usual flow. Google calls this progressive enhancement.

Current verification methods force the user to leave the site, with the risk that they abandon the session before completing their signup. Rowan Merewood, Staff Developer Relations Engineer at Google, Chrome for Developers, July 8, 2026.

The grid: where the protocol helps, where it’s useless

12 collection scenarios, 12 different answers. The protocol only covers a narrow slice of the signup journey: the one where Chrome and Gmail combine, with autocomplete actually used on the same profile. On Safari, Apple already has its own layer with Hide My Email, an independent mechanism that redistributes addresses across your lists, with no connection to Chrome’s protocol.

The most counterintuitive case fits in a single row of the table. A disposable address hosted by a provider that one day deploys an issuer would pass the EVP check with a perfectly valid token. The token measures nothing beyond an active session at time T; it says nothing about the mailbox’s intended lifespan, nor about the real intent behind the signup. A Yopmail or Mailinator address with its own issuer would sign a token just as clean as a standard Gmail address.

The other blind spot is time. The token confirms possession at the moment of signup, never afterward. For a freshly created address, the gap between what the protocol claims and the mailbox’s actual state stays marginal. After a few months of inactivity, though, nothing in the mechanism flags a mailbox that’s full or has been abandoned for months. EVP isn’t designed to do that anyway: it’s limited to proof of possession at the moment of collection, a snapshot that degrades without ever refreshing.

A third area of uncertainty concerns business addresses. Google Workspace claimed more than 11 million paying customers in Q4 2025, a figure announced by Sundar Pichai on February 4, 2026, meaning that many organizations have their mailboxes hosted by Google. The documentation doesn’t say whether these domains can publish the _email-verification record and move into the grid’s first column. That table row stays conditional on the absence of that record, never on the address type.

Can the EVP token serve as GDPR proof?

Chrome’s documentation has no section dedicated to privacy. GDPR doesn’t appear in it. Neither does marketing consent, nor the planned retention period for the token. This silence leaves the decision to the data controller rather than the browser.

A safeguard exists nonetheless on the user’s side. Chrome shows a permission prompt the first time an address is provided for validation, so the first validation never happens without the signed-up person’s knowledge. That prompt doesn’t reappear afterward for the same address.

The token embeds concrete personal data: the issuer (iss), the address or its equivalent (email), a validity flag (email_verified), a timestamp (iat), a confirmation key (cnf), the site’s origin (aud), a nonce, and a confirmation hash (sd_hash). Storing it as supporting evidence amounts to retaining personal data, subject to the principles of minimization and storage limitation. How long should you keep it? The documentation doesn’t say. That’s a question to settle with your DPO rather than your technical vendor.

One detail changes things on the minimization front: the email claim can be selectively disclosed. Configured that way, it sends a hash instead of the plaintext address to the validator, a setting worth checking before any production rollout.

Article 7.1 of the GDPR requires the data controller to be able to demonstrate the person’s consent. Today, the double opt-in confirmation click fills that role. The EVP token doesn’t replace it: it attests technical possession of the mailbox at the moment of signup, without saying anything about agreement to receive messages afterward. It does solve another problem that double opt-in only partly covers, though: the “I didn’t enter this address” objection. Double opt-in proves consent, the token proves possession of the mailbox at signup: a form that combines both closes off both angles at once.

On privacy on the issuer’s side, Google is explicit: “The issuer only sees a request to verify the user’s existence; it doesn’t see which site initiated the request.” The token’s architecture makes that claim credible: it’s the browser that builds the key-binding token carrying the site’s origin and the nonce, signed with the ephemeral key, after receiving the issuer’s token. So the issuer never needs to know the destination site to sign its part of the token.

Two questions remain unanswered in the current documentation. The issuer’s exact legal role in the chain stays unclear: does it act as data controller or processor? Transfers outside the European Union aren’t documented either: the issuer is the provider that already hosts the person’s mailbox. Nothing is said, however, about the processing of the token itself or where it’s located.

Calculating your real protocol coverage

Chrome accounts for 65.23% of browser sessions worldwide in May 2026, a figure that climbs to 76.39% on desktop alone (StatCounter, May 2026). That global share ignores your actual EVP coverage, which depends solely on your own traffic and signup data. On the mailbox side, Gmail is credited with roughly 1.8 billion active users worldwide, a November 2024 Statista estimate the industry keeps citing for lack of regular figures from Google. That volume sets a theoretical ceiling, never your real share: a list built from business addresses and one built from consumer signups don’t produce anywhere near the same percentage.

3 numbers are enough. The share of Chrome traffic on your signup form, readable in Google Analytics or Matomo. The share of Gmail addresses among your recent signups, by extracting the domain from your ESP database. And the share of those signups where autocomplete actually filled the field rather than manual entry, a figure no API surfaces natively, which you have to instrument yourself, for example by comparing the input and change events fired on the email field.

Multiplying the first two numbers gives you an upper ceiling. The third, almost always overlooked, brings it back down.

The 3-stage setup, from token to send

Once you understand the mechanism, the instinct is to ask whether you still need to pay for verification before sending, since Chrome already validates the address at signup. The token’s scope answers that: it stops exactly where the grid says it does.

The token lets you skip the confirmation-link click for Gmail signups made through Chrome. Double opt-in thus keeps its own role, described above: proof of active consent, timestamped in practice so you can demonstrate it as Article 7.1 of the GDPR requires. An EVP token replaces neither the checked box nor the timestamp stored in your database at the moment of consent.

Since 2024, Google has set a complaint rate threshold of 0.3% for bulk sending, on pain of having messages flagged as spam or rejected by Gmail, a figure already visible in Google Postmaster Tools’ per-sending-domain tables. A disposable address or a closed mailbox that still receives the campaign pushes that rate up, even mid-IP warmup, regardless of what the token showed at signup. Deliverability plays out at send time, when collection is already long behind you. This isn’t the first technical protocol to redraw one link in the chain without removing the others: DKIM2 followed the same logic on message authentication.

The check that verifies syntax, the MX domain, and sometimes deliverability history before sending (the one CaptainVerify runs) fits logically between collection and the campaign. The only way to know if your list needs this filter is to run a sample through it before your next send.

What you need to keep on file, at minimum: the GDPR opt-in record, the status of the last list hygiene check, and the date of the last campaign sent without a bounce. The EVP token itself isn’t meant to be stored beyond the signup session.

Gmail remains the only consumer-facing issuer today. The protocol itself is carried by Chromium browsers: Chrome since version 150, Edge via its own origin trial on Microsoft’s side. Its path toward standardization is already mapped out: an Internet-Draft signed by Dick Hardt and Sam Goto has been filed with the IETF since June 17, 2026, in a revision dated July 4, as an individual submission, with no working group or validation at this stage. Validity estimates in its July 2026 analysis that double opt-in loses 20 to 35% of sign-ups at the confirmation stage, a friction point EVP could genuinely reduce on the Gmail side. If Outlook or Yahoo ever deploy their own issuer, the grid’s first column will widen; without them, it stays confined to Gmail.

Frequently asked questions about the Email Verification Protocol

Does the EVP protocol work on mobile or inside an app?
The documentation doesn’t explicitly settle this point. The protocol assumes browser autocomplete, which effectively rules out contexts where it isn’t available, particularly certain in-app browsers.

Which browsers support EVP in 2026?
Chrome since version 150, via the origin trial opened on July 8, 2026. Edge follows with its own origin trial, listed in the Implementation Status section of the IETF draft: the same Chromium mechanism, with a token to register on Microsoft’s side, separate from Chrome’s. On Safari, no announcement to date.

Does the protocol work with Outlook or Yahoo?
Not yet. Gmail is the only mailbox provider issuing tokens at launch. The API for other mailbox providers is still under development at Google.

Should you enable the origin trial right now?
Only if Chrome and Gmail account for a measurable share of your signups. The trial imposes traffic limits and a mandatory fallback to the standard confirmation email on failure.