Como evitar emails falsos no seu cadastro (sem barrar usuário real)

O dilema: segurança vs conversão

Toda PO que cuida de signup enfrenta o mesmo problema: sua base cresceu, mas 30% dos emails são inválidos ou descartáveis. A primeira reação é apertar a validação. Problema: usuários legítimos com emails pouco convencionais batem na porta, conversão cai, e você fica explicando pra execução por que perdeu 5% do funnel.

A verdade é que não existe validação perfeita. Email válido sintáxe, mas inexistente domínio, é um problema real. Email de empresa legítima, mas criado ontem sem MX record, passa em tudo. Seu trabalho não é criar uma muralha impenetrável (impossível), mas sim construir camadas inteligentes que filtrem o óbvio sem sacrificar o usuário real.

Vamos falar de estratégia.

Camada 1: regex simples no front (UI gating)

Começa aqui, é gratuito e melhora UX imediatamente.

Um regex decente pega:

• Falta de @
• Domínio vazio ou com caracteres inválidos
• Espaços em branco
• Tipinhos comuns (gmial.com em vez de gmail.com)

const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

if (!emailRegex.test(email)) {
  showError("Email parece inválido. Confira digitação.");
  return false;
}

Propósito: bloqueiar entrada óbvia, evitar requisição desnecessária pro backend. Sem regex, 15-20% do tráfego de validação é lixo.

Armadilha: regex muito restritivo (tipo rejeitar .co.uk ou emails com + para aliases). Teste com base real antes de deploy. Nielsen Norman Group recomenda feedback imediato em campos críticos, e validação progressiva cumpre isso.

Camada 2: validação assíncrona via API

Agora você sabe que a sintaxe tá OK. Precisa checar se o domínio existe e se o email é descartável — e aqui vale entender a diferença entre validação e verificação de email, porque nem toda ferramenta faz todas as camadas.

Uma API de validação de email checa:

• MX records: o domínio tem infraestrutura de email?
• Entrega SMTP: consegue fazer handshake com servidor?
• Descartáveis: é tempmail.com, 10minutemail.io, etc? (Veja o que é um email descartável e como identificar.)
• Vazamentos: o email vazou em data breaches públicas?

Isso custa. Não valida 100% dos users, apenas durante signup. Se performance é crítica, valide async, não-bloqueante: deixe o usuário prosseguir enquanto você verifica backend.

// Front: submit form, mas deixa loading
const response = await fetch('/api/validate-email', { method: 'POST', body: JSON.stringify({ email }) });
const { isValid, reason } = await response.json();

if (!isValid && reason === 'disposable') {
  showWarning("Emails descartáveis não são aceitos.");
  return false;
}

Propósito: filtrar 70% dos falsos positivos sem barrar o real. Um email corporativo com typo passa aqui (tem MX), mas tempmail.com fica de fora.

Armadilha: assumir que API é 100% precisa. Não é. Falsos positivos acontecem: novo domínio sem MX configurado, servidor temporariamente offline, rate limit. Sempre ofereça "meu email está correto, continue mesmo assim".

Camada 3: double opt-in (confirmação por token)

Sua arma nuclear: email de confirmação com link/código.

User preenche email, recebe mensagem "Clique o link pra confirmar", clica, e só aí account ativa. Benefícios:

• Email de verdade: se não conseguir entregar, o user nunca entra
• Engagement inicial: o user se envolveu (clicou link), é más intent
• Validação humana: descartáveis raramente monitoram inbox

Timing: mande em < 5 minutos. User não espera. Expira token em 24h.

Propósito: garantir que email é alcançável. Sinal mais forte de legitimidade. Como bônus, o opt-in documentado também sustenta a base legal de consentimento exigida pela LGPD na validação de emails.

Armadilha: double opt-in aumenta fricção. Alguns usuários perdem email de confirmação, esquecem, saem. Trade-off aceitável? Depende do seu negócio. Se é SaaS enterprise, vale. Se é consumer app, considere opt-in só pra users de risco (descartável flags).

Camada 4: monitoramento + revalidação periódica

Cadastro validado != email permanentemente válido. Domínios morrem, contas são deletadas, inboxes ficam cheias.

Após 30 dias, re-valide:

• Verificação SMTP leve (sem novo send)
• Feedback de bounces em notificações futuras
• Sinal de inatividade: emails que nunca clicaram, nunca abriram

Se email volta inválido 2x consecutivas, marque como suspeito, segmente em list separada.

Propósito: manter lista "respirando", não coleta defuntos.

Armadilha: revalidação constante gera custos. Respeite quotas de API. Faça batch jobs fora de horário pico.

Erros que você NÃO deve cometer

1. Regex que rejeita .co.uk, .io, emails com +: seus usuários têm esses emails. Tá errado.

2. Validação só SMTP sem lista de descartáveis: tempmail.com passa em MX check, é um servidor legítimo. Precisa de feed de lista negra atualizada.

3. Exigir double opt-in para 100% dos usuários: converter é difícil. Reserve pra casos de risco. Para email corporativo com domínio antigo? Permite direto.

4. Confiança cega em API third-party: provedores têm downtime. Sempre tenha fallback: se API demora > 3s, deixa passar (melhor false positive que timeout).

5. Não comunicar o rejeit com clareza: "Email inválido" é vago. Diga "Parece ser email temporário. Use seu email pessoal ou corporativo."

A combinação é a resposta

Nenhuma camada sozinha resolve. Regex pega typo. API pega descartáveis. Double opt-in pega intenção falsa. Monitoramento pega decadência.

Juntas, você filtra:

• Entrada óbvia (regex)
• Descartáveis conhecidas (API + lista negra)
• Falta de intenção (opt-in)
• Degradação pós-cadastro (monitoramento)

Resultado: lista limpa, conversão alta, conformidade melhorada.

Próximos passos

• Implementar regex customizado pra sua base
• Integrar API de validação de email no fluxo de signup
• Estruturar double opt-in com template de confirmação clara
• Montar job de revalidação periódica

Para detalhes técnicos de integração, consulte documentação da API. Para testar seu email, use verificador online.

Sua lista agradece. Seu compliance team também.