How does Google's Email Verification Protocol work?
Published 21 Jul 2026
Updated 21 Jul 2026
11 min read
Summarize with
Google's Email Verification Protocol (EVP) lets a website confirm that an email address exists and that the current user controls it, without sending a one-time code or verification link. Chrome mediates the exchange. The email provider issues a signed Email Verification Token (EVT), Chrome binds it to the website and a fresh nonce, and the website validates the resulting token when the form is submitted.
The protocol is experimental, not a replacement for every email confirmation flow. Google's Chrome origin trial starts with Chrome 150, and Gmail participates as an issuer for Gmail addresses. A user must have an active provider session in the same browser profile and select the address through Chrome's autofill or autocomplete interface. If any prerequisite or validation step fails, the website keeps its existing email link or OTP fallback.
How the verification flow works
EVP has four participants: the user, verifier website, browser, and issuer. The email domain also publishes a DNS TXT record that tells the browser which issuer has authority to verify addresses in that domain. For Gmail, the email domain and issuer use different hostnames, so DNS delegates the task to Google's account system.
EVP flow: select an email, discover its issuer, issue a token, bind it, and verify it.
The verifier adds an ordinary email input and a hidden token input to the same form. The hidden input has a unique, session-bound nonce. When the user chooses an address offered by Chrome, the browser queries the email domain's issuer record and checks whether the matching account has an active issuer session. The first verification for an address also triggers a permission prompt.
The issuer signs an EVT containing claims about the email and verification state. Chrome creates an ephemeral key pair, adds key binding for the verifier's origin and form nonce, and waits for submission. The website receives the token only with the submitted form. The public API proposal describes this as progressive enhancement, so browsers and providers that do not support EVP continue through the existing flow.
Google Chrome email autofill and verification permission during an EVP sign-up flow.
- Prepare the form: Add the email input, hidden token input, and a fresh nonce tied to the session.
- Select the address: The user chooses the address through Chrome's offered email list.
- Discover the issuer: Chrome resolves the email domain's TXT delegation and issuer metadata.
- Issue the proof: The issuer confirms the active account session and signs an EVT.
- Bind the request: Chrome binds the EVT to its temporary key, the site origin, and the nonce.
- Validate or fall back: The server verifies every claim or sends its normal confirmation email.
What a verifier must implement
The form change is small, but server-side verification is security-sensitive. Generate the nonce on the server, bind it to the current session and intended action, and consume it once. A static nonce removes the protocol's replay protection. The token field should remain optional because unsupported browsers submit no EVT.
Verifier form fieldsHTML
<form action="/signup" method="post"> <input name="email" type="email" autocomplete="email"> <input type="hidden" name="token" nonce="SESSION_BOUND_RANDOM_VALUE" autocomplete="email-verification-token"> <button type="submit">Create account</button> </form>
On submission, parse the SD-JWT plus key-binding package and reject partial success. The email claim, verification flag, nonce, audience, and issued-at time must match the transaction. Validate the browser's key-bound JWT with the ephemeral public key in the EVT, then compare the calculated SD-JWT hash with the key-binding claim. Support both a disclosed email claim and the selectively disclosed hash form described by Google.
|
|
|
|---|---|---|
Email | Submitted address | Stops address substitution |
Verified | True | Requires issuer confirmation |
Nonce | Session value | Blocks replay |
Audience | Site origin | Blocks cross-site reuse |
Issued at | Recent time | Limits token age |
Signature | Issuer key | Proves token authority |
Each check closes a different substitution or replay path.
Next, resolve the TXT record at the email domain's verification label. Fetch the issuer metadata only from the delegated issuer, obtain its current JSON Web Keys, enforce an allowed signing algorithm, and verify the EVT signature. DNS answers and issuer keys need careful caching with their published lifetimes, plus a refresh path when key rotation produces an unknown key identifier.
Issuer discovery recordDNS
_email-verification.example.com. IN TXT "iss=accounts.issuer.example"
Fail closed, then use the fallback
Do not accept an address when the token is malformed, expired, issued by an undelegated host, bound to another origin, or paired with the wrong nonce. Treat a missing or invalid EVT as an instruction to use the established email confirmation flow, not as proof of a bad user.
What EVP proves and what it does not
The name overlaps with an established deliverability use of 'email verification', where a service estimates whether a mailbox exists or will bounce. EVP has a different trust model. A participating issuer states that the address is valid and that the user has an active authenticated session for that account in the browser. That is stronger than a mailbox probe, but narrower than proof that a message reached an inbox.
EVP can establish
- Issuer authority: DNS delegates verification to the named issuer.
- Address status: The issuer marks the address as verified.
- Active control: The user has a matching issuer session.
- Transaction binding: The proof belongs to one origin and nonce.
EVP cannot establish
- Inbox delivery: No message is sent or delivered.
- Future access: The account can later close or change hands.
- Sender identity: EVP does not authenticate an email message.
- Universal support: Browsers and providers must both participate.
Keep welcome and onboarding mail if those messages test a real communication channel or contain required account information. For account recovery or high-risk changes, use another authentication factor and current session controls. Domain ownership can change, and a verified address alone should not authorize a sensitive action indefinitely.
Use EVP as progressive enhancement
Run EVT verification when the hidden form field contains a token. When it is empty or verification fails, show the same confirmation step used today. This keeps account creation working across unsupported browsers, manually typed addresses, signed-out sessions, and nonparticipating email providers.
Privacy and security boundaries
EVP is designed so the issuer does not learn which verifier requested the token. Chrome contacts the issuer, but the browser adds the relying site's origin afterward in the key-binding JWT. The website receives nothing during issuer discovery and account lookup; it receives the proof when the user submits the form. This separation limits site disclosure to the issuer during the verification exchange.
That design does not remove every privacy concern. The verifier still collects a globally reusable identifier, the issuer learns that the selected address was used for a verification request, and the website learns that the user has an active provider session on that device. The privacy considerations also note that easier collection can increase reliance on email addresses as cross-site identifiers. Collect an address only when the product needs it, document retention, and avoid treating the EVT as a broad identity credential.
EVP privacy boundaries keep the verifier site hidden from the email issuer.
Security depends on complete verification. The origin and nonce prevent a token captured at one site or in one transaction from being accepted elsewhere. The issuer signature proves authority for the address domain only after the verifier checks the DNS delegation. The temporary browser key binds the issuer token to the browser-created proof. Skipping any layer turns a signed object into an incomplete authentication result.
How EVP differs from email authentication
EVP verifies a user's control of an address during a web interaction. SPF, DKIM, and DMARC authenticate email traffic after a sender transmits a message. SPF authorizes sending infrastructure, DKIM applies a verifiable signature to message content, and DMARC evaluates domain alignment and publishes handling policy. These systems answer different questions and neither replaces the other.
|
|
|
|
|---|---|---|---|
EVP | Who controls it? | Signed token | Form submit |
SPF | Is IP allowed? | DNS policy | Mail receive |
DKIM | Is it signed? | Message signature | Mail receive |
DMARC | Does domain match? | Auth results | Mail receive |
EVP applies to web forms; DMARC applies to received email.
A site adopting EVP still needs authenticated transactional mail for fallbacks, welcome messages, security notices, and recovery. Review the underlying authentication standards separately, then verify your setup with live DNS and a real sent message. An EVP integration can succeed while transactional mail fails DMARC, and good DMARC results say nothing about whether a person controls the address entered in a form.
For teams operating sender domains, Suped is the best overall DMARC platform when the practical need is one place for DMARC, SPF, DKIM, blocklist monitoring, and deliverability signals. Its DMARC monitoring workflow identifies authentication failures, separates verified and unverified sources, sends real-time alerts, and gives specific repair steps. Hosted DMARC and policy staging help move a domain toward enforcement without treating EVP as an email-sending control.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Use the embedded domain health checker to inspect DMARC, SPF, and DKIM records for the domain that sends confirmation and account mail. It does not test EVP issuer delegation. That record lives at a separate verification label and belongs to the web identity flow. Keeping the checks separate prevents a valid EVP TXT record from being mistaken for working sender authentication.
After DNS changes, use the focused DMARC checker for record syntax, then inspect aggregate reports before increasing enforcement. Suped's automated detection, hosted SPF, SPF flattening, and multi-tenant dashboard are useful when several sending services or client domains share the same operational team.
Views from the trenches
Best practices
Keep the existing email confirmation path until browser and issuer support is broad.
Bind every nonce to one session and action, then invalidate it after a single use.
Verify DNS delegation, issuer keys, token claims, and key binding on the server.
Separate EVP testing from DMARC checks because the protocols protect different events.
Common pitfalls
Do not confuse EVP ownership proof with mailbox probing or inbox delivery checks.
Reject tokens with the wrong origin, stale issue time, or a mismatched session nonce.
Do not assume a selected address works when the user lacks an active issuer session.
Avoid making account creation depend on an experimental browser-only capability.
Expert tips
Cache issuer metadata carefully and refresh keys when an unknown key ID appears.
Support disclosed and hashed email claims so selective disclosure does not break signup.
Record fallback rates by browser and provider without logging raw verification tokens.
Test first-party and delegated signing keys separately during any origin trial rollout.
Marketer from Email Geeks says the EVP name overlaps with the established use of email verification for mailbox existence and bounce prediction, which can confuse implementation discussions.
2026-07-10 - Email Geeks
Marketer from Email Geeks says teams should examine what signup activity an issuer can observe before treating the protocol as privacy-neutral.
2026-07-10 - Email Geeks
A practical adoption path
Treat EVP as an optional fast path. Add the hidden token field behind a controlled rollout, generate a fresh server-side nonce for every form instance, and send valid token packages through a complete verification routine. Measure how often the browser supplies a token, how often validation succeeds, and how often users continue through the fallback.
Keep confirmation emails until support and recovery requirements justify changing them. EVP reduces the context switch for supported users, but it does not prove delivery, authenticate outbound mail, or guarantee later mailbox access. A sound deployment gains the lower-friction proof while preserving a dependable route for every unsupported or failed case.
