--- title: Test the Email Verification Protocol with an origin trial description: Chrome is introducing an Email Verification Protocol (EVP) available via origin trial starting in Chrome 150. The API lets browsers communicate directly with... canonical: https://daily.dev/posts/test-the-email-verification-protocol-with-an-origin-trial-e6auhyjzb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Test the Email Verification Protocol with an origin trial | daily.dev og:description: Chrome is introducing an Email Verification Protocol (EVP) available via origin trial starting in Chrome 150. The API lets browsers communicate directly with... og:url: https://daily.dev/posts/test-the-email-verification-protocol-with-an-origin-trial-e6auhyjzb og:image: https://api.daily.dev/og/posts/E6AuHYjZb.png og:image:alt: Test the Email Verification Protocol with an origin trial og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Test the Email Verification Protocol with an origin trial **[Lobsters](https://daily.dev/sources/lobsters)** · 12 min read · 0 upvotes · 0 comments ## Summary Chrome is introducing an Email Verification Protocol (EVP) available via origin trial starting in Chrome 150. The API lets browsers communicate directly with email providers to verify ownership of an email address without sending OTPs or magic links, eliminating the need for users to leave the current site. The flow uses DNS TXT records, a .well-known endpoint, Selective Disclosure JWTs (SD-JWT+KB), and the Login Status API. Detailed implementation steps are provided for both verifier sites (form field configuration, EVT validation in 5 steps) and email provider/issuer services (DNS setup, .well-known endpoints, issuance request handling). The feature is a progressive enhancement with fallback to traditional email confirmation if unsupported. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 6 discussions and 14 comments across lobsters, hackernews (as of 2026-08-01). **TL;DR:** The Lobsters community is largely skeptical of the Email Verification Protocol (EVP), viewing it as a Google-driven proposal that would entrench large email providers like Gmail, undermine email aliases/privacy tools, and is essentially just OpenID in disguise. A minority see it as a manageable enhancement with reasonable fallback behavior. **Sentiment:** 10% positive · 25% mixed · 65% skeptical **The case for** - Smaller email providers could realistically implement the required DNS record and HTTP endpoints without enormous effort. - The spec appears to have at least considered private/directed email addresses, with an opt-in upgrade path for revealing the real address. - A permissive verification server could theoretically enable anonymous account creation without exposing a real email to spam. **The pushback** - The proposal effectively requires email providers to run HTTP/webmail infrastructure, disadvantaging small providers and self-hosters and consolidating power around Gmail/Microsoft. - No actual email is sent during verification, so deliverability is not confirmed and subsequent emails may be treated as unsolicited. - Commenters argue it is functionally just OpenID/FedCM rebranded, adding complexity without meaningful new capability. - The design could kill or complicate the use of email aliases and one-time generated addresses. - Google's dominant browser and email market share means this proposal could unilaterally reshape internet identity infrastructure for Google's benefit. **By community** - lobsters (skeptical): Commenters are broadly critical, framing EVP as a Gmail/Microsoft oligopoly play that bypasses real email delivery, mirrors OpenID, and burdens smaller providers. - hackernews (mixed): No substantive comments were present in the Hacker News threads. **Hottest debate:** Whether EVP will entrench large email providers and kill smaller/self-hosted alternatives, or whether smaller providers can realistically implement it as just another DNS/HTTP record. **Open questions** - Will Firefox and WebKit actually adopt this, or will it remain a Chromium-only feature? - How would truly anonymous logins work for a self-hosted 'email provider' acting as an EVP issuer? - Does the absence of actual email delivery in the EVP flow make it unsuitable as a real email verification mechanism? **Highlights** > > The user must be signed in to their email provider or issuer on the same browser profile“; „As an issuer […] [y]ou just need to ensure the expected endpoints are in place to respond to those requests. So this is going to require the e-mail provider to run HTTP infrastructure, including a webmailer, to work, that is, it places even more burden and attack surface onto e-mail providers. It is thus likely that only large e-mail providers are going to implement it – most notably, probably, GMail – and smaller ones (especially selfhosters) not. However, as users come to expect that feature, they will be restricted in their choice of e-mail providers to the large ones, like, um... GMail? > Existing verification methods, like one-time passwords (OTPs) or email verification links (magic links), require the user to navigate away from your site. Or rather, require the user to engage knowingly with their respective e-mail provider, who is certainly glad to get noticed, and require the user to think twice whether it’s really worth signing up at your service. This entire proposal looks like just another attempt to secure the GMail/Microsoft oligopoly on e-mail by driving out smaller providers that are not willing to take even more work onto them. > — [quintus on lobsters · 8 points, 2 comments](https://lobste.rs/s/72ni5s/test_email_verification_protocol_with#c_hzewza) > This completely drops what is often a rather important part of verification: deliverability. In fact, the more I’ve thought about it, the fascinating and bizarre thing about this is that it’s *literally nothing to do with email*. It merely uses email address *syntax*. In the traditional flow, you confirm that at least one email actually got through, which drastically increases the odds that more will. In this EVP flow, no actual email is sent, and the email service provider doesn’t learn what website it is that is asking for email verification, so if you subsequently send an email, it may seem to be out of the blue, which increases its odds of being rejected. But as I have realised, it’s not even anything to do with email. Simplifying a little, it’s actually just “when I enter localpart@issuer.example, prove that the user is logged into https://issuer.example as ‘localpart’”. issuer.example need not even have an MTA/email server. > — [chrismorgan on lobsters · 6 points, 1 comments](https://lobste.rs/s/72ni5s/test_email_verification_protocol_with#c_e9k2xr) > When looking at Google proposals, it's usually informative to apply some systems thinking. What would this accomplish? It would corral users to big email providers, and it would ensure they stick to one trackable identity. > — [marginalia on lobsters · 5 points](https://lobste.rs/s/72ni5s/test_email_verification_protocol_with#c_u0xn3q) > This stuff is insane. I'm reading the [Email Verification API](https://github.com/WICG/email-verification). There's this: > There are orders of magnitude more users (say, ~billions) than websites (say, ~millions) than email providers (say, ~thousands) than browser vendors (say, ~tens), so our proposal focuses on pulling change in the reverse order: make browsers pull as much responsibility as possible, Three. There are *three* browser vendors, Google, Apple and Firefox. And Google has what? 80+% of the market? The cynic in me wants to say someone at Google is angling for a promotion and as a result, again going to dictate the direction of the Internet. > For better or for worse, the current deployment of email providers follows a power law (e.g. ~10 email providers account for 50%+ of the market share), so we expect that incentivizing the head/torso of email providers might provide enough activation energy to bootstrap the flywheel. > ... > A significant part of the deployment of FedCM is represented by email providers: most notably google.com (which is authoritative to gmail.com email addresses, accounts for ~45% of the email provider market share) seznam.cz, and gmx.de / web.de (account for a large portion of the market share in Europe). Scary stuff here. > We think it is plausible that the browser might be able to help the user user login to the email provider / issuer inline in the flow. It is not quite clear to us yet how, but one of the intuitions is that we can offer a streamlined experience through passkeys: Really? Most people use a web interface to read email? One protocol to rule them all, and in the darkness, bind them? One last bit: > It seems to us that you could make the system quite a bit more generic by changing a few words, and introducing a mechanism by which an identifier could be tied to an issuer absent an explicit @provider.example in the string (e.g. another input field whose value is inferred from the identifier if possible, or set by the site for social sign in). > — [spc476 on lobsters · 1 points](https://lobste.rs/s/72ni5s/test_email_verification_protocol_with#c_oacvpo) > Nah, if something like this gains traction, smaller providers will implement it, no trouble, and add the _email-verification record to their DNS templates and advice. Most people already using their own domains wouldn’t get it until they added it manually, but it wouldn’t be hard to do. If you’re not using the ESP’s nameservers, there are already always at least four records to set (MX, SPF, DKIM, DMARC), and commonly a dozen or more if you want to do things comprehensively (e.g. autodiscovery is one or two records each for SMTP, IMAP, POP3, CalDAV, CardDAV, JMAP…), and this is just adding one more to that larger set. But remember that this is all *supposed* to be just an enhancement, with fallback to the existing system. And I think it will be so, because it will remain common enough for it to not be supported, that such fallback will need to exist. > — [chrismorgan on lobsters · 1 points](https://lobste.rs/s/72ni5s/test_email_verification_protocol_with#c_g1vrjl) **Source threads** - [lobsters](https://lobste.rs/s/72ni5s/test_email_verification_protocol_with) · 17 points · 14 comments - [hackernews](https://news.ycombinator.com/item?id=49106105) · 4 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=48867249) · 3 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=48844115) · 3 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=49133888) · 2 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=48857472) · 1 points · 0 comments ## Similar posts on daily.dev - [WICG/email-verification-protocol: verified autofill](https://daily.dev/posts/wicg-email-verification-protocol-verified-autofill-krvbysrq9) · Hacker News · 23 upvotes · 2 comments - [Streamline User Journeys with Verified Email via Credential Manager](https://daily.dev/posts/streamline-user-journeys-with-verified-email-via-credential-manager-qxsxzc7o2) · Android Developers Blog · 1 upvotes · 0 comments - [Digital Credentials API for credential issuance](https://daily.dev/posts/digital-credentials-api-for-credential-issuance-tpov6wf4y) · Chrome Developers · 1 upvotes · 0 comments - [How I Found an Email Verification Bypass on an AI Freelance Platform](https://daily.dev/posts/how-i-found-an-email-verification-bypass-on-an-ai-freelance-platform-u8qbqrzz7) · InfoSec Write-ups · 0 upvotes · 0 comments - [Digital Credentials API: Secure and private identity on the web](https://daily.dev/posts/digital-credentials-api-secure-and-private-identity-on-the-web-lt5j5nrqr) · Chrome Developers · 0 upvotes · 0 comments --- Tags: [#authentication](https://daily.dev/tags/authentication), [#google-chrome](https://daily.dev/tags/google-chrome) [View this post on daily.dev](https://daily.dev/posts/test-the-email-verification-protocol-with-an-origin-trial-e6auhyjzb) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Test the Email Verification Protocol with an origin trial","url":"https://daily.dev/posts/test-the-email-verification-protocol-with-an-origin-trial-e6auhyjzb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/test-the-email-verification-protocol-with-an-origin-trial-e6auhyjzb"},"datePublished":"2026-08-01T17:27:58.875Z","dateModified":"2026-08-01T23:33:37.167Z","description":"Chrome is introducing an Email Verification Protocol (EVP) available via origin trial starting in Chrome 150. The API lets browsers communicate directly with...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10155a6502b12bf0f06f0b8ad52a04d5?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10155a6502b12bf0f06f0b8ad52a04d5?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/test-the-email-verification-protocol-with-an-origin-trial-e6auhyjzb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"authentication,google-chrome","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Test the Email Verification Protocol with an origin trial"}]} ```