IETF approves a working-group-forming BoF on Email Address Verification, scheduled for IETF 127
A working-group-forming IETF BoF on Email Address Verification, built on the Email Verification Protocol draft, was approved on October 8, 2026 and is on the IETF 127 agenda for November 17, 2026 in San Francisco.
What happened
The IETF approved a BoF request titled Email Address Verification on October 8, 2026, with the status "WG forming" and Andy Newton (ART area) as responsible AD. The session is on the IETF 127 agenda for Tuesday, November 17, 2026, 14:00 to 16:00 Pacific, in San Francisco. Proponents are Dick Hardt and Sam Goto.
Per the BoF request, the proposed working group would start from two proposals:
- The Email Verification Protocol (EVP), in which the browser or operating system obtains an issuer-signed token that the user controls an address, with no message sent. The email domain delegates to the issuer through DNS, and the issuer does not learn which application asked. The current text is draft-hardt-email-verification-02, dated August 25, 2026.
- An OTP-Token email header field that carries an origin-bound one-time code in a machine-readable header, for email domains without an EVP issuer.
The request says EVP was presented at DISPATCH at IETF 126 in Vienna, which recommended a BoF, and that EVP is in origin trials in Chrome and Edge, with Gmail operating an issuer. The browser API is developed separately in the W3C WICG.
Why it matters
Email verification by code or link is in almost every CIAM sign-up flow. The BoF request names its problems directly: users abandon while switching to their mail client, codes carried by hand can be phished by any site that asks, and the email provider learns which application the user signed up with. A standard browser-mediated token would remove all three for domains that support it.
Deepak's take
This is the email equivalent of what WebOTP and origin-bound SMS codes did for phone verification, and the BoF request makes that comparison itself. The part I would watch is the private per-site address. If browsers make relay addresses a one-click default, email stops being a reliable cross-site identifier, which is good for users and a real change for any CIAM or marketing system that matches customers by email.
A BoF is not a working group, and a working group is years from an RFC. Nothing here changes what you ship this quarter.
What to do
- CIAM teams: keep the email verification step pluggable, so a verified-token path can sit next to OTP and magic links later.
- Data teams: do not assume one email per person across properties; private per-site addresses are part of the design.
- Further reading: magic links vs OTP for today's options.