Looking at sign-up form metrics, there is always one stage where users drop off. People progress through entering their email address, but vanish on the verification code entry screen.
When you break down what users are being asked to do, the reason is obvious. They enter their address in the form, switch to an email app, wait for delivery, search their spam folder, copy the code, and return to the original site to paste it. Someone who just wants to create an account is forced to bounce between two different applications.
People have long recognized that this flow is problematic, but alternatives simply did not exist. There was no way to confirm ownership other than sending something to that address. The Email Verification Protocol (EVP) is a proposal designed to address this challenge.
The verification round trip blocks the registration doorway
According to explanatory materials submitted to the WICG, out of the top 50 high-traffic websites, 95% support account creation via email address, and 73% of those halt the account creation process until email verification is completed.
In other words, email verification is not an exceptional step, but the default gatekeeper when creating accounts on the web. And because it is a gatekeeper, anyone who cannot pass through it never reaches the service.
In practice, issues manifest in ways like these:
- Inquiries arrive saying expected emails never showed up (spam filtering, corporate security filters)
- Verification codes expire, leading to repeated resend attempts
- A user attempts to sign up with a corporate address, but the email cannot be opened because it is a shared mailbox
- Users straddle smartphones and desktop computers, failing to return to the original screen in the first place
While standard form improvements like reducing fields and providing input assistance were covered in EFO (Form Optimization), the verification code round trip persists no matter how much you polish form design. This is because the step forces users outside the website entirely.
What EVP changes is the "source of proof"
EVP is a mechanism for verifying address ownership without sending an email.
Under this flow, when a user enters an address on a website, the browser receives a signed token from that email provider and presents it to the site. By verifying the token's signature, the site confirms that the user owns the address. No confirmation email is generated, and the user never needs to open an email application.
The entity generating proof shifts from an email inbox to an interaction between the browser and the email provider. From the user's perspective, it feels similar to selecting an email address, bringing the experience closer to an account selector screen.
As an added benefit, inherent phishing resistance cannot be overlooked. The proof of ownership generated by the browser contains the origin of the website open at that moment. Proof obtained on a spoofed site will not pass validation on the genuine site. Furthermore, because the email provider can see which site requested verification, opportunities emerge to detect suspicious requests on the spot.
As part of the movement toward eliminating passwords in favor of holding keys on user devices, this follows the same direction as Migrating to Passkeys. It is easier to contextualize by viewing it as distinct mechanisms targeting distinct problems: passkeys for login authentication, and EVP for address verification during registration.
It is not yet a "usable standard"
This is the single most critical point for decision-making: EVP remains in the proposal stage.
An IETF Internet-Draft was published in June 2026, and an Origin Trial began in Chrome starting in July 2026. Edge is in a similar testing phase. Meanwhile, Mozilla and WebKit are currently maintaining a wait-and-see stance. In short, it will not reach Safari and Firefox users for the foreseeable future.
In Japan, iPhone market share is high, meaning designs that disregard Safari directly translate into lost opportunities. The principles for judging whether a feature is safely usable across browsers follow what was covered in Corporate Site Implementation Grounded in Baseline, and EVP does not meet that standard today.
Therefore, choosing to "eliminate verification codes and replace them with EVP" is not viable for websites being built right now. The specification is designed around this reality, anticipating fallback options to conventional verification codes or magic links for unsupported browsers and email addresses.
What commissioning clients can decide right now
There is no need to spend budget on features that may or may not be adopted later. However, you can decide today whether to build your architecture so components can be swapped out later.
Decouple the verification step as an independent component. If code generation, verification, resending, and expiration handling are scattered across your registration logic, switching methods will require altering the registration flow itself. If isolated into a dedicated role of "verifying address ownership," adopting a new method later only requires adding the new mechanism. This can be settled simply by inserting a single requirement during the scoping phase.
Implement drop-off tracking in advance. Track completed email inputs and completed verifications as separate metrics. The difference between these two figures represents the exact volume of users lost to the verification round trip. Without numbers, you cannot demonstrate the effectiveness of changing methods later. With them, you can prioritize improvements through comparative data rather than gut feeling.
Verify confirmation email delivery rates first. Before waiting for new mechanisms, it is worth verifying whether your existing emails are being delivered reliably. Many sites still operate with inadequate sender domain authentication, in which case the problem precedes any protocol switch.
Decide how much access to grant immediately after registration. Will you block all functionality until verification is complete, or allow read-only access? While the aforementioned 73% figure reflects that hard lockouts remain the majority, requirements can sometimes be relaxed depending on data sensitivity. This is a business decision, not a technical one.
What to do next
On your own sign-up forms, check what percentage of people who enter an email address actually complete verification. Most businesses lack this figure. Once you measure it, that number becomes the baseline for all subsequent decisions.
Beyond that, if you plan to build a new form, include a requirement to keep the verification step modular and replaceable. The difference between the cost of adopting EVP once widely supported versus rebuilding from scratch at that time is decided right here.
GleamHub provides guidance on designing registration flows, selecting authentication mechanisms, and mitigating drop-offs on existing forms through our Development, AI, and Automation consultation. Optimal designs vary depending on user demographics and data sensitivity, so please contact us individually. Get in touch via Contact Us.
