É preciso mudar seu formulário de inscrição porque o Chrome agora sabe confirmar um endereço Gmail em um clique? Em 8 de julho de 2026, o Google abriu o origin trial de um novo protocolo, o Email Verification Protocol (EVP): o emissor atesta que existe uma sessão ativa no provedor de e-mail e o navegador transporta a prova, sem envio de e-mail de confirmação. Na prática, isso elimina uma fricção específica, a do código de uso único ou do link de confirmação recebido por e-mail, a etapa em que sua ferramenta de e-mail marketing mostra tudo verde enquanto a taxa de hard bounce sobe silenciosamente. O que o protocolo prova e, principalmente, o que ele não prova, está detalhado em uma grade com 12 situações de coleta.
O mecanismo do protocolo EVP, em 6 etapas
O protocolo distingue 3 papéis. O validador coleta o endereço de e-mail em seu formulário. O provedor de e-mail hospeda a caixa de entrada. O emissor, accounts.google.com no caso de um endereço Gmail, gerencia a sessão da conta. Ter um endereço e ter uma sessão ativa no provedor são duas coisas distintas: o protocolo verifica apenas a segunda. Ainda é preciso que duas condições sejam atendidas. O usuário precisa estar conectado ao e-mail no mesmo perfil do Chrome. Ele também precisa escolher o endereço pelo autocompletar, em vez de digitá-lo manualmente. Sem essas condições, nenhum token é gerado. O processo tem 6 etapas.
- O usuário escolhe o endereço pelo autocompletar do navegador, nunca por digitação manual.
- O Chrome consulta o registro DNS _email-verification do domínio para identificar o emissor responsável.
- O emissor confirma que existe uma sessão ativa para essa conta, sem revelar nenhuma outra informação sobre o usuário.
- Ele gera um Email Verification Token no formato SD-JWT+KB, ou seja, um token de divulgação seletiva vinculado a uma chave pública efêmera, assinado em EdDSA ou ES256.
- O token trafega em um campo oculto do formulário no momento do envio.
- O servidor do site executa 5 verificações: decodificação do JWT, verificação de email_verified, do nonce e da audience, validação do key binding, consulta DNS e, por fim, verificação de assinatura por meio do endpoint well-known dedicado.
O mecanismo lembra o do BIMI, outro protocolo que depende de um registro DNS e de uma adoção provedor por provedor, nunca universal desde o primeiro dia. Se alguma verificação falhar ou se o token estiver ausente, o site volta ao fluxo habitual. O Google chama isso de aprimoramento progressivo.
Os métodos de verificação atuais obrigam o usuário a sair do site, com o risco de que ele abandone a sessão antes de concluir a inscrição. Rowan Merewood, Staff Developer Relations Engineer no Google, Chrome for Developers, 8 de julho de 2026.
A grade: onde o protocolo responde, onde ele não serve para nada
12 situações de coleta, 12 respostas diferentes. O protocolo cobre apenas uma fatia estreita da jornada de inscrição: aquela em que Chrome e Gmail se combinam, com o autocompletar realmente utilizado no mesmo perfil. No Safari, a Apple já tem sua própria camada com o Ocultar meu e-mail, um mecanismo independente que redistribui os endereços das suas listas sem nenhuma relação com o protocolo do Chrome.
| Situação de coleta | O EVP responde? | O que você faz |
|---|---|---|
| Inscrição Gmail no Chrome, endereço escolhido pelo autocompletar | Sim | O token é aceito, você o armazena como prova de posse no momento T |
| Inscrição Gmail no Safari, Firefox ou em um navegador in-app (LinkedIn, Instagram) | Não | Retorno ao fluxo tradicional de e-mail de confirmação |
| Endereço profissional em um domínio sem registro DNS _email-verification | Não | Verificação de endereço antes do envio |
| Outlook, Yahoo, Proton, enquanto não emitirem token | Não | Verificação de endereço |
| Erro de digitação no domínio, gmial.com em vez de gmail.com | Não, nenhum emissor responde | Verificação de sintaxe e checagem dos registros MX |
| Catch-all corporativo | Não | Verificação de endereço |
| Endereço descartável, se o provedor um dia implementar o emissor | Sim: é a armadilha | Detecção de descartáveis como complemento ao token |
| Endereço de função no Workspace, contact@ ou info@ | Sim, mas valor de marketing nulo | Filtragem de endereços de função |
| Base já coletada, com milhares de contatos em estoque | Fora do escopo por natureza | Limpeza de base, por exemplo com o CaptainVerify |
| Endereço validado há 8 meses, caixa cheia ou fechada desde então | Fora do escopo, a validação é um instantâneo | Reverificação periódica |
| Importação de CRM, arquivo de feira, cadastro por telefone | Fora do escopo | Verificação de endereço |
| Prova de consentimento RGPD | Não, o protocolo atesta uma posse técnica, insuficiente como prova de consentimento | Manter um registro de opt-in separado |
O caso mais contraintuitivo está em uma única linha da tabela. Um endereço descartável, hospedado em um provedor que um dia viesse a implementar o emissor, passaria pela verificação EVP com um token perfeitamente válido. O token não mede nada além de uma sessão ativa no momento T; ele não diz nada sobre a vida útil prevista da caixa, nem sobre a intenção real por trás da inscrição. Um endereço Yopmail ou Mailinator que tivesse seu próprio emissor assinaria um token tão limpo quanto o de um endereço Gmail comum.
O outro ponto cego é o tempo. O token confirma uma posse no instante da inscrição, nunca depois. Em um endereço recém-criado, a diferença entre o que o protocolo afirma e a realidade da caixa é marginal. Passado algum tempo de inatividade, porém, nada no mecanismo sinaliza uma caixa cheia ou abandonada. Aliás, o EVP não tem a função de fazer isso: ele se limita à prova de posse no momento da coleta, um instantâneo que se degrada sem nunca ser atualizado.
Uma terceira zona de incerteza envolve os endereços profissionais. O Google Workspace afirmava ter mais de 11 milhões de clientes pagantes no 4º trimestre de 2025, número anunciado por Sundar Pichai em 4 de fevereiro de 2026, ou seja, outras tantas organizações cujas caixas são hospedadas pelo Google. A documentação não diz se esses domínios podem publicar o registro _email-verification e entrar na primeira coluna da grade. A linha da tabela permanece condicionada à ausência desse registro, nunca ao tipo de endereço.
O token EVP pode servir como prova de RGPD?
A documentação do Chrome não dedica nenhuma seção à privacidade. O RGPD não é mencionado. O consentimento de marketing também não, nem o prazo de retenção previsto para o token. Esse silêncio transfere a decisão para o responsável pelo tratamento, e não para o navegador.
Ainda assim, existe uma proteção do lado do usuário. O Chrome exibe um aviso de autorização na primeira vez que um endereço é fornecido para validação; esse aviso não aparece mais depois para o mesmo endereço. A primeira validação acontece, portanto, com o conhecimento da pessoa inscrita. Para esse endereço, as próximas validações não pedem mais nada.
O token carrega dados pessoais concretos: o emissor (iss), o endereço ou seu equivalente (email), um indicador de validade (email_verified), uma marcação de tempo (iat), uma chave de confirmação (cnf), a origem do site (aud), um nonce e um hash de confirmação (sd_hash). Armazená-lo como comprovante equivale a conservar um dado pessoal, sujeito aos princípios de minimização e de limitação da conservação. Por quanto tempo mantê-lo? A documentação não especifica. É uma questão a decidir com seu DPO, e não com seu fornecedor técnico.
Um detalhe muda o jogo do lado da minimização: a claim email pode passar por divulgação seletiva. Configurada assim, ela transmite um hash em vez do endereço em texto claro para o validador, uma configuração a ser verificada antes de qualquer implantação em produção.
O artigo 7.1 do RGPD exige que o responsável pelo tratamento seja capaz de demonstrar o consentimento da pessoa. O clique de confirmação do double opt-in cumpre esse papel hoje. O token EVP não o substitui: ele atesta uma posse técnica da caixa no momento da inscrição, sem dizer nada sobre a concordância em receber mensagens depois. Em compensação, ele resolve outro problema, que o double opt-in cobre apenas parcialmente, o da objeção “não fui eu quem digitou esse endereço”. O double opt-in prova o consentimento, o token prova a posse da caixa no momento da inscrição: um formulário que combina os dois fecha as duas brechas ao mesmo tempo.
Sobre a privacidade do lado do emissor, o Google é explícito: “O emissor vê apenas um pedido de verificação da existência do usuário, ele não vê qual site iniciou o pedido.” A arquitetura do token torna essa afirmação plausível: é o navegador que constrói o token de vinculação de chave contendo a origem do site e o nonce, assinado com a chave efêmera, depois de receber o token do emissor. Assim, o emissor nunca precisa saber qual é o site destinatário para assinar sua parte do token.
Duas perguntas permanecem sem resposta na documentação atual. O papel jurídico exato do emissor na cadeia não é especificado: ele age como responsável pelo tratamento ou como operador? As transferências para fora da União Europeia também não são documentadas: o emissor é o provedor que já hospeda a caixa de e-mail da pessoa. Por outro lado, nada é dito sobre o tratamento do próprio token nem sobre sua localização.
Como calcular sua cobertura real do protocolo
O Chrome representa 65,23% das sessões de navegador no mundo em maio de 2026, número que sobe para 76,39% apenas no desktop (StatCounter, maio de 2026). Essa fatia global ignora sua cobertura real de EVP, que depende exclusivamente dos seus próprios dados de tráfego e de inscrição. Do lado do e-mail, o Gmail é creditado com cerca de 1,8 bilhão de usuários ativos no mundo, uma estimativa da Statista de novembro de 2024 que o setor continua repetindo na falta de uma publicação regular do Google. Esse volume define um teto teórico, nunca sua fatia real: uma base alimentada por endereços profissionais e uma base alimentada por inscrições do público em geral não geram, de forma alguma, o mesmo percentual.
3 números bastam. A fatia de tráfego do Chrome no seu formulário de inscrição, disponível no Google Analytics ou no Matomo. A fatia de endereços Gmail entre suas inscrições recentes, extraindo o domínio da sua base ESP. E a fatia dessas inscrições em que o autocompletar realmente preencheu o campo, em vez de uma digitação manual, um número que nenhuma API retorna nativamente e que é preciso instrumentar por conta própria, por exemplo comparando os eventos input e change disparados no campo de e-mail.
Multiplicar os dois primeiros números dá um teto alto. O terceiro, quase sempre ignorado, faz esse teto cair.
A montagem em 3 camadas, do token ao envio
O reflexo imediato, depois de entender o mecanismo: se o Chrome já valida o endereço na inscrição, por que continuar pagando por uma verificação antes do envio? A resposta está no escopo do token, que termina exatamente onde a grade indica.
O token permite pular a etapa do clique no link de confirmação, para inscrições Gmail feitas pelo Chrome. O double opt-in mantém, assim, seu papel próprio, descrito acima: a prova de um consentimento ativo, registrado com data e hora, para poder demonstrá-lo como exige o artigo 7.1 do RGPD. Um token EVP não substitui nem a caixa marcada nem o registro de data e hora conservados na base no momento do consentimento.
Desde 2024, o Google fixa um limite de complaint rate de 0,3% para envios em massa, sob risco de as mensagens serem marcadas como spam ou rejeitadas pelo Gmail, um número já visível nos painéis do Google Postmaster Tools por domínio remetente. Um endereço descartável ou uma caixa fechada que mesmo assim recebe a campanha empurra essa taxa para cima, inclusive em plena fase de IP warmup, independentemente do que o token mostrava na inscrição. A deliverability se decide no momento do envio, quando a coleta já ficou muito para trás. Não é o primeiro protocolo técnico que redesenha um elo da cadeia sem eliminar os outros: o DKIM2 seguiu a mesma lógica do lado da autenticação das mensagens.
A verificação que checa a sintaxe, o domínio MX e, às vezes, o histórico de deliverability antes do envio, a que o CaptainVerify faz, se encaixa logicamente entre a coleta e a campanha. A única forma de saber se sua base precisa desse filtro é rodar uma amostra antes do próximo envio.
O que é preciso manter na base, no mínimo: o registro de opt-in do RGPD, o status da última verificação de list hygiene e a data da última campanha enviada sem bounce. Já o token EVP não deve ser armazenado além da sessão de inscrição.
Hoje, o Gmail continua sendo o único emissor voltado ao público em geral. Já o protocolo é conduzido pelos navegadores Chromium: o Chrome desde sua versão 150, o Edge por meio do próprio origin trial do lado da Microsoft. Do lado da padronização, um Internet-Draft assinado por Dick Hardt e Sam Goto está depositado no IETF desde 17 de junho de 2026, em uma revisão datada de 4 de julho, mas em submissão individual, sem grupo de trabalho nem validação até o momento. A Validity estima em sua análise de julho de 2026 que o double opt-in faz perder de 20 a 35% dos inscritos no momento da confirmação, uma fricção que o EVP poderia efetivamente reduzir do lado do Gmail. Se a Outlook ou o Yahoo um dia implementarem seu próprio emissor, a primeira coluna da grade vai se ampliar; sem eles, ela permanece restrita ao Gmail.
Perguntas frequentes sobre o Email Verification Protocol
O protocolo EVP funciona em dispositivos móveis ou em um aplicativo?
A documentação não esclarece esse ponto explicitamente. O protocolo pressupõe o autocompletar do navegador, o que exclui, na prática, os contextos em que ele não está disponível, principalmente alguns navegadores in-app.
Quais navegadores suportam o EVP em 2026?
O Chrome, desde a versão 150, por meio do origin trial aberto em 8 de julho de 2026. O Edge segue com seu próprio origin trial, listado na seção Implementation Status do draft do IETF: mesmo mecanismo Chromium, com um token a ser registrado do lado da Microsoft, distinto do token do Chrome. Do lado do Safari, nenhum anúncio até o momento.
O protocolo funciona com Outlook ou Yahoo?
Ainda não. O Gmail é o único provedor de e-mail que emite tokens no lançamento. A API destinada aos demais provedores de e-mail continua em desenvolvimento no Google.
Vale a pena ativar o origin trial desde já?
Só se o Chrome e o Gmail representarem uma parcela mensurável das suas inscrições. O trial impõe limites de tráfego e um fallback obrigatório para o e-mail de confirmação tradicional em caso de falha.
