Crie uma allowlist e denylist de domínios para cadastros que bloqueie domínios descartáveis sem impedir empresas reais. Dicas sobre propriedade e manutenção.
Por padrão, use uma denylist que bloqueie domínios descartáveis conhecidos e domínios ligados a abusos repetidos. Adicione uma allowlist apenas quando o acesso deve ser restrito (como ferramentas internas ou portais de clientes para empresas específicas).
Comece pelos seus próprios dados de cadastro dos últimos 30–90 dias. Procure domínios com alto volume de cadastros mas quase nenhuma ativação, hard bounces repetidos ou relatos claros de abuso; revise algumas amostras antes de bloquear qualquer domínio.
Normalize o domínio do e-mail primeiro: remova espaços, converta para minúsculas e elimine um ponto final sobrando. Depois, combine domínios exatos por padrão, porque padrões amplos são a forma mais fácil de bloquear usuários legítimos por engano.
Um bom padrão é “allowlist vence”, assim uma exceção revisada pode desbloquear usuários reais rapidamente mesmo que exista uma regra deny mais ampla. Se optar por “denylist vence”, espere mais tickets de suporte e recuperação mais lenta.
Evite regras amplas como bloquear TLDs de país, domínios com traços ou qualquer coisa “incomum”. Antes de negar um domínio, verifique se ele é usado por organizações reais (universidades, governo, grandes ISPs) e revise cadastros recentes bem-sucedidos desse domínio.
Mostre um motivo claro e um próximo passo. Por exemplo: “Este provedor de e-mail não é permitido. Use um e-mail corporativo ou contate o suporte para solicitar exceção.” Certifique-se de que o suporte consiga ver qual regra exata disparou o bloqueio.
Rode as regras primeiro em modo “apenas log” para medir o impacto, depois libere em pequenos lotes com um switch de rollback rápido. Teste contra uma amostra recente de cadastros reais para estimar quantos usuários bons seriam bloqueados antes de aplicar a regra.
Designe um dono claro para aprovações e apelações e registre cada alteração com uma razão curta e uma data de revisão. Sem dono, as listas se degradam e você acaba com bloqueios permanentes que ninguém consegue explicar ou remover com confiança.
Reveja a denylist semanalmente e a allowlist mensalmente como base prática. Adicione datas de expiração a bloqueios temporários e exceções para que caiam automaticamente, a menos que alguém renove com evidência recente.
Listas de domínio são camada de política, não prova de que um endereço é real. Combine com validação de e-mail que verifique sintaxe, registros de domínio e MX e sinais de provedores descartáveis para bloquear menos usuários legítimos enquanto ainda pega cadastros ruins.
Regras de domínio existem para proteger o cadastro de problemas previsíveis: contas falsas, e-mails devolvidos e abuso. Se as pessoas podem se cadastrar com endereços descartáveis, você acaba com usuários que não dá para contatar, taxas de bounce maiores e uma base de dados mais bagunçada. Domínios descartáveis também são uma ferramenta comum para bots e fraudadores porque facilitam criar milhares de contas.
Uma allowlist e uma denylist de domínios de e-mail para cadastro é um controle bruto, mas útil. Funciona melhor quando você deixa claro o que está tentando impedir. Bloquear provedores descartáveis conhecidos, por exemplo, pode reduzir rapidamente cadastros de baixa qualidade, mesmo antes de enviar um e-mail de verificação.
Ajuda separar duas ideias:
Essa diferença importa porque o trade-off é real. Regras mais rígidas normalmente significam menos cadastros ruins, mas também mais rejeições falsas. Se você bloquear de forma muito ampla, vai afastar usuários reais tentando se cadastrar de boa-fé.
Então o que conta como domínio corporativo legítimo no seu contexto? Geralmente é um domínio pertencente a uma organização real que recebe mensagens de forma confiável. Isso pode incluir o domínio principal da empresa (como name.com), domínios regionais (name.co.uk) ou um domínio gerenciado por um fornecedor que a empresa usa para a equipe. O objetivo é bloquear domínios arriscados sem punir e-mails comerciais normais.
Uma lista de domínios não é um recurso técnico isolado. É uma decisão de política que afeta receita, carga de suporte e confiança. Antes de construir uma allowlist e denylist para cadastro, seja específico sobre o que você está prevenindo.
A maioria das equipes tem um objetivo primário (e alguns secundários): impedir endereços descartáveis, reduzir fraude em cadastros ou proteger entregabilidade mantendo dados ruins fora. O objetivo importa porque muda o que você bloqueia e quão estrito você é. Bloquear domínios descartáveis costuma ser seguro. Bloquear “e-mails grátis” é arriscado e frequentemente bloqueia usuários legítimos.
Também escreva o que você não vai bloquear, mesmo que pareça suspeito. Exemplos comuns incluem clientes pagantes, usuários convidados, parceiros e contas internas. Uma regra simples como “Permitimos esses fluxos, mas podemos sinalizá-los para revisão” evita muitos bloqueios acidentais.
Decida onde a aplicação acontece para que as regras sejam consistentes no produto: formulários de cadastro self-serve, APIs públicas que criam usuários, usuários criados por admins no back office, fluxos de convite (geralmente mais permissivos) e ações sensíveis como reset de senha e mudança de e-mail (evite surpreender usuários existentes).
Por fim, defina expectativas para suporte. Se alguém for bloqueado, o que vê e como resolve? Uma boa mensagem de bloqueio inclui uma razão simples (“Este provedor de e-mail não é permitido”), um próximo passo seguro (use um e-mail corporativo ou contate o suporte) e um caminho claro de apelação.
Allowlist é a opção estrita. Você só deixa pessoas se inscreverem se o domínio do e-mail pertencer a um conjunto que você confia. Isso funciona melhor quando você já sabe quem deve ter acesso.
Casos comuns de allowlist incluem ferramentas internas para funcionários, betas privados onde convites vão para empresas específicas ou portais B2B onde cada conta mapeia para um domínio de negócio conhecido. Nessas configurações, bloquear uma pessoa real é menos arriscado porque os domínios certos são previsíveis e o suporte pode adicionar domínios faltantes.
A denylist é a opção flexível. Você deixa a maioria dos domínios passar, mas bloqueia domínios que são claramente de baixa qualidade ou abusivos. É aqui que normalmente bloqueia-se domínios descartáveis, domínios ligados a abuso repetido e padrões óbvios de endereços temporários.
Uma abordagem híbrida costuma ser a mais segura para crescimento: use uma denylist como base e adicione overrides de allowlist direcionados para casos importantes. Por exemplo, um grande cliente pode usar um domínio corporativo menos comum, ou um parceiro legítimo pode se cadastrar a partir de um subdomínio que à primeira vista parece suspeito.
Mantenha a linguagem das regras simples para facilitar revisão e reduzir equívocos. Combine domínios exatos (por exemplo, example.com) sempre que puder. Decida desde o começo se subdomínios são tratados como iguais (se mail.example.com deve contar). Se usar exceções temporárias, dê-lhes um dono e uma data de expiração, e prefira regras pequenas e claras a padrões inteligentes que podem bloquear pessoas erradas.
Uma lista inicial boa não é algo que você baixa e cola. Deve basear-se no que realmente acontece no seu fluxo de cadastro. Assim você constrói uma allowlist e denylist que reflete risco real, não suposições.
Comece pelos seus próprios dados. Puxe os últimos 30 a 90 dias de tentativas de cadastro, usuários confirmados, bounces, reclamações de spam e quaisquer relatórios de fraude ou abuso. Agrupe por domínio e procure padrões como volume alto com ativação muito baixa, hard bounces repetidos ou o mesmo domínio criando muitas contas em pouco tempo.
Se tiver relatórios internos, busque reincidentes. Uma regra prática: domínios que geram alto volume mas quase nenhuma interação pedem revisão, não bloqueio automático. Escolha um número pequeno, investigue alguns endereços e confirme o comportamento antes de adicionar o domínio.
Construa o lado “bom” também a partir do conhecimento interno. Pergunte ao time de Vendas e Customer Success por uma lista curta de domínios principais de clientes e prospects ativos. Eles podem se tornar sua allowlist inicial (ou pelo menos uma lista de “nunca bloquear sem revisão”), o que evita atrito para empresas reais.
Seja qual for a entrada, escreva por que ela está lá. Mantenha a nota curta e útil: a fonte (relatório, ticket, caso de fraude, dados de bounce), data de inclusão, quem aprovou, o que foi observado e quando será revisado.
Exemplo: você vê 400 cadastros de um domínio numa semana, mas zero confirmações e muitos IPs idênticos. Você registra a evidência, adiciona ao denylist e define revisão em 30 dias caso o padrão mude.
Trate o domínio do e-mail como entrada não confiável. Pequenas diferenças de formatação podem quebrar suas regras.
Normalize todo endereço da mesma forma antes de compará-lo com qualquer lista: remova espaços, passe para minúsculas e retire um ponto final (alguns sistemas tratam example.com. como válido). Faça isso uma vez, perto de onde o e-mail entra no sistema, para que toda verificação downstream veja o mesmo valor.
Em seguida, decida como a correspondência funciona e documente. “Domínio exato apenas” é mais seguro para a maioria das equipes porque evita surpresas. “Incluir subdomínios” pode ser útil (por exemplo, bloquear mail.disposable.com junto com disposable.com), mas também pode bloquear setups legítimos se uma empresa usar subdomínios incomuns.
Escolha uma regra de desempate e aplique-a em todo lugar. Muitos produtos optam por “allowlist vence” para que uma exceção revisada desbloqueie usuários reais imediatamente, mesmo se existir uma regra deny mais ampla. Se escolher “denylist vence”, espere mais tickets e desbloqueios mais lentos.
Um rollout seguro costuma parecer com isto:
A forma mais rápida de perder cadastros reais é bloquear com padrões amplos. Evite regras como “negar todos os TLDs de país” ou “negar qualquer coisa com um traço.” Muitas empresas reais usam domínios como company.co.uk, company.com.au ou configurações regionais como eu.company.com.
Trate subdomínios como normais, não suspeitos. Uma grande empresa pode rotear e-mail por subdomínios diferentes para times, regiões ou aquisições. Se sua regra checa apenas o “domínio principal”, assegure-se de que ela trata corretamente casos como company.co.uk vs company.com, e não rotule mail.company.com como “desconhecido”.
Cuidado com provedores de roteamento de e-mail. Alguns negócios legítimos enviam e recebem pelo meio de serviços que parecem genéricos, e seus registros MX podem assemelhar-se àqueles usados por setups descartáveis ou apenas de marketing. Regras de domínio isoladas não conseguem indicar intenção.
Uma checklist de segurança antes de adicionar uma regra de deny:
Por fim, crie um processo de exceção para contas de alto valor. Após fusões, um cliente pode ter cinco a dez domínios ativos. Facilite que suporte ou vendas peçam uma exceção temporária enquanto você verifica propriedade e atualiza regras com segurança.
Regras de domínio falham com mais frequência por um motivo chato: ninguém as possui. Dê a um time ou papel uma responsabilidade clara por aprovar mudanças e lidar com apelações. Não se trata de controle, mas de velocidade e consistência quando um cliente real é bloqueado.
Um fluxo básico é suficiente:
Cada mudança deve ser logada para que você possa explicar depois. Mantenha o log enxuto: quem requisitou, quem aprovou, o que mudou (domínio e tipo de regra), por quê (evidência), quando entrou no ar e quando re-checar.
Defina um SLA para blocos em disputa para que usuários legítimos não fiquem presos. Por exemplo: acuse recebimento em 4 horas úteis e resolva em 1 dia útil, com um caminho de emergência para clientes pagantes.
Antes de negar um domínio, exija evidência, não impressão. Provas típicas incluem volume alto de cadastros com padrões claros de abuso, hard bounces repetidos, reclamações de spam ou alta taxa de correspondência com provedores descartáveis conhecidos.
Exemplo: suporte relata que usuários de acme-partners.com não conseguem se cadastrar. O responsável checa o log, vê que foi bloqueado por 30 cadastros de spam em uma hora e troca para uma regra temporária mais checada, depois revisa em 48 horas.
Uma lista de domínios não é setup único. No momento em que você para de cuidar dela, ela deriva: padrões antigos de abuso desaparecem, novos domínios descartáveis surgem e uma única entrada ruim pode bloquear usuários legítimos silenciosamente.
Defina um ritmo de revisão que combine com o risco. Semanal para a denylist é um ponto de partida comum, já que atacantes se movem rápido. Mensal para a allowlist costuma funcionar porque domínios legítimos mudam mais devagar.
Para evitar “list rot”, faça decisões temporárias expirarem por padrão. Se adicionar um domínio por causa de uma onda de spam curta, anexe uma data de expiração e uma nota do porquê. Faça o mesmo para exceções (“permitir este domínio para Parceiro X até o fim do contrato”). Quando a data chegar, a regra cai a menos que alguém renove com nova evidência.
Monitore alguns indicadores para ver se a lista está ajudando ou atrapalhando: taxa de bloqueio, taxa de apelação, falsos positivos (usuários legítimos confirmados que você bloqueou), taxa de bounce e concentração por domínio (quanto tráfego vem de um domínio só).
Fique atento a dois sinais em particular: novos domínios descartáveis e picos repentinos em um domínio só. Se examplemail.co passa de 2 cadastros por dia para 400 em uma hora, investigue antes de bloquear em massa. Olhe geografia, padrões de IP e se endereços são sintaticamente válidos e têm roteamento de e-mail real.
Por fim, aposente entradas agressivamente. Se um domínio não produz abuso há um tempo, ou continua gerando falsos bloqueios para empresas reais, remova-o ou troque um bloqueio rígido por um controle mais suave como limites de taxa, verificação extra ou revisão manual.
A forma mais rápida de quebrar a confiança com usuários reais é bloquear domínios baseado em palpites. Uma allowlist e denylist só funcionam se baseadas em evidência, revisadas frequentemente e aplicadas da mesma forma em todo lugar.
Uma armadilha comum é bloquear de forma muito ampla. Equipes às vezes negam TLDs inteiros ou um grande provedor de e-mail por causa de um pico temporário de cadastros ruins. Isso quase sempre pega pessoas legítimas, especialmente contratados, estudantes e usuários internacionais.
Outra armadilha é rotular um domínio como descartável só porque é novo, incomum ou parece “aleatório”. Muitas empresas reais usam domínios pequenos hospedados, rebrands ou provedores regionais. Se não tiver prova (taxa de fraude, taxa de bounce, relatos de abuso), trate “desconhecido” como “não sabido”, não como “ruim”.
Padrões que causam mais dano:
Mesmo um bloqueio correto cria problemas se a experiência do usuário for confusa. Se alguém esbarra em um bloqueio, precisa entender o que ocorreu e o que fazer a seguir. Logue a razão exata e a regra que disparou, mostre uma mensagem clara (evite “e-mail inválido”) e mantenha um caminho rápido de exceção para clientes e parceiros conhecidos.
Antes de aplicar uma atualização na sua allowlist e denylist, faça uma checagem de segurança. A maior parte do dano vem de pequenas inconsistências, contexto faltando ou mudanças sem retorno.
Comece pelas regras de correspondência. Decida se combina apenas domínios exatos (example.com) ou inclui subdomínios (mail.example.com). Normalize a entrada sempre da mesma forma: minúsculas, trimming de espaços e formato consistente para domínios internacionais. Se seu sistema trata Gmail.com e gmail.com de forma diferente, você vai perder casos e criar comportamento confuso.
Assegure que cada regra seja explicável. Cada entrada deve ter uma razão curta, data de adição e um dono que possa responder depois. “Domínio ruim” não é uma razão. “Visto em 1.200 cadastros de fraude na semana passada” é.
Mantenha o caminho de apelação simples, mas real. Coloque revisão com prazo em entradas contestadas para que erros não vivam para sempre. E não deixe exceções temporárias virarem permanentes por acidente: se permitir um domínio arriscado para um rollout de parceiro ou evento, coloque expiração e remova a menos que alguém renove com justificativa.
Após a mudança entrar no ar, monitore o impacto. Acompanhe falsos positivos e trate-os rápido. Monitore bounce e entregabilidade para domínios recém-permitidos. Amostre cadastros recentes para confirmar que as regras se comportam como esperado.
Uma SaaS B2B nota um pico de contas novas usando domínios parecidos (como "acme-corp-support.com" em vez da empresa real) e uma onda de provedores descartáveis. Vendas reclama de leads lixo e suporte vê mais tentativas de chargeback. A equipe já tem uma allowlist e denylist, mas ela não era tocada há meses.
Eles começam com resposta medida, não uma limpeza agressiva. Primeiro, adicionam uma regra deny direcionada para o pior domínio descartável nos logs. Também colocam um limite de taxa temporário em cadastros que parecem arriscados (mesma faixa de IP, alta velocidade, nomes de usuário repetidos). Isso reduz o abuso enquanto aprendem, em vez de bloquear categorias inteiras de domínios.
Dois dias depois, um cliente real é bloqueado. Uma grande empresa usa um subdomínio regional para e-mail (por exemplo, [email protected]). Uma regra ampla criada para pegar lookalikes o correspondeu por engano. O suporte escala com evidência: o prospect tem proposta assinada, histórico de IP consistente e mensagens estão sendo devolvidas porque a conta nunca completou cadastro.
A correção não é remover a entrada do denylist. Em vez disso, adicionam uma exceção de allowlist estreita para o domínio corporativo verificado, documentam o porquê e colocam data de expiração para revisão posterior.
Após duas semanas, a equipe revisa resultados: bloqueios sobem para 6% (de 1%), mas apelações de suporte ficam baixas, em 0,2% dos cadastros. A taxa de bounce em e-mails de boas-vindas cai de 3,4% para 1,1% e vendas relata menos demos falsas agendadas. A vitória chave é confiança: agora cada regra tem dono, razão e caminho de rollback.
Allowlists e denylists são úteis, mas são ferramentas rudes. Combine-as com validação de e-mail para pegar endereços ruins mesmo quando o domínio parece normal, e assim evitar bloquear usuários reais só porque usam um domínio corporativo pouco conhecido.
Comece escrevendo sua política em linguagem simples: o que bloqueia, o que permite e o que vai para revisão manual. Isso mantém suporte, produto e engenharia alinhados quando alguém pergunta por que um cadastro foi rejeitado.
Um fluxo prático é: verifique sintaxe, confirme que o domínio pode receber e-mails (DNS e checks MX), faça triagem por provedores descartáveis e armadilhas de spam, e então aplique suas regras de allowlist e denylist (incluindo exceções). Registre o resultado para aprender e ajustar.
Se quiser manter as regras simples enquanto obtém sinais fortes no cadastro, Verimail (verimail.co) é uma opção que equipes usam para validar e-mails com checagens RFC-compliant de sintaxe, verificação de domínio e MX e correspondência de provedores descartáveis em uma única chamada de API. Usada assim, suas listas permanecem a camada de política, e a validação faz o trabalho pesado de decidir se um endereço parece real e alcançável.
