Cadastros com domínios recém-criados: detectar e prevenir abuso

Por que domínios recém-criados aparecem em cadastros abusivos

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.

O que “idade do domínio” é e o que ela pode (e não pode) dizer

“Idade do domínio” costuma se referir a uma de duas coisas:

• Idade de registro: quando o domínio foi registrado num registrar.
• Primeira aparição: quando o domínio apareceu pela primeira vez em sinais como datasets de DNS, tráfego de e-mail ou telemetria de segurança.

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.

Sinais de validação de e-mail que combinam bem com idade de domínio

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:

• Sintaxe confirma que o input parece um e-mail.
• DNS e checagens de domínio confirmam que o domínio é real e responde.
• MX confirma que o domínio está configurado para receber e-mail.
• Checagens de descartáveis e blocklists sinalizam fontes de alto risco rapidamente.

Um modelo de decisão simples: agrupe por idade do domínio e aja

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:

• 0–7 dias: risco mais alto
• 8–30 dias: risco elevado
• 31–180 dias: risco médio a baixo
• 180+ dias: risco mais baixo

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:

• Hard fail: bloquear o cadastro imediatamente (e-mail claramente inválido, provedor descartável claro, erros de sintaxe óbvios).
• Soft fail: permitir que o usuário prossiga, mas adicionar atrito (verificação por e-mail, CAPTCHA, limites de taxa, revisão manual ou atraso de acesso até verificação).

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.

Passo a passo: combine idade do domínio com resultados de validação

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.

1. 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.

2. 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.

3. Combine sinais em um nível de risco claro. Mantenha regras simples o suficiente para que suporte e produto entendam depois.

4. Aja: permitir, exigir verificação, aplicar throttling ou bloquear.

5. 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.

Regras de verificação progressiva que reduzem atrito para usuários reais

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:

• Baixo risco: cadastro normal
• Risco médio: verificação por código enviado por e-mail (OTP)
• Alto risco: CAPTCHA mais verificação por código por e-mail
• Tentativas repetidas: limites temporários de taxa e cooldowns
• Abuso claro: bloquear

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:

• Semana 1: apenas monitoramento (registre decisões, não bloqueie)
• Semana 2: aplique apenas aos casos de maior risco
• Semana 3: expanda a aplicação e ajuste limiares

Exemplos práticos de regras para começar

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:

• Se um domínio é muito novo e não tem MX (ou o domínio não resolve de forma confiável), bloqueie e peça outro e-mail.
• Se um domínio é muito novo, tem MX, mas o endereço é descartável, bloqueie.
• Se um domínio é muito novo, passa na validação e não é descartável, permita o cadastro mas exija verificação por e-mail antes de liberar recursos valiosos (ativação de trial, chaves de API, exportações).
• Se o domínio é mais antigo e a validação está limpa, siga o fluxo normal.
• Se a idade do domínio é desconhecida e os sinais são mistos, trate como risco médio e coloque ações sensíveis atrás de verificação ou revisão.

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.

Erros comuns e armadilhas a evitar

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:

• Bloquear todos os domínios com menos de X dias
• Tratar datas WHOIS como verdade absoluta
• Parar em checagens de sintaxe
• Não medir falsos positivos
• Permitir que atacantes testem suas regras sem limites (sem rate limits, eles conseguem achar brechas)

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).

Lista rápida de verificação antes de aplicar regras

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:

• Confirme o que suas checagens de e-mail retornam: sintaxe, domínio/DNS, MX, detecção de descartáveis e quaisquer flags de risco.
• Escolha faixas de idade do domínio e documente a ação correspondente para cada uma.
• Prefira step-up verification a uma barreira única e rígida.
• Registre cada decisão em linguagem simples (faixa de idade, sinais de validação, ação, motivo).
• Crie um caminho de override para usuários legítimos que forem sinalizados.

Se você consegue explicar as regras a um colega em dois minutos, está pronto para um primeiro lançamento. Depois ajuste com dados reais.

Cenário de exemplo: parar trials falsos sem bloquear equipes novas

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:

• Se a idade do domínio for menor que 7 dias, exija verificação por e-mail antes da conta poder iniciar um trial.
• Se a idade do domínio for menor que 24 horas e o e-mail parecer arriscado (descartável, em blocklist ou sem MX), bloqueie.
• Se a idade do domínio for 7+ dias e a validação estiver limpa, permita trial instantâneo.

Agora compare dois cadastros.

Cadastro A: uma startup real

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.

Cadastro B: um spammer automatizado

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:

• Taxa de conversão de trial para ativação (geral e para domínios com menos de 7 dias)
• Taxa de bounce e entregabilidade de e-mail
• Taxa de abuso (trials falsos, cadastros por bot, reclamações de spam)
• Taxa de conclusão de verificação e tempo até verificar
• Tickets de suporte ligados a cadastro e acesso

Ajuste limiares devagar. O objetivo é bloquear lixo óbvio mantendo equipes novas de verdade em movimento.

Próximos passos: medir, ajustar e adicionar uma camada de validação

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:

• Faixa de idade do domínio e a ação que isso acionaria
• Resultado da validação de e-mail (válido, arriscado, inválido, descartável)
• Resultado alguns dias depois (estorno, reclamação de spam, bounce, ticket de suporte ou usuário saudável)

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.