Verificação de e-mail não funciona: corrigir links, tokens e lógica de reenvio

Como se manifesta quando a verificação quebra

Quando a verificação de e-mail não funciona no seu cadastro, raramente falha de forma limpa e óbvia. Os usuários simplesmente ficam presos. Eles se cadastraram, fizeram o que você pediu, e sua app ainda diz que não estão verificados.

A experiência mais comum é o silêncio: nenhum e-mail chega. As pessoas checam spam, esperam alguns minutos, clicam em reenviar e desistem. Outras recebem o e-mail, mas o botão leva a uma página em branco, um erro assustador ou um redirecionamento de volta para a tela de login sem explicação.

A pior versão é o loop:

“Por favor verifique seu e-mail” -> “Reenviar” -> “E-mail enviado” -> clicar -> ainda “Por favor verifique seu e-mail.”

Aqui estão os padrões que os usuários geralmente reportam (frequentemente com screenshots e frustração):

• Nenhum e-mail de verificação chega (ou chega horas depois)
• O link abre, mas mostra “Token inválido” ou “Link de verificação expirado”
• O link funciona uma vez e nunca mais, mesmo para um novo cadastro
• Após verificar, a app ainda os trata como não verificados
• O reenvio parece funcionar, mas só o e-mail mais novo ou só o mais antigo funciona (não ambos)

Isso não é apenas alguns cadastros bloqueados. Cada fluxo de verificação quebrado gera tickets de suporte, reembolsos e avaliações ruins. Também cria risco: se o reenvio pode ser batido, seu sistema pode enviar milhares de e-mails rapidamente, prejudicando entregabilidade e parecendo spam.

Fluxos de onboarding gerados por IA costumam quebrar porque as peças são coladas com suposições de caminho feliz. Causas comuns incluem tokens armazenados em memória em vez de no banco de dados, links construídos a partir do domínio errado, estado de verificação não salvo de forma confiável ou um botão de reenvio que cria um token novo sem invalidar o antigo.

O objetivo é simples: a verificação deve ser confiável para usuários reais (incluindo pessoas que clicam no e-mail em outro dispositivo), clara quando algo dá errado e restrita o suficiente para que não possa ser abusada. Se você herdou um protótipo gerado por IA de ferramentas como Lovable, Bolt, v0, Cursor ou Replit, esses problemas são comuns e geralmente consertáveis com uma auditoria focada e algumas mudanças cuidadosas.

Sintomas comuns para reconhecer rápido

Alguns bugs de verificação são barulhentos (um erro claro). Outros são silenciosos e só aparecem como “pessoas não conseguem se cadastrar.” A maneira mais rápida de debugar é nomear o sintoma exato, porque cada um aponta para uma camada diferente.

1) O e-mail nunca chega

Se usuários dizem que o e-mail está faltando, não assuma que sua app não o enviou. Frequentemente ela enviou, mas o provedor bloqueou, caiu em spam ou foi para o endereço errado.

Indícios típicos: apenas alguns domínios falham (por exemplo, caixas corporativas), mensagens aparecem em spam ou nada aparece nos logs do provedor de e-mail. Também cheque o básico: erros de digitação no e-mail do usuário, domínio do remetente errado ou variáveis de ambiente que ainda apontam para um serviço de e-mail de teste em produção.

2) O link abre, mas mostra “inválido” ou “expirado”

Esta é a queixa clássica de “verificação de e-mail não funciona”. Normalmente significa que o token na URL não consegue ser emparelhado com o que seu backend espera, ou sua lógica de expiração é muito severa.

Padrões comuns:

• O token está codificado na URL de forma incorreta.
• Seu backend faz hash dos tokens mas compara como texto simples.
• Você roda secrets entre deploys, então tokens emitidos antes nunca mais validam.
• Derivações de relógio ou lógica de timezone marcam tokens como expirados imediatamente.

3) O link diz verificado, mas o usuário ainda não está logado

Usuários clicam no link, veem uma mensagem de sucesso, depois são redirecionados para a tela de login como se nada tivesse acontecido.

Isso geralmente acontece quando verificação e login são tratados como passos separados, mas a UI insinua que são o mesmo. Outras causas comuns: cookies de sessão não sendo definidos (domínio errado, flags secure ausentes, cookies de terceiros bloqueados) ou o endpoint de verificação atualiza o banco de dados, mas o frontend continua usando estado de usuário desatualizado.

4) Reenvio funciona, mas links antigos ainda funcionam (ou nada funciona)

Fluxos de reenvio costumam se comportar de forma estranha em onboarding gerado por IA. Você pode ver reenvios que continuam gerando novos e-mails enquanto todo link permanece válido para sempre, ou o oposto, onde cada novo e-mail falha instantaneamente.

Um fluxo de reenvio confiável precisa de uma regra clara: um token novo invalida o antigo, ou qualquer token ativo ainda funciona?

• Se você não revoga tokens antigos, atacantes podem usar qualquer link vazado.
• Se revogar agressivamente sem avisar o usuário, ele vai clicar num e-mail anterior e ver “expirado” mesmo tendo solicitado reenvio.

5) Contas múltiplas, duplicatas e condições de corrida

Cliques repetidos e tentativas repetidas de cadastro podem criar casos de borda: duas linhas de usuário para o mesmo e-mail, uma flag de verificado que oscila, ou erros de “já verificado” que ainda não liberam o login.

Procure por corridas como: um usuário se cadastra duas vezes antes da primeira verificação completar, duas requisições de verificação rodam ao mesmo tempo, ou um reenvio cria um segundo registro pendente. Isso aparece mais com usuários impacientes em mobile que tocam o link várias vezes.

Se esses sintomas aparecem juntos, muitas vezes significa que o fluxo foi montado a partir de trechos sem uma única fonte de verdade para tokens, expiração e estado de usuário.

Onde as falhas geralmente vivem (entrega, app, banco de dados)

Quando a verificação de e-mail não funciona, equipes costumam mexer no lugar errado primeiro. Trate como uma corrida de revezamento: o provedor de e-mail tem que entregar a mensagem, a app tem que aceitar o clique e o banco de dados tem que registrar o novo estado.

Divida o problema em três zonas

A maioria das quebras se encaixa em uma destas zonas:

• Entrega: o e-mail não chega, cai em spam ou o cliente de e-mail altera o link (wrap, truncamento ou reescrita “safe-link”)
• App: o endpoint de verificação rejeita a requisição, o frontend mostra a mensagem errada ou o endpoint verifica mas a UI continua presa
• Banco de dados: o registro do token está faltando ou foi sobrescrito, timestamps estão errados ou a flag de verificado do usuário nunca atualiza

Comece com uma pergunta simples: o clique chegou ao seu backend? Se você tem uma entrada de log do servidor para a requisição de verificação, a entrega provavelmente está ok e o problema está na app ou no banco.

A mudança de estado deve acontecer no backend

Um bug comum em onboarding gerado por IA: o frontend finge que a verificação teve sucesso (mostra a tela de sucesso) mas nenhuma alteração de estado no backend ocorre. Verificação deve ser uma ação server-side que atualiza registros reais: status do usuário, token marcado como usado, e o horário em que aconteceu.

Seu modelo de banco de dados deve responder claramente:

• A qual usuário esse token pertence?
• Quando foi criado e quando expira?
• Já foi usado?
• Qual é o status atual de verificação do usuário?

Se qualquer um desses estiver ausente, você verá comportamento instável como “funciona uma vez”, “funciona só no mobile” ou “continua dizendo link expirado”.

Desencontros de ambiente (dev vs prod)

Mesmo quando o código está correto, configurações podem mudar o comportamento entre ambientes. Um backend pode gerar links com o host errado ou usar secrets diferentes para assinar tokens em produção. Outro clássico: produção roda múltiplas instâncias, mas tokens são armazenados em memória, então metade das requisições não consegue validá-los.

Se você herdou um protótipo gerado por IA (Lovable/Bolt/v0/Cursor/Replit), a causa raiz muitas vezes não é um bug só, mas alguns pequenos desencontros entre entrega, app e banco que só aparecem em produção.

Erros de link e token que quebram a verificação

Quando a verificação de e-mail não funciona, o bug frequentemente não está no e-mail em si. Está em como o token do link é criado, armazenado e verificado.

Um link de verificação é tão confiável quanto as regras por trás do seu token. Se essas regras são vagas (ou inexistentes), você terá falhas aleatórias para usuários reais e abuso fácil para atacantes.

Erros de token que quebram silenciosamente o fluxo

Estes são os problemas que mais aparecem em código de onboarding gerado por IA:

• Token não é armazenado no servidor, então a app não consegue validá-lo depois. Alguns protótipos colocam o token em estado do cliente (como localStorage) e comparam com ele mesmo, o que não prova nada.
• Token vaza para logs. Se você registra URLs completas ou bodies de requisição, seu token pode acabar em logs do servidor, analytics, rastreadores de erro ou screenshots de suporte.
• Token é armazenado em texto puro. Se seu banco vazar, atacantes podem verificar contas imediatamente. Padrão mais seguro: armazene um digest hasheado do token, como faria com senhas.
• Expiração está errada. Muito curta significa que atrasos normais causam “link expirado”. Sem expiração significa que links antigos funcionam para sempre.
• Token está ligado à coisa errada. Mismatch comum: token é gerado para um user ID, mas o endpoint busca por e-mail, ou o link aponta para o host de API errado.
• Endpoint não checa propósito e status. Um token deve ser válido apenas para um propósito (verificar e-mail) e apenas quando a conta não está já verificada.
• Vários tokens válidos existem com regras pouco claras. Se você permitir tokens ativos ilimitados, precisa de uma política clara: vence o mais novo, ou qualquer token ativo funciona.

Um exemplo realista pequeno: alguém se cadastra, pede dois reenvios e então clica no primeiro e-mail. Seu sistema aceita apenas o token mais recente, então retorna “token inválido.” O usuário não fez nada errado. Suas regras e mensagens não corresponderam ao que aconteceu.

Um conjunto de regras que funciona na prática: gere um token aleatório, armazene apenas seu hash, defina uma expiração sensata (horas, não minutos), vincule ao usuário e ao propósito, e escolha uma política para múltiplos tokens (frequentemente “o mais novo vence” com tokens antigos revogados).

Lógica de reenvio que funciona e não convida abuso

Quando a verificação quebra, usuários tentam reenviar primeiro. Se o reenvio for fraco, vira um loop interminável para usuários reais e uma ferramenta gratuita para maus atores.

Um bom botão de reenvio faz três coisas toda vez: cria um token novo, torna tokens antigos inúteis e desacelera requisições repetidas. Gerar um token novo sem invalidar o antigo leva a estados confusos como “já usado” ou “token mismatch”, dependendo de qual e-mail o usuário clicar.

Mantenha o comportamento de reenvio previsível:

• Emita um token novo e revogue ou expire tokens não usados anteriores
• Faça rate-limit por conta e por IP (um curto cooldown mais um limite diário)
• Retorne a mesma mensagem independente de o e-mail existir (previne descoberta de contas)
• Armazene hashes de token (não tokens crus) e use um tempo de expiração claro
• Mostre um estado de UI claro como “E-mail enviado. Tente novamente em 30 segundos.”

Evite loop de reenvio usando uma única fonte de verdade para “verificação pendente.” Não baseie isso em flags do frontend ou localStorage. Baseie no estado do servidor (por exemplo, um registro de usuário com status de verificação). A UI deve ler esse estado e oferecer apenas ações que façam sentido: reenviar, trocar e-mail ou contatar suporte.

Lidar com usuários que mudam o e-mail antes de verificar é outro ponto comum de quebra. Trate como um fluxo de verificação novo: atualize o e-mail pendente, revogue todos os tokens anteriores e exija verificação do novo endereço. Caso contrário você corre o risco de verificar o e-mail errado ou deixar múltiplos links válidos flutuando.

Logs importam, mas registre com segurança. Guarde eventos e timestamps (verification_sent, verification_clicked, verification_succeeded, verification_failed) mais metadados grosseiros como user ID e códigos de resposta do provedor. Nunca registre tokens crus, URLs completas de verificação ou conteúdos de e-mail. Se precisar de traces, registre um identificador do token (como os primeiros 6 caracteres do hash) e mantenha isso fora de mensagens visíveis ao cliente.

Passo a passo: torne a verificação confiável de ponta a ponta

Se seu problema de verificação de e-mail não funciona aparece só às vezes, geralmente é porque o fluxo está dividido demais. Torne-o chato: um token, um endpoint, uma mudança de estado clara.

1) Construa um fluxo simples e repetível

Decida como os tokens funcionam antes de tocar na UI.

1. Gere um token que não possa ser adivinhado. Use um valor longo e aleatório (não um código curto, não um id previsível, não um JWT previsível a menos que você saiba exatamente o que está fazendo).
2. Armazene apenas o que precisa. Salve um hash do token (não o token cru), mais user_id, expires_at e used_at (ou um simples status).
3. Envie um link de verificação único que aponte para um único endpoint de backend, por exemplo: GET /verify-email?token=....
4. Verifique uma vez e defina uma fonte única da verdade. Quando o token for válido, marque o usuário como verificado (por exemplo, users.email_verified_at = now()), e marque o token como usado.
5. Trate expiração com um caminho amigável. Se o token estiver expirado, mostre uma mensagem clara e ofereça um modo seguro de pedir um novo e-mail.

2) Torne reenvios e cliques repetidos seguros

Duas regras mantêm isso confiável: invalide tokens antigos e faça cada ação idempotente.

Quando um usuário clica no mesmo link duas vezes (ou o cliente de e-mail faz preload), nada deve quebrar. Se o usuário já está verificado, o endpoint deve retornar “Você está verificado” e parar.

Para reenvios, evite múltiplos tokens ativos por usuário. Ao emitir um token novo, invalide quaisquer tokens não usados anteriores para esse usuário. Isso previne casos de borda onde um e-mail mais antigo chega depois e confunde o usuário.

Um checklist rápido que pega a maioria dos erros de onboarding gerados por IA:

• Um token ativo por usuário, inválido após reenvio
• Um endpoint de verificação que faz a mudança de estado completa (não metade no frontend)
• Atualização atômica: verifique o usuário e consuma o token na mesma operação
• Janela de expiração clara (por exemplo, 15 minutos a 24 horas) e um caminho limpo de “enviar de novo”
• Respostas idempotentes para tokens já verificados e já usados

Exemplo: um fundador testa o cadastro, clica no link e funciona. Mais tarde, um colega usa o mesmo link e recebe “token inválido.” Isso pode ser aceitável, mas só se o endpoint responder com “Já verificado” ao invés de um erro. Frequentemente o estado está correto, mas a mensageria e a idempotência estão faltando, então parece quebrado.

Resistência a abuso e checagens de segurança a adicionar cedo

Equipes frequentemente focam na entregabilidade e na UI. Mas muitos fluxos “quebrados” na verdade estão bloqueados por checagens de segurança ausentes, ou estão funcionando mas fáceis de abusar. Adicione algumas salvaguardas cedo para que a verificação permaneça confiável sob tráfego real.

Controle de resends e tentativas de verificação

Botões de reenvio atraem abuso. Se um bot acionar centenas de e-mails por minuto, seu provedor pode atrasar ou rejeitar mensagens, e usuários reais ficam presos.

Limites que geralmente funcionam sem penalizar usuários reais:

• Limite de reenvio por conta (por exemplo, 1 por minuto com um teto diário)
• Limite de tentativas de verificação por token (pare após algumas tentativas erradas)
• Throttles por IP ou dispositivo para cadastros e reenvios repetidos
• Cooldowns progressivos onde cada reenvio aumenta a espera
• Feedback claro ao usuário (uma contagem regressiva vence um botão clicável infinitamente)

Um detalhe que importa: não crie um token novo a cada clique sem limites. Isso pode inflar seu banco de dados e tornar o suporte mais difícil (“qual e-mail é o correto?”).

Previna replay e caminhos comuns de takeover

Tokens devem ser de uso único e de curta duração. Após uma verificação bem-sucedida, marque o token como usado e rejeite-o para sempre.

Também vigie comportamentos que facilitam takeover. A verificação não deve trocar silenciosamente o e-mail de uma conta só porque alguém clicou em um link. Um padrão mais seguro: solicitar troca -> enviar link para o novo e-mail -> confirmar -> notificar o e-mail antigo.

Tratamento de redirects é outro problema silencioso. Se seu endpoint de verificação aceita um parâmetro de redirect, permita apenas destinos internos conhecidos. Caso contrário, atacantes podem usar seu domínio para redirecionar usuários a páginas de phishing.

Trate tokens como senhas: vazam facilmente. Evite colocar tokens completos em logs, eventos de analytics, relatórios de erro ou screenshots de suporte. Se precisar logar, armazene apenas um prefixo curto.

Um exemplo realista: um protótipo captura a URL de verificação (com token) em uma ferramenta de analytics, e ela aparece em dashboards de terceiros. Qualquer pessoa com acesso pode verificar contas. Isso acontece mais do que equipes esperam porque códigos de template frequentemente registram URLs completas por padrão.

Armadilhas comuns em fluxos de onboarding gerados por IA

Quando a verificação de e-mail não funciona em uma app gerada por IA, as pessoas geralmente culpam o provedor de e-mail primeiro. A entrega pode fazer parte do problema, mas falhas repetidas normalmente vêm do estado confuso da app: o banco diz uma coisa, o servidor checa outra e a UI mostra uma terceira.

Um padrão comum é “muitos tokens, sem regras.” O fluxo gera um token novo a cada reenvio, mas tokens antigos nunca são revogados. Então o usuário clica no primeiro e-mail, o servidor checa o token mais recente e você tem um mismatch mesmo que o link pareça válido. Duas abas ou dois dispositivos também podem criar requisições concorrentes que deixam o estado estranho.

O design do token é outra armadilha. Código gerado por IA às vezes usa tokens previsíveis, ou coloca um user ID (ou e-mail) diretamente no link e chama isso de “verificação.” Isso é mais fácil de adivinhar ou reutilizar, e é mais difícil de invalidar com segurança.

Verdade do servidor vence verdade do cliente

Se a UI define isVerified = true depois que o usuário clica no link (sem atualização server-side), vai parecer certo naquele navegador e falhar em outros. Você precisa de uma fonte única de verdade no servidor, armazenada no banco, e toda ação protegida deve checar isso. Caso contrário, pessoas podem contornar verificação chamando endpoints diretamente.

Tempo é outra falha silenciosa. Usuários reais clicam links tarde, clicam duas vezes ou recebem e-mails fora de ordem. Se você não testar janelas de expiração, desvio de relógio entre serviços e entrega atrasada, vai lançar um fluxo que só funciona em condições de laboratório.

Verificações rápidas que pegam a maioria dos bugs de onboarding:

• Apenas um token válido por usuário por vez, com regras de precedência claras
• Hashes de token são armazenados (não tokens crus) e validação sempre acontece no servidor
• Reenvio é uma mudança de estado: revogar tokens antigos, definir nova expiração e logar o evento
• Verificação é idempotente: um segundo clique diz “já verificado”, não um erro
• Teste de tempo: links expirados, e-mails fora de ordem, cliques duplos e trocas de dispositivo

Exemplo realista: consertando um cadastro quebrado nesta semana

Um fundador lança uma app gerada por IA e os primeiros usuários batem em um muro: cadastro funciona, mas ninguém consegue entrar porque a app insiste em verificação de e-mail. Tickets de suporte dizem a mesma coisa: “Nunca recebi o e-mail.” Alguns recebem, mas ao clicar no botão aparece “token inválido.” O fundador procura por “verificação de e-mail não funciona” e tenta ajustes rápidos, mas o problema volta.

Comece pelas partes chatas. O provedor de e-mail está rejeitando envios porque o endereço from não corresponde ao domínio verificado, então muitas mensagens nem saem. Além disso, a app gera tokens em memória, envia por e-mail, mas nunca os salva no banco. Então quando o usuário clica no link, o servidor não tem nada para comparar.

Uma correção estável fica assim:

• Corrigir configurações do remetente (domínio verificado, from e reply-to)
• Armazenar um token hasheado com expiry e o user id
• Validar no clique: usuário existe, token bate, não está expirado, não foi usado
• Adicionar limite de reenvio (cooldown mais teto diário) por usuário e por IP
• Invalidar tokens antigos quando um novo é emitido

Após a correção, a verificação funciona mesmo quando alguém abre o e-mail horas depois. Se solicitar um novo e-mail, apenas o link mais novo é aceito e links antigos falham com uma mensagem clara. Isso reduz confusão e fecha uma rota comum de abuso onde atacantes disparam reenvios em massa ou reutilizam tokens antigos.

Durante a transição, o suporte precisa de um script simples que não culpe o usuário. Por exemplo: “Corrigimos nossos e-mails de verificação. Por favor solicite um novo e-mail de verificação na tela de login. Se ainda não receber em 5 minutos, verifique spam e informe qual domínio de e-mail você usou (Gmail, Outlook, etc.).”

Checagens rápidas e próximos passos

Se a verificação de e-mail não funciona e está bloqueando cadastros, faça uma passagem rápida que cheque toda a cadeia. A maioria dos relatos de “não funciona” se resume a um desencontro entre o que foi enviado e o que seu servidor espera quando o link é aberto.

Um checklist rápido que você pode rodar em cerca de 15 minutos:

• Entrega: confirme que o e-mail foi realmente enviado, não está preso na fila do provedor e não está indo para spam (ver eventos do provedor e bounces)
• Correção do link: abra o e-mail e compare domínio, path e query params do link com o que suas rotas tratam (atente para codificação de URL)
• Regras do token: confirme formato do token, estratégia de hashing, lifetime e configurações de tempo batem dos dois lados
• Atualizações de estado: garanta que verified é gravado uma vez, no registro de usuário certo, e que o login lê esse mesmo campo
• Logging: adicione um trace ID por requisição, registre códigos de motivo claros (expired, already_used, invalid) e nunca registre tokens completos (registre só um prefixo curto)

Depois rode alguns testes de borda em uma janela anônima para ver como novos usuários veem:

• Token expirado: espere passar o TTL, clique no link e confirme que recebe um resultado claro de expiração e um caminho seguro para reenviar
• Reenvio duas vezes: solicite dois reenvios e confirme que apenas o link mais novo funciona (ou que os antigos são invalidados)
• Clique no link antigo após um reenvio: confirme que você não verifica pelo token errado nem reverte o usuário para não verificado
• Clique no mesmo link duas vezes: confirme que o segundo clique é tratado com segurança e não gera erro
• Crie duas contas, troque links: confirme que links não conseguem verificar outro usuário

Se você herdou um código gerado por IA, fique atento a fluxos auth emaranhados: múltiplos endpoints de verificação, tokens armazenados em lugares diferentes ou lógica de UI que marca usuário como verificado antes do servidor. Esses são difíceis de ver sem ler o fluxo de ponta a ponta.

Se quiser uma segunda opinião, FixMyMess (fixmymess.ai) se especializa em diagnosticar e reparar código gerado por IA, incluindo autenticação e fluxos de verificação quebrados. Uma auditoria focada de código frequentemente revela as pequenas questões que se combinam (config de entrega, persistência de token, regras de reenvio, atualizações de estado) e que só aparecem em produção.