Reduza cadastros falsos com validação de e‑mail e fricção inteligente

O que são cadastros falsos e por que eles passam despercebidos

Cadastros falsos são contas criadas sem intenção real de se tornarem usuários legítimos. Às vezes são bots que preenchem seu formulário em escala. Outras vezes são pessoas usando scripts, fazendas de cliques ou rotinas simples de copiar‑colar. Frequentemente usam endereços descartáveis para nunca lidar com verificação, onboarding ou follow‑up.

Eles passam porque sistemas de cadastro são feitos para ser rápidos e acolhedores. Atacantes aproveitam as mesmas coisas que usuários bons gostam: formulários curtos, acesso instantâneo e trials generosos. Se você só checa que um e‑mail “parece válido”, um bot ainda pode submeter um endereço que passa na formatação, mas nunca receberá suas mensagens, ou um de um provedor descartável criado só para o cadastro.

A validação de e‑mail ajuda, mas só o e‑mail não basta. Um atacante determinado pode rotacionar endereços, usar caixas reais ou distribuir tentativas por muitos IPs e dispositivos. O objetivo é fricção direcionada: adicionar checagens extras apenas quando o risco é alto, em vez de fazê-las para todo usuário legítimo.

O impacto costuma ser maior do que parece à primeira vista:

• Gastos desperdiçados (anúncios pagos, trials gratuitos, programas de incentivo)
• Métricas ruins (cadastros inflados, taxas de conversão quebradas, cohorts ruidosos)
• Carga no suporte (contas misteriosas, redefinições de senha, reclamações de spam)
• Danos à entregabilidade (bounces, armadilhas de spam, reputação do remetente baixa)

Uma abordagem em camadas funciona melhor: validação de e‑mail forte (pegar domínios descartáveis e caixas inválidas), limites de taxa leves, sinais de dispositivo e comportamento, e verificação step‑up só quando algo parecer fora do normal.

Como atacantes exploram seu fluxo de cadastro

Atacantes miram o cadastro porque é o ponto mais barato para ganhar acesso. Uma conta falsa bem‑sucedida pode destravar trials gratuitos, códigos promocionais, recompensas de indicação ou acesso a recursos que eles podem revender. Se conseguem criar centenas de contas rapidamente, drenam orçamentos e poluem sua base de usuários antes que alguém perceba.

A maioria das campanhas tem um objetivo claro. Normalmente você verá um destes:

• Abuso de promoções e trials (muitos “novos” usuários que nunca convertem)
• Agricultura de contas (criar contas envelhecidas para usar depois)
• Spam e scraping (contas feitas apenas para enviar mensagens ou extrair dados)
• Credential stuffing (testar logins roubados e então registrar quando bloqueados)

Os padrões raramente são sutis. Cadastros costumam chegar em rajadas, com nomes similares (mesmo estilo, números aleatórios, prefixos repetidos) e tráfego de proxy ou hospedado que muda IPs rápido. Você também pode notar domínios de e‑mail repetidos, ou os mesmos poucos domínios usados em muitas contas num curto espaço de tempo.

Caixas descartáveis ajudam a mover rápido e dificultam rastreamento. Mesmo quando o endereço é “válido o suficiente” para passar uma checagem básica, muitas vezes sinaliza baixa intenção. Endereços inválidos são outro truque: ainda conseguem gerar carga no sistema e provocar bounces nas mensagens de boas‑vindas que prejudicam a entregabilidade.

Então trate a validação de e‑mail como seu primeiro filtro, não o único. Ele bloqueia o lixo óbvio na porta, enquanto controles adicionais pegam o restante.

Exemplo: um bot se cadastra para 200 trials gratuitos usando um novo proxy a cada vez. A validação de e‑mail pode barrar muitas tentativas (domínios descartáveis, MX inválido), e as tentativas restantes se destacam quando você adiciona limites de taxa e checagens step‑up para tráfego de maior risco.

Um modelo simples de defesa em camadas

Para cortar fraude sem irritar usuários reais, empilhe algumas checagens leves que funcionam em conjunto. Cada camada pega um tipo diferente de cadastro ruim, assim você não depende de um único sinal que atacantes podem aprender e contornar.

Comece pela validação de e‑mail porque é rápida e de baixa fricção. Boa validação checa mais que sintaxe. Confirma que o domínio existe, consulta registros MX, marca provedores descartáveis e adiciona sinais de risco para padrões ligados a armadilhas de spam. Trate o resultado como input para um score de risco, não apenas como passar ou falhar.

Depois disso, adicione fricção só quando ela for merecida:

• Limites de taxa para desacelerar rajadas, limitar tentativas e adicionar cooldowns após falhas repetidas
• Sinais de dispositivo e rede para identificar setups repetidos (mesmo dispositivo, faixa de IP, ASN, user agent)
• Checagens step‑up como OTP por e‑mail, SMS, CAPTCHA ou uma fila de revisão curta para tentativas de alto risco
• Registro e métricas para que você possa ajustar sem chutar no escuro

Um cadastro normal com domínio comercial conhecido e comportamento estável deve passar só com validação. Um cadastro que usa domínio descartável, tenta cinco vezes em um minuto e corresponde a um dispositivo visto em abuso passado deve ser desacelerado e solicitado a provar propriedade.

A última camada é a que mais importa: medição. Se os desafios sobem mas a fraude confirmada é baixa, suas regras estão rígidas demais. Se a fraude ainda passa, aperte os limites e aumente gatilhos de step‑up para as combinações mais arriscadas.

Regras de validação de e‑mail que pegam os ganhos fáceis

A maioria dos cadastros falsos começa com e‑mails de baixo esforço: erros de digitação, domínios inventados ou caixas descartáveis. Capturar isso cedo reduz muito ruído sem adicionar obstáculos para usuários legítimos.

Um padrão prático é validar duas vezes. Primeiro, checar quando o usuário sai do campo de e‑mail para que ele receba feedback instantâneo. Depois, validar novamente no envio como portão final, porque atacantes frequentemente contornam checagens do navegador.

Concentre‑se em regras claras e difíceis de contestar:

• Rejeitar sintaxe inválida (falta de @, caracteres ilegais) com uma mensagem simples como “Esse endereço de e‑mail parece inválido.”
• Rejeitar domínios que não existem (NXDOMAIN) e domínios sem configuração de e‑mail (sem registros MX)
• Normalizar erros comuns (remover espaços, colocar domínio em minúsculas) antes de avaliar a entrada

Provedores descartáveis são mais complicados. Um bloqueio total pode impedir usuários reais que prezam pela privacidade, mas deixá‑los passar convida abuso. Um caminho do meio é tratá‑los como mais arriscados e decidir a política pelo contexto (trial gratuito, bônus de indicação, contas de alto valor).

Hard fail vs soft fail

Separe resultados para manter o fluxo flexível:

• Hard fail: sintaxe inválida, domínio inexistente, sem MX. Bloquear cadastro.
• Soft fail: e‑mail descartável, padrões conhecidos de armadilha de spam, domínios de risco vistos recentemente. Permitir, mas marcar para fricção adicional mais tarde.

Não revalide para sempre

Chamadas de validação custam tempo. Armazene o resultado e o timestamp com a tentativa de cadastro, e reutilize durante tentativas subsequentes por uma janela curta (por exemplo, 10 a 30 minutos). Guarde também a resposta bruta para que você possa explicar decisões depois e ajustar regras com dados reais.

Limites de taxa e throttles que realmente ajudam

Limites de taxa funcionam melhor quando são específicos e previsíveis. O objetivo é desacelerar automação sem fazer pessoas normais se sentirem punidas.

Uma boa linha de base é limites por IP em duas velocidades: rajadas curtas e pressão contínua. Por exemplo, permita um pequeno número de tentativas de cadastro por minuto, mais um teto maior por hora. O limite por minuto para de scripts que bombardeiam o formulário; o por hora pega ataques em “gotejamento” que tentam ficar abaixo do radar.

Para evitar bloquear redes compartilhadas, adicione limites por identificador de dispositivo ou fingerprint de sessão também. Uma rede Wi‑Fi de escritório é menos provável de ser bloqueada porque uma única máquina a está abusando.

Atrasos progressivos (cooldowns) costumam ser melhores que bloqueios rígidos. Após falhas repetidas ou cadastros sucessivos da mesma fonte, adicione pequenas esperas: 2 segundos, depois 5, depois 30. Usuários reais quase não percebem. Bots odeiam.

Também fique atento a padrões óbvios: dezenas de e‑mails diferentes submetidos por uma fonte em segundos, ou muitas tentativas que só mudam a parte de alias (+) do endereço.

Whitelist pode ajudar, mas mantenha estreita. Se precisar permitir uma rede corporativa conhecida, libere apenas o que puder verificar e monitorar, e mantenha limites por dispositivo para que uma máquina comprometida não inunde o fluxo.

Sinais de dispositivo e comportamento para identificar abusadores repetidos

Checagens de e‑mail pegam muito, mas abusadores repetidos frequentemente reaproveitam o mesmo setup com pequenas alterações. Sinais de dispositivo e comportamento ajudam a conectar tentativas e aplicar a fricção certa só quando importa.

Comece com sinais de dispositivo leves e estáveis. Um cookie simples ou token em localStorage pode dizer se o mesmo navegador voltou após cadastros falhos. Observe instabilidade do user agent também. Se a string de navegador e SO muda a cada tentativa, é sinal comum de automação. Descompassos de fuso horário também podem ser reveladores, por exemplo um navegador configurado para uma região enquanto a geolocalização do IP sugere outra.

Sinais de rede adicionam outra camada. Uma onda repentina de cadastros de redes com perfil de data center, alta probabilidade de proxy ou VPN, ou saltos geográficos rápidos entre tentativas são motivos para tratar a sessão como de maior risco. Você não precisa de precisão perfeita — precisa de sinal suficiente para separar usuários normais de abuso repetido óbvio.

Comportamento é onde bots muitas vezes escapam. Procure por colagem direta do e‑mail, preenchimento irrealmente rápido do formulário e hesitação zero entre campos. Uma pessoa real pode colar um e‑mail, mas raramente preenche todos os campos em alguns segundos toda vez.

Uma forma simples de operacionalizar é um modelo de buckets de risco:

• Baixo risco: permitir cadastro normalmente
• Risco médio: adicionar pequeno atraso, CAPTCHA ou confirmação extra
• Alto risco: exigir verificação step‑up ou bloquear a tentativa

Exemplo: se um e‑mail passa na validação mas a tentativa vem de um provável proxy, o user agent muda a cada tentativa e o formulário é preenchido em 3 segundos, coloque em alto risco.

Mantenha a privacidade em mente. Use o mínimo de sinais necessário, documente por que os coleta e evite coletar dados sensíveis que não usa de verdade.

Verificação step‑up para cadastros de alto risco

Step‑up significa adicionar uma checagem extra só quando um cadastro parece suspeito. Bem implementado, para o abuso sem transformar o cadastro em um percurso de obstáculos.

Comece definindo gatilhos claros. Um único sinal fraco não deve ser suficiente. Procure combinações que apontem para abuso, como resultado de e‑mail descartável mais rajada de tentativas da mesma faixa de IP, ou rede de risco (datacenter ou VPN) com fingerprints de dispositivo repetidos.

Gatilhos práticos que frequentemente funcionam:

• Provedor descartável ou bloqueado + mais de 3 tentativas em 2 minutos
• Mesmo dispositivo criando muitas contas com e‑mails diferentes
• ASN de alto risco mais falhas repetidas em OTP ou checagens de senha
• Múltiplos cadastros compartilhando campos “únicos” (nome, empresa, código de indicação)

Quando um gatilho dispara, escolha o step‑up mais leve que interrompa o ataque: OTP por e‑mail, CAPTCHA, verificação por telefone ou revisão manual em casos extremos.

Mantenha a experiência direcionada e reversível. Se um usuário legítimo falhar numa checagem (digitou errado o OTP, atraso na entrega), ofereça alternativas como “reenviar código”, “usar outro e‑mail” ou “contatar suporte para verificar”. Não bloqueie silenciosamente sem explicação.

Previna abuso em loop também. Limite envios de OTP por endereço e por dispositivo, e tabeleie tentativas. Por exemplo, permita 3 envios de OTP por hora e 5 tentativas no total antes de um cooldown.

Passo a passo: como combinar validação e fricção

Comece com checagens de menor fricção e só adicione etapas mais pesadas conforme o risco aumenta.

1) Construa o fluxo do menor para o maior atrito

Uma ordem prática que funciona para a maioria dos produtos:

• Valide o e‑mail na borda (sintaxe, domínio, MX, provedores descartáveis).
• Aplique limites básicos de taxa (por IP, por dispositivo e, às vezes, por domínio).
• Adicione sinais de dispositivo e comportamento (fingerprints repetidos, velocidade impossível, muitas tentativas).
• Faça o score da tentativa (baixo, médio, alto risco) e decida o próximo passo.
• Dispare step‑up apenas para tentativas de alto risco (OTP por e‑mail, CAPTCHA ou revisão).

Mantenha o caminho padrão simples. A maioria dos usuários reais deve sentir apenas a primeira etapa.

2) Use mensagens de erro que ajudem usuários, não atacantes

Seja claro, mas não excessivamente específico. “Não foi possível criar sua conta. Tente novamente ou use outro e‑mail.” é mais seguro que “E‑mail descartável detectado” ou “Sem registro MX”, que ensina atacantes o que mudar.

Se precisar de mais detalhe, coloque nos logs, não na interface.

3) Adicione monitoramento antes de ajustar thresholds

Acompanhe alguns números diariamente para ver os trade‑offs:

• Tentativas de cadastro vs cadastros bem‑sucedidos
• Bloqueios por motivo (falha de validação, limite de taxa, falha de step‑up)
• Taxa de sucesso no step‑up (quantos usuários legítimos foram desafiados)
• Mudanças de conversão (taxa de conclusão, tempo para cadastro)

Ajuste um threshold por vez e revise semanalmente. Se desafios aumentarem, suas checagens iniciais podem estar muito frouxas ou seus throttles muito permissivos.

Planeje suporte também. Tenha um caminho simples “ajude‑me a me cadastrar” (sem revelar regras de detecção) para o raro usuário legítimo que for bloqueado.

Erros comuns que aumentam fricção sem deter fraude

A fricção deve ser direcionada. Quando você a adiciona para todos, usuários reais sentem primeiro, enquanto atacantes determinados contornam.

Bloquear todos os domínios de e‑mail gratuitos (como Gmail ou Outlook) é um erro clássico. Muitos usuários legítimos usam esses domínios. Foque na qualidade do endereço (sintaxe, domínio, MX, listas de descartáveis) em vez de punir escolhas normais.

Confiar só em limites por IP é outra armadilha. Atacantes rotacionam IPs ou usam redes de bots, então o limite mal os desacelera. Ao mesmo tempo, redes compartilhadas (Wi‑Fi de escritório, escolas, operadoras móveis) podem fazer muitos usuários reais parecerem um único abusador. Limites de IP ajudam, mas só como um sinal entre vários.

CAPTCHA para todos prejudica conversão e ainda é vencido por fazendas de resolução. Um padrão melhor é exibí‑lo apenas após comportamento suspeito (alta velocidade, falhas repetidas, padrões de dispositivo estranhos).

OTP pode sair pela culatra se você não limitar envios. Fraudadores podem disparar muitos OTPs por SMS ou e‑mail, gerando custos e irritando usuários. Coloque limites rígidos por conta, por dispositivo e por janela de tempo.

Por fim, equipes pulam a trilha de auditoria. Sem logs que expliquem por que alguém foi bloqueado ou desafiado, você não pode ajustar thresholds ou resolver problemas de suporte. Mesmo um registro simples ajuda:

• Qual regra disparou
• Ação tomada (permitir, bloquear, desafiar)
• Contexto básico (hora, IP, user agent, domínio do e‑mail)
• Resultado (cadastro completado, abandonado, tentado novamente)

Checklist rápido antes de enviar mudanças

Antes de lançar defesas no cadastro em produção, decida o que é “bom” para usuários reais.

Uma lista pré‑lançamento que você pode executar em uma sessão:

• Defina ações para cada resultado de e‑mail. Se sua checagem retornar válido, inválido, descartável ou arriscado, escreva o resultado exato para cada um (permitir, bloquear, permitir com step‑up).
• Confirme limites de taxa e cooldowns. Defina limites por IP, por fingerprint de dispositivo e por endereço de e‑mail. Adicione um curto cooldown após falhas repetidas.
• Documente gatilhos de step‑up. Liste as condições que disparam OTP, CAPTCHA ou verificação extra (por exemplo: e‑mail arriscado + alta velocidade de um dispositivo). Teste esses caminhos em staging.
• Defina tetos de retries e monitore abuso. Configure limites de tentativas para OTP e CAPTCHA, e registre eventos como “OTP solicitado” e “OTP falhou.”
• Configure revisão semanal de métricas. Acompanhe taxa de bloqueio, falsos positivos e conversão geral do cadastro.

Um teste rápido de realidade: crie três cadastros de teste (um e‑mail de trabalho normal, um descartável e um domínio com erro de digitação) e confirme que o fluxo se comporta exatamente como suas regras dizem.

Exemplo: parar um pico de trials falsos sem bloquear usuários reais

Um SaaS lança um trial numa segunda‑feira. Dez minutos depois, analytics mostra 500 novos cadastros. O suporte também nota uma onda de e‑mails de boas‑vindas retornando. Nada quebrou. Você está sendo atingido por cadastros automatizados.

A validação de e‑mail sozinha vai pegar endereços obviamente ruins (erros, domínios mortos, falta de MX). Mas muito do pico pode ainda passar usando domínios com aparência válida e caixas descartáveis que passam checagens básicas, ou caixas recém‑criadas que recebem e‑mails por um curto período.

Dois controles leves reduzem o dano sem incomodar a maioria dos usuários reais. Primeiro, limites de taxa no endpoint de cadastro para que uma fonte não crie contas em velocidade de máquina. Segundo, sinais de dispositivo e rede para detectar clusterização: muitas tentativas da mesma faixa de IP, mesmo fingerprint de dispositivo ou mesmo perfil de navegador.

Com esses sinais, você pode fazer step‑up só para o bucket suspeito:

• Tráfego normal: validar o e‑mail, criar a conta, enviar o e‑mail de onboarding.
• Tráfego suspeito: exigir OTP por e‑mail, atrasar a criação da conta até o endereço ser confirmado ou apertar limites.
• Tráfego claramente abusivo: bloqueio rígido por um período e registro do padrão para ajuste.

O que você mede depois da mudança: o pico gera muito menos contas ativadas, as taxas de bounce caem, a entregabilidade melhora e a conversão do trial se mantém estável porque usuários reais mantêm o fluxo simples enquanto bots são desacelerados ou forçados a provar que são reais.

Próximos passos: lançar com segurança e continuar ajustando

Comece com mudanças que você pode enviar em uma semana e meça claramente. Escolha um pequeno conjunto de controles e adicione bom logging desde o primeiro dia.

Na primeira semana, foque em três básicos:

• Validação de e‑mail no cadastro (sintaxe, domínio, MX, checagens de descartáveis)
• Limites básicos por IP e por identificador de conta (e‑mail, telefone, código de convite)
• Registro para cada decisão (permitido, desafiado, bloqueado) com o motivo

Se quiser uma camada dedicada de qualidade de e‑mail, Verimail (verimail.co) é uma API de validação de e‑mail de nível enterprise que checa sintaxe compatível com RFC, verifica domínios, consulta registros MX e compara com milhares de provedores descartáveis em uma única chamada. É uma forma de baixa fricção para bloquear endereços inválidos e descartáveis antes que cheguem ao seu banco de dados, e inclui um nível gratuito de 100 validações por mês sem exigir cartão de crédito.

Defina thresholds e escalonamento

Escreva regras simples que digam ao sistema o que fazer a seguir:

• Step‑up: velocidade incomum, falhas repetidas, tipo de e‑mail arriscado ou novo dispositivo mais outros sinais suspeitos
• Bloquear: padrões claros de automação, uso repetido de descartáveis ou redes conhecidas ruins
• Revisar: casos limite onde você não quer arriscar bloquear (por exemplo, domínios corporativos com configuração de e‑mail incomum)

Lance gradualmente e observe os dois lados

Libere para uma pequena fatia do tráfego primeiro (como 5% a 10%), depois expanda. Compare métricas de conversão e fraude lado a lado: taxa de conclusão do cadastro, tempo para completar, taxa de falha na validação, bounce rate e relatórios de abuso.

Agende revisões recorrentes (semanal no começo, depois mensal). Atacantes se ajustam rápido, então trate thresholds como configurações vivas. Procure por novos domínios descartáveis, faixas de IP em mudança ou padrões de dispositivo e ajuste gatilhos de step‑up antes de aumentar bloqueios.