Aprenda a identificar cadastros com domínios recém-criados usando sinais de idade do domínio, resultados de validação de e-mail e regras de verificação progressiva que reduzem fraude e bounces.
Porque são baratos e fáceis de substituir. Se um domínio for bloqueado, o atacante pode registrar outro e continuar, por isso você costuma ver rajadas de cadastros vindos de domínios recém-criados durante ondas de abuso.
Não. Muitos usuários legítimos registram um domínio e se cadastram no mesmo dia para uma nova empresa, projeto, evento ou rebranding. Trate a idade do domínio como um indicativo de risco e confirme com sinais de configuração de e-mail e comportamento.
Normalmente significa ou que o domínio foi registrado recentemente, ou que ele apareceu “pela primeira vez” em sinais de atividade há pouco tempo. A idade de registro e a primeira aparição podem diferir, por exemplo se o domínio ficou inativo ou mudou de dono.
Comece com checagens de sintaxe compatíveis com RFC para pegar lixo óbvio, verifique se o domínio existe no DNS, confira registros MX para saber se pode receber e-mail e, por fim, filtre provedores descartáveis e infraestrutura conhecida como maliciosa. Essas checagens respondem rapidamente “é real?” e “pode receber e-mail?”.
A ausência de MX normalmente indica que o domínio ainda não está configurado para receber e-mails, o que torna verificação e onboarding pouco confiáveis. Para domínios muito novos, é um motivo prático para desacelerar o cadastro ou pedir outro endereço em vez de liberar acesso imediato a recursos valiosos.
Agrupe a idade em faixas amplas como 0–7 dias, 8–30 dias, 31–180 dias e 180+ dias. Combine a faixa com o resultado da validação e escolha uma ação consistente, por exemplo permitir, exigir verificação, limitar taxa ou bloquear.
Um hard fail bloqueia o cadastro imediatamente quando o e-mail é claramente inutilizável ou de alto risco (sintaxe inválida, domínio inexistente, ou correspondência com provedores descartáveis). Um soft fail permite criar a conta, mas adiciona atrito — verificação por e-mail, CAPTCHA, limites de taxa ou acesso restrito até a comprovação.
Permita a criação da conta, mas limite ações sensíveis até que a verificação seja concluída. Por exemplo, deixe o usuário definir senha e ver o painel, mas atrase trials, criação de chaves de API, exportações ou convites até a verificação por e-mail.
Trate idade desconhecida como dado não confiável, não como negativo. Use isso para aplicar checagens extras ou step-up verification, e apoie-se mais em sinais de entregabilidade como validade do DNS, presença de MX e correspondência com provedores descartáveis ou blocklists.
Execute as regras em modo monitor por um tempo e registre a faixa de idade, o resultado da validação e a ação proposta, depois compare com desfechos posteriores como bounces, reclamações de spam, estornos ou uso saudável. Para reunir sinais centrais durante o cadastro numa única chamada, uma API de validação de e-mail como Verimail pode retornar sintaxe, verificação de domínio, MX e checagens de descartáveis/blocklist em tempo real.
Domínios novos são atraentes para atacantes porque são fáceis de criar, baratos e descartáveis. Se um domínio é bloqueado, eles podem registrar outro e continuar. Por isso cadastros com “domínio novo” frequentemente aparecem em ondas de contas falsas.
Domínios novos também têm pouco histórico. Há menos sinais públicos para avaliá-los e é menos provável que já estejam em listas de bloqueio. Esse “quadro limpo” ajuda o abuso a passar por filtros simples e ganha tempo até que o domínio adquira má reputação.
Quando esse padrão acontece, costuma gerar os mesmos problemas de negócio: contas criadas por bots que consomem suporte, spam enviado pelo seu produto que prejudica a entregabilidade, trials falsos usados para scraping ou sondagem, fraude em pagamentos que vira estornos e leads de baixa qualidade que poluem relatórios.
Nada disso significa que todo domínio novo seja ruim. Pessoas reais registram domínios todo dia: uma nova empresa, um projeto paralelo, um evento, um rebranding ou uma equipe que passa de caixa gratuita para um endereço com marca. Bloquear todos os domínios novos penaliza exatamente os usuários que você quer atender.
O objetivo prático é reduzir abuso sem bloquear usuários legítimos. Trate a idade do domínio como uma dica de risco, não um veredicto. Combine-a com sinais de validação de e-mail (sintaxe, configuração de domínio, pistas de entregabilidade) e use verificação progressiva para que cadastros de maior risco enfrentem um pouco mais de atrito enquanto usuários normais mantêm um fluxo suave.
Uma startup legítima pode se cadastrar com um domínio registrado na semana passada, mas com configuração de e-mail sólida e comportamento humano. Atacantes frequentemente mostram o oposto: domínio recém-criado, configuração frágil e comportamento automatizado em alta escala.
“Idade do domínio” costuma se referir a uma de duas coisas:
A idade de registro ajuda porque muitas campanhas de abuso registram domínios pouco antes de usá-los. A primeira aparição pode ser ainda mais útil na prática, porque um domínio pode ficar inativo por meses e “acordar” hoje, ou mudar de dono.
Times normalmente obtêm dados de idade de domínio de registros WHOIS/RDAP, feeds de registradores ou registros (quando disponíveis), DNS passivo ou datasets de “primeira observação”, e do histórico do próprio produto (quando viram o domínio pela primeira vez).
Um problema comum é dado ausente ou incerto. Alguns registradores redigem detalhes, serviços de privacidade ocultam campos e alguns TLDs têm registros inconsistentes. Quando a idade do domínio é desconhecida, trate-a como não confiável, não como ruim. Não bloqueie por padrão. Use-a para decidir quais checagens extras aplicar.
Idade do domínio é um sinal, não um veredicto. Muitos usuários reais criam um domínio e se cadastram no mesmo dia. Ao mesmo tempo, muitos cadastros falsos dependem de domínios recém-registrados. O valor vem de combinar a idade com outros sinais.
Idade do domínio é útil, mas sozinha não diz se um endereço é alcançável. Para cadastros com domínios recém-criados, combine a idade com checagens que respondem perguntas simples como “isso é mesmo um e-mail?” e “esse domínio consegue receber e-mail?”.
Comece com checagens de sintaxe compatíveis com RFC. É rápido e captura lixo óbvio como partes faltando, caracteres ilegais ou texto colado que não é um e-mail. Sintaxe sozinha não prova que existe uma caixa postal, mas elimina muito ruído.
Depois, verifique se o domínio existe no DNS. Muitos cadastros abusivos usam erros de digitação, strings aleatórias ou domínios nunca registrados. Isso complementa bem a idade do domínio porque ambos são sinais em nível de domínio.
Em seguida, faça uma consulta a registros MX. O domínio pode receber e-mail? Alguns domínios novos estão registrados, mas sem configuração de e-mail. Se você depende de e-mail para códigos de login, faturas ou onboarding, a falta de MX é um motivo prático para desacelerar o cadastro ou exigir prova extra.
Por fim, compare contra provedores de e-mail descartáveis e infraestrutura conhecida como ruim. Idade do domínio não flagra um provedor descartável de longa data, e blocklists nem sempre capturam um domínio recém-criado. Juntas, essas checagens cobrem lacunas umas das outras.
Uma forma simples de pensar:
Você não precisa de um score de risco perfeito para começar. Um modelo simples funciona bem: coloque o domínio numa faixa de idade, combine isso com o resultado da validação e então tome uma ação consistente.
Mantenha as faixas amplas para poder ajustá-las depois:
Depois combine a faixa com resultados simples de validação como válido, inválido, descartável, arriscado e desconhecido (por exemplo, problemas temporários de DNS).
Defina dois tipos de resposta para que o time não improvise:
Por exemplo, um domínio com 2 dias e correspondência com um provedor descartável costuma ser hard fail. Um domínio com 2 dias que valida limpo pode ser soft fail: crie a conta, mas exija verificação antes de liberar um trial.
O quão rígido você deve ser depende do seu produto. Produtos B2B frequentemente veem domínios novos legítimos (startups, domínios para projetos), então soft fails são mais seguros quando a validação parece forte. Aplicativos de consumo costumam ter mais comportamento descartável, então você pode ser mais severo com domínios de 0–30 dias.
Domínios novos não são automaticamente ruins, mas atacantes os usam para rotacionar identidades rapidamente. Trate a idade do domínio como um sinal e confirme com o que for possível aprender a partir do próprio e-mail.
Valide o e-mail no cadastro (não só sintaxe). Confirme que o domínio existe, que há registros MX presentes e que o endereço não é de um provedor descartável.
Busque a idade do domínio (por exemplo via WHOIS/RDAP ou seu provedor). Não armazene blobs completos de WHOIS. Guarde apenas o necessário: data de criação se disponível, status da busca e a faixa de idade.
Combine sinais em um nível de risco claro. Mantenha regras simples o suficiente para que suporte e produto entendam depois.
Aja: permitir, exigir verificação, aplicar throttling ou bloquear.
Registre entradas e resultados. Bons logs transformam o melhor palpite de hoje numa política confiável no mês seguinte.
As ações devem refletir risco e custo. Um domínio de 2 dias com MX válido mas marcado como descartável é alto risco: bloquear. Um domínio de 5 dias com validação limpa é risco médio: permitir a criação da conta, mas exigir verificação por e-mail antes de liberar um trial ou enviar convites.
A maioria dos cadastros é legítima, mesmo quando o domínio da empresa é novo. Comece com checagens silenciosas e de baixo atrito e só adicione passos quando o risco aumentar.
A validação de e-mail é uma primeira camada forte porque é rápida e invisível ao usuário, e captura erros comuns como digitação, domínios inválidos, falta de MX e provedores descartáveis.
Quando sinais se acumulam (por exemplo, domínio muito novo mais falhas nas checagens), escale com verificação progressiva. Mantenha simples:
Um padrão amigável ao usuário é separar criação de conta de capacidade da conta. Em vez de bloquear de imediato, crie a conta mas mantenha limitações até a verificação ser concluída. Deixe o usuário definir senha e ver o painel, mas restrinja ações sensíveis como convidar colegas, criar chaves de API, exportar dados ou iniciar um trial gratuito.
Tentativas repetidas merecem tratamento especial porque atacantes iteram rápido. Monitore cadastros por IP, por dispositivo (se você usa isso) e por domínio. Se vir muitas tentativas em pouco tempo, acelere a escalada na próxima tentativa.
Implemente gradualmente para não surpreender usuários reais:
Regras funcionam melhor quando são simples, explicáveis e fáceis de ajustar. Comece com poucos resultados (permitir, verificar, bloquear) e depois afine com base no tráfego real.
Aqui estão regras iniciais que cobrem a maioria dos casos:
Exemplo concreto: alguém se cadastra com [email protected] criado ontem. O endereço passa na validação e o domínio tem MX. Em vez de bloquear, você permite criar a conta mas exige verificação por e-mail antes de liberar créditos de trial. Se o mesmo cadastro tivesse correspondência com um provedor descartável, você bloquearia imediatamente.
A forma mais rápida de tornar a proteção impopular é punir usuários honestos. Domínios recém-criados não são automaticamente ruins. Uma meta mais segura é separar “desconhecido” de “malicioso” e só adicionar atrito quando múltiplos sinais apontarem na mesma direção.
Os erros que causam mais dor são previsíveis:
Para evitar isso, use a idade do domínio como sinal leve. Quando os dados de idade faltam ou conflitam, confie mais em checagens de entregabilidade como verificação de domínio, consulta MX e correspondência com provedores descartáveis. Assuma que suas regras serão testadas, adicione limites de taxa e registros, e reveja resultados semanalmente (quantos usuários legítimos foram bloqueados e quais checagens foram preditivas).
Antes de impor regras para cadastros com domínios recém-criados, faça uma revisão rápida para pegar abuso óbvio sem cortar o caminho dos usuários reais:
Se você consegue explicar as regras a um colega em dois minutos, está pronto para um primeiro lançamento. Depois ajuste com dados reais.
Um trial gratuito no seu SaaS é divulgado no Product Hunt e gera um pico de cadastros de domínios recém-criados. O suporte fica sobrecarregado com usuários de trial que nunca ativam e o time de vendas vê as taxas de bounce subirem. Você quer bloquear abuso óbvio sem punir times reais que registraram um domínio ontem.
Um conjunto de regras simples:
Agora compare dois cadastros.
Priya se cadastra com [email protected]. O domínio tem 2 dias. A validação mostra sintaxe válida, o domínio resolve, há registros MX e não é descartável.
Resultado: ela não é bloqueada, mas precisa verificar o e-mail antes de receber acesso completo ao trial. Custa segundos, não minutos.
Um bot se cadastra com [email protected]. O domínio tem 3 horas. A validação mostra falta de MX (ou correspondência descartável) e o mesmo padrão se repete em muitos cadastros.
Resultado: o cadastro é bloqueado imediatamente.
Após o lançamento, meça se o trade-off vale a pena:
Ajuste limiares devagar. O objetivo é bloquear lixo óbvio mantendo equipes novas de verdade em movimento.
Trate regras iniciais como uma hipótese. Rode-as em modo monitor por uma ou duas semanas e registre o que teria acontecido: quem seria desafiado, quem seria bloqueado e quantos desses cadastros depois pareceram suspeitos.
Registre três coisas para cada tentativa de cadastro:
Depois ajuste com base no que encontrar. Se usuários reais com domínios novos estão sendo bloqueados, troque essa faixa de bloqueio para step-up verification. Se abuso continua passando, aperte as regras combinadas em vez de aumentar atrito para todos.
Quando estiver pronto para formalizar o lado do e-mail, uma API de validação pode fornecer os sinais centrais rapidamente durante o cadastro. Por exemplo, Verimail (verimail.co) retorna checagens de sintaxe compatíveis com RFC, verificação de domínio, consulta MX e correspondência em tempo real com provedores descartáveis e blocklists em uma única chamada, o que facilita aplicar regras mais rígidas apenas quando o domínio é muito novo ou os resultados parecem suspeitos.
Revisite limiares mensalmente. O abuso muda, e seu produto também. O objetivo é pressionar continuamente o tráfego ruim sem fazer usuários bons pagarem o preço.
