Por que a verificação de email importa mais do que pensas

A verificação de email serve três objetivos principais. Primeiro confirma que o utilizador controla realmente o endereço fornecido — erros de digitação como [email protected] são surpreendentemente frequentes. Segundo reduz a criação massiva de contas automatizadas por bots que usam endereços falsos ou descartáveis. Terceiro — e este ponto é o mais subestimado — um endereço de email verificado é um pré-requisito de segurança para a redefinição de senha. Sem verificação, um atacante pode registar o endereço de outra pessoa e desencadear um email de redefinição. O OWASP Authentication Cheat Sheet cobre estes riscos em detalhe.

O fluxo de verificação completo passo a passo

O protocolo de transporte de email está definido no RFC 5321 — mas as decisões a nível de aplicação são completamente do desenvolvedor. Cada passo importa:

1. O utilizador submete o formulário de registo. Validar o formato do email no servidor — não apenas no cliente.
2. Gerar um token criptograficamente aleatório. Não um UUID, não um ID sequencial, não um timestamp — verdadeira aleatoriedade criptográfica com pelo menos 32 bytes de entropia.
3. Armazenar o hash do token na base de dados. Guardar o hash SHA-256 do token, não o token bruto — juntamente com o ID do utilizador, timestamp de criação, tempo de expiração e uma flag "usado".
4. Enviar o email de verificação. O link contém o token bruto como parâmetro de consulta. Usar sempre HTTPS.
5. O utilizador clica no link. O servidor recebe o token bruto na string de consulta.
6. Validar o token. Hashear o token recebido, encontrar a correspondência na base de dados, verificar expiração e estado "usado".
7. Em caso de sucesso: marcar o email como verificado, marcar o token como usado, fazer login do utilizador.
8. Em caso de falha: mostrar uma mensagem de erro específica e acionável com um link para solicitar um novo email.

Geração segura de tokens

O erro mais comum é usar UUID v4 como token de verificação. UUIDs são bons para identificadores de base de dados, mas não são concebidos como tokens de segurança. A abordagem correta: usar o gerador de números aleatórios criptográficos do teu runtime. Em Node.js: crypto.randomBytes(32).toString('hex'). Em Python: secrets.token_urlsafe(32). Em .NET: RandomNumberGenerator.GetBytes(32). O OWASP Authentication Cheat Sheet recomenda pelo menos 32 bytes (256 bits) de entropia.

Testar o fluxo de verificação corretamente

Cada alteração ao fluxo de verificação deve ser testada com um email real para uma caixa de entrada real. Abrir um endereço de email temporário, copiá-lo para o formulário de registo, criar uma conta de teste e observar o email de verificação chegar em tempo real. Isso prova definitivamente que o email é realmente entregue — não apenas aceite pela API do fornecedor.

Autenticação de email: SPF, DKIM e DMARC

Sem autenticação de email correta, os emails de verificação vão para spam. O SPF autoriza servidores de envio através de um registo DNS TXT. O DKIM adiciona uma assinatura criptográfica. O DMARC define a política quando o SPF ou DKIM falham. Usar MXToolbox para verificar as três configurações. Consultar a documentação sobre autenticação de email no teu fornecedor de envio.

Erros comuns a evitar

• Não invalidar o token após uso. Sempre definir a flag "usado" e verificá-la em cada validação.
• Enviar emails de boas-vindas antes da verificação. Ativar sequências de onboarding apenas após verificação confirmada.
• Não limitar pedidos de reenvio. Limitar reenvios por endereço a por exemplo três por hora.
• Enviar links de verificação por HTTP. Usar sempre HTTPS — sem exceção.
• Não registar eventos de verificação. Quando o token foi criado, enviado e clicado — essencial para diagnóstico.
• Usar o mesmo token para múltiplos propósitos. Tokens separados para verificação, redefinição de senha e alteração de email.