Como criar uma pontuação de risco de e‑mail: uma rubrica simples baseada em sinais

O que é uma pontuação de risco de e‑mail (e por que você pode precisar de uma)

Uma pontuação de risco de e‑mail é um número simples (ou um rótulo como baixo, médio, alto) que estima quão provável é que um endereço de e‑mail cause problemas para o seu negócio. “Problemas” normalmente significam cadastros falsos, e‑mails rejeitados (bounces), reclamações de spam ou usuários que você não consegue mais alcançar.

Não é um veredito sobre se alguém é “bom” ou “mau”. É um resumo rápido e consistente de sinais que você já tem.

Uma pontuação ajuda quando passar/falhar é muito bruto. Muitos endereços parecem válidos na superfície, mas ainda carregam risco. Um e‑mail pode ter sintaxe correta e um domínio real, mas ainda ser descartável, mal configurado ou ligado a padrões que antes levaram a abuso.

Com uma pontuação de risco, você pode tomar decisões consistentes sem transformar cada caso limite em debate. Ações típicas incluem:

• Permitir o cadastro e seguir normalmente
• Permitir, mas adicionar fricção (verificação por e‑mail, CAPTCHA, limites)
• Enviar para revisão manual em ações de alto valor
• Bloquear o cadastro ou impedir certas ações

Explicabilidade importa. Equipes não técnicas devem ser capazes de responder “Por que isso foi considerado alto risco?” Mire em razões simples como “provedor descartável”, “domínio não recebe e‑mail” ou “checagens de domínio falharam”.

Uma maneira simples de alinhar todo mundo é ligar cada faixa de pontuação a uma política clara. Por exemplo: 0–30 significa baixo risco e aprovação automática, 31–70 significa risco moderado e exigência de verificação, e 71–100 significa alto risco e bloqueio ou revisão. O objetivo não é um número perfeito. O objetivo é uma decisão que você possa explicar, medir e ajustar.

Sinais de e‑mail a incluir: a lista prática e curta

Comece com um pequeno conjunto de sinais que sejam fáceis de explicar e difíceis de manipular. Você sempre pode adicionar mais depois.

Comece com checagens de sintaxe estritas. Isso é mais do que “tem um @”. Parsing no estilo RFC detecta partes faltantes, caracteres ilegais, pontos duplicados e formatos complicados que muitos sistemas tratam mal. Checagens de sintaxe são baratas e impedem lixo óbvio cedo, mas não dizem se a caixa postal pode realmente receber mensagens.

Em seguida, verifique a saúde do domínio. Duas checagens fazem a maior parte do trabalho: o domínio existe (DNS resolve) e publica registros MX. MX não é perfeito (alguns domínios aceitam e‑mail sem ele), mas é um forte indicativo de alcançabilidade. Um domínio novo sem configuração de e‑mail costuma ser de maior risco no cadastro.

Flags de provedores descartáveis importam mais na criação de conta. Caixas descartáveis aparecem em abuso de testes gratuitos, caça a cupons e captura de leads falsos. Você nem sempre precisa bloquear, mas deve pontuar.

Você também pode incluir sinais no estilo reputação, com cuidado. Blocklists e indicadores de spam‑trap podem reduzir bounces, mas falsos positivos acontecem. Trate‑os como entradas de alta confiança apenas, e prefira ações mais suaves (como verificação extra) em vez de bloqueios rígidos.

Finalmente, adicione contexto que você já tem. O e‑mail raramente conta toda a história sozinho. Entradas úteis incluem de onde veio o cadastro, velocidade incomum de cadastros, padrões repetidos e o que aconteceu com cadastros semelhantes antes.

Exemplo: durante uma promoção, um endereço sintaticamente válido em um domínio sem MX, com flag descartável e alta velocidade de cadastros é um sinal mais forte do que qualquer uma dessas checagens isoladamente.

Defina o que a pontuação deve prever

Uma pontuação de risco só funciona se todos concordarem sobre o que “risco” significa. Comece registrando a decisão que ela suporta. Você quer bloquear cadastros ruins, reduzir bounces ou cortar carga de suporte? Se a pontuação tentar fazer tudo ao mesmo tempo, ela se torna confusa e difícil de ajustar.

Separe risco de entregabilidade do risco de fraude

Eles estão relacionados, mas não são a mesma coisa.

Risco de entregabilidade trata de se você consegue alcançar o endereço. Ele mapeia para resultados como hard bounces, bounces repetidos ou dano à reputação do remetente.

Risco de fraude ou abuso trata do usuário por trás do endereço. Ele mapeia para resultados como chargebacks, abuso de cupons, contas falsas, denúncias de spam ou valor de vida útil muito baixo.

Você pode lidar com isso de duas formas simples: manter duas pontuações separadas, ou manter uma pontuação mas rotulá‑la claramente (por exemplo, “risco de abuso no cadastro”).

Defina o resultado e o custo dos erros

Escolha um resultado primário para prever, depois adicione secundários mais tarde. Bons alvos iniciais incluem:

• “Este e‑mail de cadastro vai dar bounce dentro de 7 dias?”
• “Esta conta vai gerar um evento de abuso dentro de 30 dias?”
• “Este usuário terá baixo valor (sem ativação, sem compra) dentro de 14 dias?”

Depois decida o custo de um falso positivo. Se você bloquear um cliente real, perde receita e confiança. Se deixar um cadastro arriscado passar, pode pagar em chargebacks, tempo de suporte ou dano à entregabilidade. Sua tolerância a esses trade‑offs deve moldar os limites.

Por fim, escolha uma escala de pontuação e o que ela significa. Uma escala de 0–100 é fácil de comunicar, mas só funciona se você definir faixas como 0–24 baixo risco, 25–59 médio, 60–100 alto. Vincule cada faixa a uma ação para que a pontuação seja mais que um número.

Escolha um modelo de pontuação que você consiga explicar

Uma pontuação de risco só é útil se as pessoas confiarem nela. Isso significa que você deve ser capaz de responder duas perguntas em palavras simples: por que este cadastro recebeu essa pontuação, e o que devemos fazer a seguir?

Uma rubrica baseada em pontos é geralmente o lugar mais fácil para começar. Ela funciona como uma checklist com uma pontuação total, e é simples de escrever em um documento de política. Uma média ponderada ou um modelo pequeno pode ser mais preciso, mas é mais difícil de explicar quando alguém pergunta “Por que isto foi bloqueado?”.

Aqui está uma abordagem de pesos simples usando quatro sinais principais. Mantenha a matemática chata e os resultados claros:

• Sintaxe e formatação (0 a 10): erros óbvios, caracteres inválidos, checagens RFC falhadas
• Saúde do domínio (0 a 35): domínio existe, DNS válido, sem sinais óbvios de risco
• Roteamento de e‑mail (0 a 35): registros MX presentes e normais, sem falhas graves
• Flags descartáveis e listas de risco (0 a 20): correspondência com provedores descartáveis, padrões conhecidos ruins, indicadores de spam‑trap

Isso soma 100. Nesse setup, pontuação mais alta significa maior risco.

Dados ausentes vão ocorrer, especialmente com timeouts de DNS ou falhas temporárias de lookup. Decida desde o início se “desconhecido” deve ser neutro, levemente arriscado ou motivo para nova tentativa:

• Trate um timeout como “desconhecido” e tente novamente uma vez antes de pontuar
• Se MX estiver desconhecido após a nova tentativa, atribua uma pequena penalidade (por exemplo, +10), não uma falha automática
• Se o domínio claramente não existir, trate como falha grave independentemente de outros sinais

Calibre para seu produto. Um fluxo de convite B2B pode ser mais rigoroso em saúde de domínio e MX (espera‑se e‑mails corporativos). Um cadastro de consumidor pode permitir mais domínios gratuitos, mas deve ser mais rígido em flags descartáveis.

Passo a passo: construir uma rubrica de pontuação simples

Uma boa pontuação começa transformando sinais bagunçados em comparáveis. Não tente pontuar cada detalhe minúsculo. Converta cada sinal em alguns buckets claros que um colega não técnico possa reconhecer e explicar.

1) Agrupe cada sinal primeiro

Escolha 3 a 4 buckets por sinal. Por exemplo: sintaxe (válida, questionável, inválida), saúde do domínio (saudável, desconhecida, quebrada), flag descartável (não, talvez, sim) e resultados históricos (histórico bom, misto, ruim). Mantenha nomes de buckets simples.

Depois atribua pontos com um padrão simples: bom recebe poucos pontos, incerto recebe médio, ruim recebe muitos. Se e‑mails descartáveis são o maior motor de abuso para você, dê a esse sinal mais peso que falhas menores de sintaxe.

Um fluxo prático:

• Converta cada sinal bruto em um bucket com regras fixas
• Dê a cada bucket um valor de pontos (exemplo: 0, 10, 25)
• Some os pontos em um total
• Limite o total a uma faixa estável (como 0 a 100)
• Armazene os buckets, pontos e pontuação final para cada decisão

2) Mapeie faixas de pontuação para ações

A pontuação só importa se orientar uma ação consistente. Mantenha poucas faixas e óbvias:

• 0–24: permitir cadastro
• 25–59: permitir, mas adicionar verificação (OTP por e‑mail, CAPTCHA ou revisão manual para fluxos de alto valor)
• 60–100: bloquear ou exigir prova mais forte

Logar não é opcional. Salve os buckets de entrada (não apenas a pontuação final) e a ação tomada. Se você usa uma API de validação de e‑mail, armazene os principais resultados que você usou para poder comparar pontuações com resultados reais depois.

Um exemplo concreto de rubrica (simples o suficiente para um documento de política)

Uma pontuação simples funciona melhor quando é fácil de explicar para suporte, fraude e marketing. Comece com 0 pontos (risco mais baixo) e some pontos quando um sinal aumentar a chance de que o endereço vai bounce, ser falso ou levar a abuso.

Tabela de pontuação de exemplo

Limiares e ações

• Baixo risco (0–29): permitir cadastro
• Risco médio (30–59): permitir, mas adicionar fricção (verificação por e‑mail, limites de taxa, revisão manual)
• Alto risco (60+): bloquear ou exigir prova forte (OTP mais checagens adicionais)

Orientação em casos limites: se a sintaxe é válida e o domínio resolve mas não há MX, trate como risco médio por padrão, não como bloqueio automático. Alguns domínios estão temporariamente mal configurados, e você não quer recusas indevidas.

Para manter a rubrica estável ao adicionar novos sinais, limite o impacto de qualquer novo sinal (por exemplo, +10 a +15) e só mude limites após ter dados de resultado.

Exemplo de cenário: pontuando cadastros durante uma campanha

Uma grande promoção pode mudar seu tráfego da noite para o dia. Você atrai mais clientes reais, mas também bots, caçadores de cupons e pessoas usando endereços descartáveis para pegar a oferta e sumir. Uma pontuação de risco ajuda a decidir quem pode se cadastrar sem atrito e quem deve enfrentar uma checagem extra.

Suponha que sua escala seja 0 a 100 (maior = mais arriscado). Você roda sinais de validação (sintaxe, domínio e MX, flags descartáveis e seus próprios resultados históricos) por um pipeline, depois atribui pontos.

Aqui estão dois cadastros da mesma campanha:

Para o segundo cadastro, “adicionar verificação” pode ser leve: OTP por e‑mail, link mágico, ou exigir que o usuário verifique antes de resgatar a promoção. Você não está bloqueando todo mundo. Está adicionando lombadas de velocidade apenas onde os sinais dizem que vale a pena.

Com o tempo, ajuste pesos usando resultados, não palpites. Se e‑mails com flag descartável ainda convertem e permanecem ativos, reduza essa penalidade. Se um domínio específico continuar gerando bounces, chargebacks ou reclamações, aumente os pontos por histórico do domínio.

Erros comuns e como evitá‑los

A forma mais rápida de perder confiança numa pontuação de risco é tratar um sinal como veredito. Sinais de e‑mail são bagunçados: redes falham, domínios ficam mal configurados e pessoas reais às vezes usam endereços que parecem suspeitos.

Erro 1: tratar “descartável” como “bloquear sempre”

A detecção de descartáveis é útil, mas não é o mesmo que fraude. Se você der muito peso, vai bloquear usuários reais que só querem privacidade ou um teste rápido. Uma abordagem mais segura é pontuar fortemente, depois parear com contexto como velocidade de cadastros, intenção de pagamento ou se o endereço passa checagens de domínio e MX.

Erro 2: transformar problemas temporários de DNS em risco permanente

Timeouts de DNS acontecem. Não trate um timeout igual a “domínio não existe”. Mantenha um bucket separado para “desconhecido agora”, tente novamente uma vez e só aumente o risco levemente a menos que outros sinais concordem.

Erro 3: empilhar sinais que não adicionam informação nova

É fácil contar a mesma ideia duas vezes. Por exemplo, “sem registro MX” e “verificação de domínio falhou” podem ser duas visões do mesmo problema. Se você somar ambas com peso total, inflaciona o risco sem melhorar a precisão. Escolha a versão mais clara, ou reduza pesos quando sinais se sobrepõem.

Erro 4: deixar a pontuação derivar com o tempo

À medida que campanhas mudam e atacantes se adaptam, pesos de ontem deixam de refletir a realidade. Reveja resultados (bounces, reclamações, chargebacks, taxas de ativação) periodicamente e fique atento a mudanças abruptas.

Erro 5: aprender com dados errados

Mantenha testes e ambiente de staging separados. Dados semeados como [email protected], scripts de QA e domínios internos podem contaminar seus resultados de “bom vs ruim”.

Um checklist prático de prevenção:

• Separe “inválido” de “temporário/desconhecido” nas respostas
• Limite o impacto de flags descartáveis a menos que outros sinais confirmem
• Remova ou reduza peso de sinais sobrepostos
• Monitore métricas de resultado e re‑tune em uma cadência
• Exclua tráfego não produtivo do treinamento e relatórios

Como validar e ajustar a pontuação usando resultados

Uma pontuação só é útil se corresponder ao que acontece depois. Trate sua pontuação como uma predição que você pode checar.

Comece coletando outcomes ligados ao cadastro: entregue vs bounced, reclamações, abuso de conta, chargebacks, flags de suporte e qualquer fraude confirmada.

Escolha algumas faixas de pontuação (por exemplo: Baixa, Média, Alta) e reveja‑as com uma cadência fixa. Semanalmente costuma bastar no início; diariamente ajuda quando você está em grandes campanhas ou mudando políticas.

O que medir por faixa

Procure separação: alto risco deve ter resultados notavelmente piores que baixo risco. Monitore um conjunto pequeno de métricas de forma consistente:

• Taxa de bounce e taxa de hard‑bounce por faixa
• Eventos de abuso ou fraude por faixa (definidos por você)
• Taxa de aceitação na revisão manual por faixa (se fizer revisão)
• Proporção de cadastros em cada faixa, para detectar mudanças repentinas
• Sinais de valor a jusante (ativação, conversão paga) se você os tiver

Se as faixas parecerem semelhantes, seus sinais não estão puxando peso suficiente ou seus limites estão errados. Por exemplo, se “Alto” tem a mesma taxa de bounce que “Baixo”, você ou está sendo muito rigoroso em sinais inofensivos (como pequenas falhas de sintaxe) ou muito permissivo em sinais fortes (como detecção de descartáveis).

Como ajustar sem quebrar tudo

Mude uma coisa de cada vez e torne a mudança mensurável. O ajuste mais seguro costuma ser o limite, não o modelo inteiro.

Rode um teste A/B (ou um pequeno holdout) antes de aplicar novos cortes. Exemplo: por uma semana, bloqueie apenas o 1% mais arriscado no grupo de teste, enquanto o controle usa sua política atual. Compare bounce, abuso e perda de usuários reais.

Checklist rápido antes de lançar a pontuação

A maioria dos problemas de rollout vem de ações pouco claras, guardrails faltando ou entradas barulhentas.

• Confirme que você só pontua endereços que passam regras básicas de sintaxe (e trate erros óbvios de forma consistente)
• Verifique que o domínio é real e pode receber e‑mail, incluindo MX (ou seu equivalente escolhido)
• Decida como tratar provedores descartáveis: bloquear, desafiar ou permitir com limites
• Defina o que “risco de domínio” significa para seu app (domínios recém‑vistos, provedores raros ou histórico ruim)
• Garanta que cada sinal possa ser explicado em uma frase curta nos logs e notas de suporte

Agora mapeie a pontuação para uma ação. Se duas pessoas na sua equipe escolheriam ações diferentes para a mesma pontuação, a política ainda não está pronta.

Se você quiser uma quarta faixa durante campanhas, adicione‑a explicitamente (e mantenha operacionalmente simples): muito alto risco pode ser desacelerado ou bloqueado.

Detalhes operacionais: logging, explicabilidade e estabilidade

Uma rubrica de pontuação só ajuda se você conseguir operá‑la no dia a dia. Trate sua pontuação como qualquer outro sistema de decisão: logue o suficiente para depurar, explique para humanos e mantenha estável sob tráfego real.

Comece com logging para poder recriar o que aconteceu em qualquer cadastro. Capture as entradas brutas (resultado de sintaxe, checagens de domínio/MX, flag descartável, qualquer match em blocklist), a pontuação final e a ação tomada (permitir, fricção, revisão, bloquear). Armazene um request ID para que o suporte encontre a história completa rápido.

Torne a pontuação explicável em palavras simples. Além do valor numérico, mantenha uma string de motivo curta que alguém possa ler em cinco segundos. Por exemplo: “Provedor descartável + falha na checagem MX, pontuação 82, bloqueado.”

Estabilidade sob tráfego real

Checagens de e‑mail podem falhar por motivos alheios ao usuário. Planeje timeouts, novas tentativas limitadas, limites de taxa e fallback seguro. Se checagens falharem, retorne um estado conservador “desconhecido” em vez de deixar a pontuação oscilar muito.

Privacidade e retenção

Logs de e‑mail são sensíveis. Mantenha apenas o necessário, restrinja acesso e defina uma janela de retenção (por exemplo, 30 a 90 dias para sinais brutos). Se precisar de análises de longo prazo, armazene agregados ou identificadores hashed em vez de endereços completos.

Próximos passos: implementar, medir e manter simples

Comece pequeno. Sua primeira pontuação deve ser uma rubrica clara que um colega consiga ler e aplicar sem planilha. Se você não consegue explicar por que um cadastro obteve 72 em vez de 28, você não vai confiar nela quando for importante.

Lance alguns sinais que você entenda, então ajuste só depois de ter resultados reais (bounces, chargebacks, denúncias de abuso, ativações bem‑sucedidas). Mantenha ações simples para que sejam fáceis de operar:

• Baixo risco: permitir cadastro normalmente
• Risco médio: adicionar fricção leve (verificação por e‑mail ou CAPTCHA)
• Alto risco: exigir prova mais forte, limitar ações ou enviar para revisão

A implementação fica mais fácil quando os sinais centrais chegam num único lugar. Por exemplo, Verimail (verimail.co) fornece uma API de validação de e‑mail que retorna checagens como validação de sintaxe compatível com RFC, verificação de domínio, lookup de MX e correspondência com descartáveis e blocklists em uma única resposta. Use esses resultados como entradas para sua rubrica, mas mantenha as regras de decisão na sua aplicação para que continuem fáceis de explicar e alterar.

Depois de ativo, meça como um recurso de produto. Logue a pontuação, a faixa, a ação tomada e o resultado observado depois. Reveja uma pequena amostra de falsos positivos (bloqueados mas legítimos) e falsos negativos (permitidos mas prejudiciais), então ajuste uma regra por vez. A versão mais simples que você monitora e atualiza vence um modelo complexo que ninguém consegue explicar.