Actualizaciones de la verificación por correo electrónico, octubre de 2026

Rowan Merewood

Publicado: 5 de octubre de 2026

A medida que continúa la prueba de origen de la Verificación de correo electrónico, realizamos más actualizaciones en función de tus comentarios. No prevemos más cambios que interrumpan la función y nos estamos preparando para lanzarla. También lanzamos una nueva sección de documentación para la verificación de correo electrónico con secciones exclusivas para verificadores y emisores.

La prueba de origen de la verificación de correo electrónico comenzó en Chrome 150 para computadoras. Después de recibir comentarios de los desarrolladores y realizar pruebas en todo el ecosistema, seguimos perfeccionando la implementación. En esta publicación, se incluyen las actualizaciones de Chrome 154, como la compatibilidad con Android, las pruebas de origen de terceros, el control del descubrimiento de claves durante la validación de tokens y una actualización del encabezado para los proveedores de correo electrónico.

Actualizaciones para el usuario

Cambios en la interfaz de usuario o en el comportamiento visible para el usuario

Compatibilidad de Chrome en Android

A partir de Chrome 154, Chrome para Android admite la verificación por correo electrónico. Los verificadores o proveedores no necesitan realizar ningún cambio porque la API o el protocolo siguen siendo los mismos. Se aplican los mismos requisitos previos, incluido el requisito de que el usuario debe haber accedido a su proveedor de correo electrónico en el navegador.

Los usuarios pueden acceder a su configuración en Configuración > Direcciones y más > Correo electrónico verificado.

Actualizaciones del verificador

Cambios para los sitios que recopilan y verifican correos electrónicos

Pruebas de origen de terceros

A partir de Chrome 154, se admiten las pruebas de origen de terceros para la verificación de correo electrónico (consulta el problema 534377131). Si proporcionas un SDK de identidad o un script integrado, ahora puedes registrarte para obtener un token de prueba de terceros y, luego, insertarlo en las páginas que alojan tu script. Los sitios web que incorporan tu secuencia de comandos no necesitan registrar tokens de prueba de origen separados.

Sin embargo, hay una advertencia importante: el registrante de la prueba de origen y la entidad emisora deben ser del mismo sitio. Específicamente, el origen registrado para la prueba debe coincidir con el dominio del emisor.

Configuración admitida:

  • Dominio de la entidad emisora: issuer.example
  • Registrante de OT: https://issuer.example
  • Origen de JavaScript: https://issuer.example (o https://app.issuer.example con coincidencia de subdominio)

Configuraciones no admitidas:

  • Registrante del subdominio: El dominio del emisor es issuer.example, pero el registrante de la OT es https://app.issuer.example.
  • Registrante en varios sitios: El dominio de la entidad emisora es issuer.example, pero el registrante de OT es https://different.example.

Controla el kid opcional en el EVT

Cuando valida el token de verificación de correo electrónico (EVT), su servidor recupera el conjunto de claves web JSON (JWKS) del proveedor para verificar la firma criptográfica del emisor. Las claves incluyen, de forma opcional, un identificador de clave kid que también se incluye, de forma opcional, en el JWT para indicar qué clave se usó para firmar el token. Si el token no incluye el reclamo kid (por ejemplo, con Gmail), itera las claves para encontrar la correcta. La documentación y la demostración muestran el código para hacerlo.

Devuelve el reclamo email exactamente como se proporcionó.

A partir de Chrome 156, la dirección de correo electrónico del token se devolverá exactamente como se proporcionó en el envío del formulario (consulta el problema 549217427). Anteriormente, es posible que los emisores hayan devuelto la dirección de correo electrónico canónica de la cuenta (por ejemplo, devolviendo First.Last@example.com cuando el envío del formulario contenía first.last@example.com). Ten en cuenta que siempre es una buena práctica usar una comparación que no distinga mayúsculas de minúsculas en el correo electrónico devuelto, por lo que esto no debería ser un cambio que genere errores.

Actualizaciones del proveedor

Cambios para los proveedores de correo electrónico

Devuelve el reclamo email exactamente como se proporcionó.

Desde el lado del proveedor, este requisito es más estricto: si el proveedor no devuelve el correo electrónico exactamente como se proporcionó, Chrome rechazará el token. Esto evita exponer más datos de los que se revelarían si se enviara un correo electrónico de confirmación. Valida el correo electrónico entrante en relación con el usuario que accedió de la misma manera en que controlarías la entrega de correos electrónicos.

Se cambió el nombre de Sec-Fetch-Dest a email-verification.

A partir de Chrome 154, el encabezado Sec-Fetch-Dest que se envía en las solicitudes de emisión de tokens se actualizó para usar un guion:

  • Chrome 154 y versiones posteriores: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

Este cambio estandariza el identificador de destino de recuperación con las convenciones de nomenclatura de la plataforma web (consulta el problema 546618576).

Si tu extremo de emisión valida el encabezado Sec-Fetch-Dest (se recomienda para proteger contra CSRF y contextos de solicitudes no intencionales), actualiza tu verificación para aceptar email-verification. Para evitar interrupciones durante los lanzamientos del navegador, acepta ambos valores durante la transición.

Recursos y comentarios