¿Hay que tocar tu formulario de registro porque Chrome ya sabe confirmar una dirección de Gmail con un solo clic? Google abrió el 8 de julio de 2026 el origin trial de un nuevo protocolo, el Email Verification Protocol (EVP): el emisor certifica que existe una sesión activa en el proveedor de correo y el navegador transporta la prueba, sin enviar ningún email de confirmación. En la práctica, esto elimina una fricción concreta, la del código de un solo uso o el enlace de confirmación recibido por email, el paso en el que tu herramienta de emailing muestra todo en verde mientras la tasa de hard bounce sube en silencio. Lo que el protocolo demuestra, y sobre todo lo que no demuestra, se entiende en una tabla con 12 situaciones de captación.
El mecanismo del protocolo EVP, en 6 pasos
El protocolo distingue 3 roles. El validador recopila la dirección de email en su formulario. El proveedor de correo aloja el buzón. El emisor, accounts.google.com para una dirección de Gmail, gestiona la sesión de la cuenta. Poseer una dirección y tener una sesión activa en su proveedor son dos cosas distintas: el protocolo solo verifica la segunda. Además, deben cumplirse dos condiciones: el usuario tiene que estar conectado a su correo en el mismo perfil de Chrome, y elegir su dirección desde el autocompletado en lugar de escribirla a mano. Sin ellas, no se genera ningún token. El recorrido consta de 6 pasos.
- El usuario elige su dirección desde el autocompletado del navegador, nunca escribiéndola manualmente.
- Chrome consulta el registro DNS _email-verification del dominio para identificar al emisor responsable.
- El emisor confirma que existe una sesión activa para esa cuenta, sin revelar ninguna otra información sobre el usuario.
- Genera un Email Verification Token en formato SD-JWT+KB, es decir, un token de divulgación selectiva vinculado a una clave pública efímera, firmado en EdDSA o en ES256.
- El token viaja en un campo oculto del formulario en el momento del envío.
- El servidor del sitio ejecuta 5 controles: decodificación del JWT, verificación de email_verified, del nonce y de la audiencia, validación del key binding, consulta DNS y verificación de la firma mediante el endpoint well-known dedicado.
El mecanismo recuerda al de BIMI, otro protocolo apoyado en un registro DNS y en una adopción proveedor por proveedor, nunca universal desde el primer día. Si un control falla o el token está ausente, el sitio vuelve a su flujo habitual. Google lo llama una mejora progresiva.
Los métodos de verificación actuales obligan al usuario a abandonar el sitio, con el riesgo de que deje su sesión antes de terminar el registro. Rowan Merewood, Staff Developer Relations Engineer en Google, Chrome for Developers, 8 de julio de 2026.
La tabla: dónde responde el protocolo y dónde no sirve de nada
12 situaciones de captación, 12 respuestas distintas. El protocolo solo cubre un tramo estrecho del proceso de registro: aquel en el que Chrome y Gmail se combinan, con el autocompletado realmente utilizado en el mismo perfil. En Safari, Apple ya tiene su propia capa con Ocultar mi correo electrónico, un mecanismo independiente que redistribuye las direcciones de tus listas sin ninguna relación con el protocolo de Chrome.
| Situación de captación | ¿Responde EVP? | Qué hacer |
|---|---|---|
| Registro con Gmail en Chrome, dirección elegida mediante el autocompletado | Sí | El token se acepta, lo almacenas como prueba de posesión en el instante T |
| Registro con Gmail en Safari, Firefox o un navegador in-app (LinkedIn, Instagram) | No | Vuelta al flujo clásico de email de confirmación |
| Dirección profesional en un dominio sin registro DNS _email-verification | No | Verificación de la dirección antes del envío |
| Outlook, Yahoo, Proton, mientras no emitan un token | No | Verificación de dirección |
| Error tipográfico en el dominio, gmial.com en lugar de gmail.com | No, ningún emisor responde | Control de sintaxis y verificación de los registros MX |
| Catch-all corporativo | No | Verificación de dirección |
| Dirección desechable, si el proveedor llega a desplegar algún día el emisor | Sí: esa es la trampa | Detección de desechables como complemento del token |
| Dirección de rol en Workspace, contact@ o info@ | Sí, pero con valor de marketing nulo | Filtrado de direcciones de rol |
| Base ya recopilada, con varios miles de contactos en stock | Fuera de alcance por diseño | Limpieza de la base, por ejemplo con CaptainVerify |
| Dirección validada hace 8 meses, buzón lleno o cerrado desde entonces | Fuera de alcance, la validación es una foto fija | Reverificación periódica |
| Importación desde CRM, archivo de feria, captura telefónica | Fuera de alcance | Verificación de dirección |
| Prueba de consentimiento RGPD | No, el protocolo certifica una posesión técnica, insuficiente como prueba de consentimiento | Conservar un registro de opt-in independiente |
El caso más contraintuitivo cabe en una sola fila de la tabla. Una dirección desechable, alojada en un proveedor que algún día desplegara el emisor, pasaría el control EVP con un token perfectamente válido. El token no mide nada más que una sesión activa en el instante T; no dice nada sobre la vida útil prevista del buzón, ni sobre la intención real detrás del registro. Una dirección de Yopmail o Mailinator que contara con su propio emisor firmaría un token tan limpio como el de una dirección Gmail normal.
El otro punto ciego tiene que ver con el tiempo. El token confirma una posesión en el instante del registro, nunca después. En una dirección recién creada, la diferencia entre lo que afirma el protocolo y la realidad del buzón sigue siendo marginal. Pasados unos meses de inactividad, en cambio, nada en el mecanismo indica un buzón lleno o abandonado desde hace tiempo. EVP no está pensado para eso: se limita a la prueba de posesión en el momento de la captación, una foto fija que se degrada sin actualizarse jamás.
Una tercera zona de incertidumbre afecta a las direcciones profesionales. Google Workspace afirmaba tener más de 11 millones de clientes de pago en el cuarto trimestre de 2025, cifra anunciada por Sundar Pichai el 4 de febrero de 2026, es decir, otras tantas organizaciones cuyos buzones están alojados por Google. La documentación no indica si esos dominios pueden publicar el registro _email-verification y pasar a la primera columna de la tabla. La fila de la tabla depende de la ausencia de ese registro, nunca del tipo de dirección.
¿Puede el token EVP servir como prueba de cumplimiento del RGPD?
La documentación de Chrome no dedica ninguna sección a la privacidad. El RGPD no aparece. Tampoco el consentimiento de marketing, ni el plazo de conservación previsto para el token. Ese silencio traslada la decisión al responsable del tratamiento en lugar de al navegador.
Aun así, existe una salvaguarda del lado del usuario. Chrome muestra un aviso de autorización la primera vez que se facilita una dirección para su validación; ese aviso no vuelve a aparecer después para la misma dirección. La primera validación, por tanto, no ocurre sin el conocimiento de la persona registrada. Para esa dirección, las siguientes ya no piden nada más.
El token incluye datos personales concretos: el emisor (iss), la dirección o su equivalente (email), un indicador de validez (email_verified), una marca temporal (iat), una clave de confirmación (cnf), el origen del sitio (aud), un nonce y un hash de confirmación (sd_hash). Guardarlo como justificante equivale a conservar un dato personal, sometido a los principios de minimización y de limitación de la conservación. ¿Durante cuánto tiempo conservarlo? La documentación no lo especifica. Es una cuestión que hay que decidir con tu DPO y no con tu proveedor técnico.
Un detalle cambia las cosas en cuanto a minimización: el claim email puede someterse a divulgación selectiva. Configurado así, transmite un hash en lugar de la dirección en claro al validador, un ajuste que conviene comprobar antes de pasar a producción.
El artículo 7.1 del RGPD obliga al responsable del tratamiento a poder demostrar el consentimiento de la persona. Hoy, ese papel lo cumple el clic de confirmación del double opt-in. El token EVP no lo sustituye: certifica una posesión técnica del buzón en el instante del registro, sin decir nada sobre el acuerdo para recibir mensajes después. En cambio, sí resuelve otro problema que el double opt-in solo cubre de forma imperfecta: la objeción de «yo no introduje esa dirección». El double opt-in prueba el consentimiento, el token prueba la posesión del buzón en el momento del registro: un formulario que combine ambos cierra los dos frentes a la vez.
En cuanto a la confidencialidad del lado del emisor, Google es explícito: «El emisor solo ve una solicitud de verificación de la existencia del usuario, no ve qué sitio inició la solicitud». La arquitectura del token hace creíble esa afirmación: es el navegador quien construye el token de vinculación de clave que contiene el origen del sitio y el nonce, firmado con la clave efímera, después de recibir el token del emisor. Este último, por tanto, nunca necesita conocer el sitio destinatario para firmar su parte del token.
Dos preguntas quedan sin respuesta en la documentación actual. El papel jurídico exacto del emisor en la cadena no se precisa: ¿actúa como responsable del tratamiento o como encargado del tratamiento? Las transferencias fuera de la Unión Europea tampoco están documentadas: el emisor es el mismo proveedor que ya aloja el buzón de correo de la persona. No se dice nada, en cambio, sobre el tratamiento del propio token ni sobre su localización.
Calcular tu cobertura real del protocolo
Chrome representa el 65,23 % de las sesiones de navegador en el mundo en mayo de 2026, una cifra que sube al 76,39 % solo en escritorio (StatCounter, mayo de 2026). Este porcentaje global no refleja tu cobertura real de EVP, que depende únicamente de tus propios datos de tráfico y de registro. En cuanto al correo, se atribuyen a Gmail unos 1.800 millones de usuarios activos en el mundo, una estimación de Statista de noviembre de 2024 que el sector sigue citando a falta de una publicación regular por parte de Google. Ese volumen marca un techo teórico, nunca tu porcentaje real: una base alimentada con direcciones profesionales y una base alimentada con registros de consumo final no dan en absoluto el mismo porcentaje.
Bastan 3 cifras. La proporción de tráfico Chrome en tu formulario de registro, visible en Google Analytics o Matomo. La proporción de direcciones Gmail entre tus registros recientes, extrayendo el dominio de tu base ESP. Y la proporción de esos registros en los que el autocompletado rellenó realmente el campo en lugar de una escritura manual, una cifra que ninguna API devuelve de forma nativa y que hay que instrumentar uno mismo, por ejemplo comparando los eventos input y change disparados en el campo email.
Multiplicar las dos primeras cifras da un techo alto. La tercera, casi siempre ignorada, lo hace bajar.
El montaje de 3 niveles, del token al envío
El reflejo inmediato, una vez entendido el mecanismo, es este: si Chrome ya valida la dirección en el registro, ¿para qué seguir pagando una verificación antes del envío? La respuesta está en el alcance del token, que se detiene exactamente donde lo indica la tabla.
El token permite saltarse el paso del clic en el enlace de confirmación para los registros con Gmail realizados a través de Chrome. El double opt-in conserva así su propio papel, descrito más arriba: la prueba de un consentimiento activo, con marca temporal en la práctica para poder demostrarlo como exige el artículo 7.1 del RGPD. Un token EVP no sustituye ni la casilla marcada ni la marca temporal que se guardan en la base en el momento del consentimiento.
Desde 2024, Google fija un umbral de complaint rate del 0,3 % para los envíos masivos, bajo pena de que los mensajes se marquen como spam o se rechacen del lado de Gmail, una cifra que ya se ve en las tablas de Google Postmaster Tools por dominio remitente. Una dirección desechable o un buzón cerrado que aun así reciba la campaña empuja esa tasa al alza, incluso en plena fase de IP warmup, con independencia de lo que mostrara el token en el registro. La deliverability se juega en el momento del envío, cuando la captación ya queda muy atrás. No es el primer protocolo técnico que rediseña un eslabón de la cadena sin eliminar los demás: DKIM2 siguió la misma lógica del lado de la autenticación de los mensajes.
El control que verifica la sintaxis, el dominio MX y a veces el historial de deliverability antes del envío, el que hace CaptainVerify, encaja de forma lógica entre la captación y la campaña. La única forma de saber si tu base necesita ese filtro es pasarla por una muestra antes del próximo envío.
Lo mínimo que hay que conservar en la base: el registro de opt-in RGPD, el estado del último control de list hygiene y la fecha de la última campaña enviada sin rebotes. El token EVP, por su parte, no está pensado para almacenarse más allá de la sesión de registro.
Gmail sigue siendo hoy el único emisor de uso masivo. El protocolo, por su parte, lo impulsan los navegadores Chromium: Chrome desde su versión 150, Edge mediante su propio origin trial del lado de Microsoft. Su trayectoria hacia la estandarización ya está trazada: un Internet-Draft firmado por Dick Hardt y Sam Goto está depositado en la IETF desde el 17 de junio de 2026, en una revisión fechada el 4 de julio, presentado a título individual, sin grupo de trabajo ni validación por el momento. Validity estima en su análisis de julio de 2026 que el double opt-in hace perder entre el 20 y el 35 % de los inscritos en el momento de la confirmación, una fricción que EVP podría reducir efectivamente del lado de Gmail. Si Outlook o Yahoo llegan a desplegar algún día su propio emisor, la primera columna de la tabla se ampliará; sin ellos, sigue limitada a Gmail.
Preguntas frecuentes sobre el Email Verification Protocol
¿Funciona el protocolo EVP en móvil o dentro de una aplicación?
La documentación no zanja explícitamente este punto. El protocolo presupone el autocompletado del navegador, lo que excluye de hecho los contextos en los que no está disponible, en particular algunos navegadores in-app.
¿Qué navegadores admiten EVP en 2026?
Chrome desde la versión 150, a través del origin trial abierto el 8 de julio de 2026. Edge le sigue con su propio origin trial, incluido en la sección Implementation Status del draft de la IETF: el mismo mecanismo Chromium, con un token que hay que registrar del lado de Microsoft, distinto del de Chrome. Del lado de Safari, no hay ningún anuncio hasta la fecha.
¿Funciona el protocolo con Outlook o Yahoo?
Todavía no. Gmail es el único proveedor de correo que emite tokens en el lanzamiento. La API destinada a otros proveedores de correo sigue en desarrollo en Google.
¿Hay que activar el origin trial desde ya?
Solo si Chrome y Gmail representan una parte medible de tus registros. El trial impone límites de tráfico y un fallback obligatorio hacia el email de confirmación clásico en caso de fallo.
