For a decade, the moment a prospect types an email address into a signup form has been the messiest step in the funnel: send a one-time code, wait for a magic link, hope the person comes back from their inbox instead of abandoning the tab. Chrome is now testing a way to erase that entire round trip, and the mechanism it uses says as much about where identity infrastructure is heading as it does about signup forms.
What Chrome is actually testing
Google has opened an Origin Trial for something it calls the Email Verification Protocol (EVP), described in a Chrome for Developers post published July 8. The pitch is simple: instead of a site sending a verification email or one-time password, Chrome asks the user’s email provider directly for cryptographic proof that the person filling out the form controls that address. No message sent, no tab-switching, no lost signups waiting on an email that landed in spam.
The trigger is narrow but deliberate. The user has to be signed into their email provider in the same browser profile, they have to select the address from Chrome’s autofill or autocomplete list (typed addresses are not supported yet), and the site has to be enrolled in the origin trial. If any of that is missing, the form falls back to a normal OTP or magic-link flow. Gmail is the only participating provider so far, which means the realistic test population right now is Chrome users with a signed-in Google account.
How the verification actually works
Sites add a hidden field to the signup form carrying a session-bound nonce. When a user picks their email from autofill, Chrome queries a DNS record for that email domain, which points to an “issuer,” the account provider for that address (for Gmail, that is accounts.google.com). The issuer confirms the user has an active session, then hands back a signed token bundled with the site’s origin and the nonce. That package rides along with the form submission, and the site verifies the signatures before treating the email as confirmed. The whole exchange happens without the site learning anything about the user until the form is actually submitted.
It is a progressive enhancement, not a replacement: if the provider does not support EVP, or any validation step fails, the site drops back to whatever confirmation flow it already runs. That is the detail that makes it easy to underestimate. There is no flag day, no migration deadline. It just quietly reduces the number of people who bail at the “check your inbox” step, for the subset of users it applies to.
What it means for the marketing leader
Two things happen at once if EVP graduates from origin trial into a standard Chrome feature. First, signup conversion gets a quiet lift, because email confirmation is reliably one of the highest-drop-off moments between form submit and account creation. Second, and more consequential, the addresses that do make it into a CRM or marketing automation platform come pre-verified: fewer typos, fewer disposable addresses, fewer bounces before a welcome sequence ever fires. At a moment when marketers are already leaning harder on first-party data as third-party identifiers erode, a verified-at-capture email is a meaningfully cleaner input than one confirmed after the fact by a click that may never come.
That is the same pressure already reshaping how much of the data sitting in a CRM is really the marketer’s asset versus the platform’s: as the browser takes over more of the verification and identity layer, marketing teams gain cleaner data but hand more of the underlying infrastructure to Google.
Why now: the browser’s identity land grab is not new
EVP does not appear in isolation. Chrome has spent the past few years pushing passkeys as a password replacement and building out Federated Credential Management (FedCM) to let sites request identity information from a browser-mediated flow rather than a redirect-based login. EVP extends that same logic to email ownership specifically. The through-line across all three is the browser inserting itself as the trusted intermediary between a site and a user’s identity, rather than the site managing that relationship directly through email or passwords. It is the same direction of travel as the post-cookie standards work reshaping ad measurement: infrastructure that used to live in a marketer’s own stack is migrating into the browser itself.
The catch: adoption depends on two sides showing up
EVP only works when both the browser and the email provider participate, and right now that is Chrome plus Gmail. Growth teams evaluating this should treat it as a preview of direction rather than a feature to build against today: Safari, Firefox, and non-Gmail providers are not part of the current trial, and there is no committed timeline for EVP to leave origin-trial status. If it does become a default Chrome capability, it also means Google sits in the verification path for a meaningful share of the web’s signup forms, the same position it already holds in search and analytics identity.
What to do now
This is not a rebuild-your-signup-form moment yet. It is a flag-it-to-engineering moment. Marketing and growth leaders whose signup or checkout flows lean on OTPs or magic links should ask their web teams to track the origin trial and test EVP once broader browser and provider support exists, since the fix is additive rather than a redesign. In the meantime, it is worth auditing how much signup drop-off in current funnels traces specifically to the email-confirmation step: that is the number EVP is built to shrink, and it is also the number that tells a team how much upside is actually on the table when browser-verified identity becomes the default instead of the exception.
Source: Chrome for Developers
