Atualizações na verificação de e-mail, outubro de 2026

Rowan Merewood

Publicado em: 5 de outubro de 2026

À medida que o teste de origem da verificação de e-mail continua, fizemos mais atualizações com base no seu feedback. Não esperamos mais mudanças significativas e estamos nos preparando para lançar o recurso. Também lançamos uma nova seção de documentação para a verificação de e-mail com seções dedicadas para verificadores e emissores.

O teste de origem da verificação de e-mail começou no Chrome 150 para computadores. Com base no feedback dos desenvolvedores e nos testes em todo o ecossistema, continuamos a refinar a implementação. Esta postagem aborda atualizações do Chrome 154, incluindo suporte para Android, testes de origem de terceiros, tratamento de descoberta de chaves durante a validação de tokens e uma atualização de cabeçalho para provedores de e-mail.

Atualizações voltadas ao usuário

Mudanças na interface do usuário ou no comportamento voltado ao usuário.

Suporte do Chrome no Android

A partir do Chrome 154, o Google Chrome para Android é compatível com a verificação de e-mail. Os verificadores ou provedores não precisam fazer mudanças porque a API ou o protocolo permanece o mesmo. Os mesmos pré-requisitos se aplicam, incluindo a exigência de que o usuário esteja conectado ao provedor de e-mail no navegador.

Os usuários podem acessar as configurações em Configurações > Endereços e mais > E-mail verificado.

Atualizações do verificador

Mudanças para sites que coletam e verificam e-mails.

Testes de origem de terceiros

A partir do Chrome 154, os testes de origem de terceiros são compatíveis com a verificação de e-mail (consulte o problema 534377131). Se você fornecer um script incorporado ou um SDK de identidade, agora poderá se registrar para receber um token de teste de terceiros e injetá-lo nas páginas que hospedam seu script. Os sites que incorporam seu script não precisam registrar tokens de teste de origem separados.

Há uma observação importante: o registrante do teste de origem e o emissor precisam ser do mesmo site. Especificamente, a origem registrada para o teste precisa corresponder ao domínio do emissor.

Configuração compatível:

  • Domínio do emissor: issuer.example
  • Registrante de OT: https://issuer.example
  • Origem do JavaScript: https://issuer.example (ou https://app.issuer.example com correspondência de subdomínio)

Configurações não compatíveis:

  • Registrante do subdomínio: o domínio do emissor é issuer.example, mas o registrante do OT é https://app.issuer.example.
  • Responsável pelo registro entre sites: o domínio do emissor é issuer.example, mas o responsável pelo registro da OT é https://different.example.

Processar kid opcional no EVT

Ao validar o token de verificação de e-mail (EVT), seu servidor busca o conjunto de chaves da Web JSON (JWKS) do provedor para verificar a assinatura criptográfica do emissor. As chaves podem incluir um identificador kid, que também pode ser incluído no JWT para indicar qual chave foi usada para assinar o token. Se o token não incluir a declaração kid (por exemplo, com o Gmail), itere pelas chaves para encontrar a correta. A documentação e a demonstração mostram o código para fazer isso.

Retornar a reivindicação email exatamente como foi fornecida

A partir do Chrome 156, o endereço de e-mail no token será retornado exatamente como fornecido no envio do formulário (consulte o problema 549217427). Antes, os emissores podiam retornar o endereço de e-mail canônico da conta (por exemplo, retornando First.Last@example.com quando o envio do formulário continha first.last@example.com). É sempre recomendável usar uma comparação sem diferenciação de maiúsculas e minúsculas no e-mail retornado. Portanto, essa não deve ser uma mudança incompatível.

Atualizações do provedor

Mudanças para provedores de e-mail.

Retornar a reivindicação email exatamente como foi fornecida

Do lado do provedor, esse requisito é mais rigoroso: se o provedor não retornar o e-mail exatamente como fornecido, o Chrome vai rejeitar o token. Isso evita expor mais dados do que seria revelado pelo envio de um e-mail de confirmação. Valide o e-mail recebido com o usuário conectado para encontrar uma correspondência da mesma forma que você processaria a entrega de e-mails.

Renomear Sec-Fetch-Dest como email-verification

A partir do Chrome 154, o cabeçalho Sec-Fetch-Dest enviado em solicitações de emissão de token foi atualizado para usar um hífen:

  • Chrome 154 ou mais recente: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

Essa mudança padroniza o identificador de destino de busca com as convenções de nomenclatura da plataforma da Web (consulte o problema 546618576).

Se o endpoint de emissão validar o cabeçalho Sec-Fetch-Dest (recomendado para proteger contra CSRF e contextos de solicitação não intencionais), atualize a verificação para aceitar email-verification. Para evitar interrupções durante os lançamentos de navegadores, aceite os dois valores durante a transição.

Recursos e feedback