Como bloquear e-mails descartáveis no formulário de cadastro

Para bloquear e-mails descartáveis no cadastro, rejeite o domínio se ele estiver numa lista mantida de domínios descartáveis, depois consulte os registros MX e rejeite se o e-mail for tratado por um servidor que só atende caixas temporárias. No nosso teste de 1º de outubro de 2026, essa checagem de MX pegou 420 de 445 domínios descartáveis recém-listados que uma lista desatualizada deixou passar.

A maioria dos guias para em "use uma blocklist". As perguntas interessantes são com que rapidez uma lista fica desatualizada, o que cobre essa lacuna e como evitar bloquear pessoas reais no caminho. Medimos as três coisas.

Por que uma lista de domínios sozinha não basta

Uma lista de domínios descartáveis fica para trás no mesmo dia em que você a copia. Serviços descartáveis registram domínios novos o tempo todo, e cada um funciona até alguém incluí-lo numa lista.

A lista do SimpleVerifier, com 8.740 domínios descartáveis, era uma cópia da lista open source disposable-email-domains feita no começo de setembro de 2026. Comparamos com a versão atual dessa mesma lista, baixada em 1º de outubro de 2026. Em menos de um mês, a lista atual tinha ganhado 457 domínios que nossa cópia não tinha, e removido um que nossa cópia ainda trazia. Qualquer formulário usando a cópia antiga teria deixado passar todos os 457.

A lista também se deteriora no sentido contrário. Resolvemos os registros MX dos 8.740 domínios:

Resultado	Domínios	Parcela
Tem registros MX	5.789	66,2%
MX nulo (não aceita e-mail, RFC 7505)	134	1,5%
Domínio não existe (NXDOMAIN)	1.869	21,4%
Existe, sem registro MX	838	9,6%
Falha ou timeout do servidor DNS	110	1,3%

Mais de um quinto dos domínios não existe mais. Bloqueá-los não custa nada, já que ninguém pode receber e-mail ali. Mas isso mostra a rotatividade: os serviços abandonam domínios e registram novos, e uma lista sempre descreve o passado.

O que uma checagem de MX acrescenta

Serviços descartáveis operam centenas de domínios em um punhado de servidores de e-mail. Veja para onde vai o e-mail de um domínio novo e você consegue reconhecer o serviço mesmo sem nunca ter visto o domínio.

Entre os 5.789 domínios listados com registros MX funcionando havia 1.246 servidores de e-mail principais distintos, e eles são muito concentrados:

Os N principais hosts MX	Domínios atendidos	Parcela dos domínios listados com MX
10	2.719	47,0%
25	3.636	62,8%
50	4.153	71,7%
100	4.503	77,8%

O host mais carregado, email.chatgpt.org.uk, é o MX principal de 470 domínios listados. generator.email, tinyhost.shop e emailfake.com atendem centenas de outros cada um.

Depois testamos se esse conhecimento vale para domínios que uma lista ainda não pegou. Resolvemos os MX dos 457 domínios que estavam na lista open source mas faltavam na nossa. 445 tinham registros MX. Desses, 420 usavam pelo menos um servidor de e-mail que já atendia algum domínio da nossa lista antiga, excluindo provedores de uso geral (veja a próxima seção). Os outros 25 usavam servidores que nunca tínhamos visto ou só provedores compartilhados.

Em outras palavras, se o formulário tivesse checado os hosts MX além dos nomes de domínio, a lista desatualizada teria pegado mesmo assim 420 dos 445 domínios novos com e-mail funcionando (94%). Os domínios novos eram em sua maioria nomes recentes nos mesmos servidores de sempre.

O método, para você repetir: as consultas foram feitas com dnspython 2.8.0 contra 1.1.1.1 e 8.8.8.8, com timeout de 6 segundos, em 1º de outubro de 2026. Os hosts MX de cada domínio foram registrados; um domínio contava como correspondência se algum dos seus hosts MX aparecesse entre os hosts MX dos nossos 8.740 domínios listados, depois de excluir os provedores compartilhados listados abaixo.

A armadilha dos falsos positivos: infraestrutura de e-mail compartilhada

Nunca bloqueie por um host MX que também atenda empresas comuns. Essa única regra separa uma checagem de MX útil de uma que rejeita seus melhores clientes.

567 dos 5.789 domínios listados com MX (9,8%) roteiam e-mail por infraestrutura de uso geral:

Provedor (o hostname do MX contém)	Domínios descartáveis listados que o usam
cloudflare.net (Cloudflare Email Routing)	290
google.com (Google Workspace / Gmail)	88
above.com (estacionamento de domínios)	57
mailgun.org	50
registrar-servers (encaminhamento da Namecheap)	32
outlook.com (Microsoft 365)	17
zoho	13
secureserver (GoDaddy)	10
improvmx	7
forwardemail	3

Se você incluísse aspmx.l.google.com num conjunto de MX descartáveis porque 51 domínios descartáveis o usam, bloquearia todas as empresas no Google Workspace. O mesmo vale para os servidores de roteamento do Cloudflare. Esses 567 domínios só podem ser pegos pelo nome, e é por isso que a lista continua sendo a primeira camada.

As outras fontes de falsos positivos que vale considerar no projeto:

• Relays de privacidade não são descartáveis. Endereços do Ocultar Meu E-mail da Apple, Firefox Relay e DuckDuckGo encaminham para uma caixa real e duradoura. Nem privaterelay.appleid.com, nem mozmail.com, nem duck.com estão na lista open source ou na nossa. Trate-os como usuários reais com uma preferência de privacidade.
• Domínios mortos são registrados de novo. 1.869 domínios listados não existem atualmente. Se uma empresa legítima comprar um deles depois, uma lista que nunca remove entradas vai bloquear os funcionários dela. Os próprios mantenedores da lista open source dizem isso: eles não podem garantir que todos ainda possam ser considerados descartáveis, apenas que foram descartáveis em algum momento. (Tradução livre do original em inglês.)
• Não ter MX não é o mesmo que não ter e-mail. Pela RFC 5321, um domínio sem registro MX recorre ao registro A. Rejeitar todo domínio sem MX bloqueia um pequeno número de configurações reais. Rejeite por NXDOMAIN e por MX nulo, que não deixam dúvida.
• Subdomínios de um domínio listado. Alguns serviços distribuem anything.service.tld. Compare o domínio e cada domínio pai com a lista, não só a string exata.

Uma implementação funcional em Node.js

Esta é a ordem que recomendamos: consulta à lista (sem rede), depois uma consulta de MX com timeout curto, depois uma decisão. Em caso de erro de DNS, o código deixa passar, para que uma queda do seu resolvedor nunca impeça cadastros reais.

import { promises as dns } from "node:dns";
import { readFileSync } from "node:fs";

const BLOCKLIST = new Set(
  readFileSync("disposable_domains.txt", "utf8").split("\n").map((d) => d.trim().toLowerCase()).filter(Boolean)
);

// MX hosts that only serve throwaway inboxes. Never put Google, Microsoft,
// Cloudflare or Mailgun here: they host millions of real domains too.
const DISPOSABLE_MX = new Set([
  "email.chatgpt.org.uk", "generator.email", "emailfake.com",
  "tinyhost.shop", "mail.wabblywabble.com", "mail.mailinator.com",
]);

function onBlocklist(domain) {
  const labels = domain.split(".");
  for (let i = 0; i < labels.length - 1; i++) {
    if (BLOCKLIST.has(labels.slice(i).join("."))) return true;
  }
  return false;
}

async function withTimeout(promise, ms) {
  let timer;
  const timeout = new Promise((_, reject) => { timer = setTimeout(() => reject(new Error("ETIMEOUT")), ms); });
  try { return await Promise.race([promise, timeout]); } finally { clearTimeout(timer); }
}

export async function checkSignupDomain(email) {
  const domain = email.split("@").pop().trim().toLowerCase();
  if (onBlocklist(domain)) return { verdict: "block", reason: "domain on disposable list" };

  let records;
  try {
    records = await withTimeout(dns.resolveMx(domain), 3000);
  } catch (err) {
    if (err.code === "ENOTFOUND") return { verdict: "block", reason: "domain does not exist" };
    if (err.code === "ENODATA") {
      // RFC 5321 section 5.1: no MX means mail falls back to the A record.
      const hasA = await withTimeout(dns.resolve4(domain), 3000).then(() => true, () => false);
      return hasA
        ? { verdict: "allow", reason: "no MX, but A record (implicit MX)" }
        : { verdict: "block", reason: "domain cannot receive mail" };
    }
    return { verdict: "allow", reason: "DNS unavailable, failing open" };
  }

  const hosts = records.map((r) => r.exchange.toLowerCase().replace(/\.$/, ""));
  if (hosts.length === 0 || hosts.every((h) => h === "")) {
    return { verdict: "block", reason: "null MX: domain accepts no mail" };
  }
  if (hosts.some((h) => DISPOSABLE_MX.has(h))) {
    return { verdict: "block", reason: `MX ${hosts[0]} serves disposable inboxes` };
  }
  return { verdict: "allow", reason: "no disposable signal" };
}

for (const email of process.argv.slice(2)) {
  console.log(email, await checkSignupDomain(email));
}

Salve como check.mjs ao lado de um arquivo disposable_domains.txt (um domínio por linha) e rode no Node 18 ou mais recente. Nossa saída em 1º de outubro de 2026:

$ node check.mjs a@mailinator.com x@foo.mailinator.com a@247chats.com b@gmail.com d@example.com f@github.io
a@mailinator.com { verdict: 'block', reason: 'domain on disposable list' }
x@foo.mailinator.com { verdict: 'block', reason: 'domain on disposable list' }
a@247chats.com { verdict: 'block', reason: 'MX generator.email serves disposable inboxes' }
b@gmail.com { verdict: 'allow', reason: 'no disposable signal' }
d@example.com { verdict: 'block', reason: 'null MX: domain accepts no mail' }
f@github.io { verdict: 'allow', reason: 'no MX, but A record (implicit MX)' }

247chats.com é um dos 457 domínios que faltavam na nossa lista antiga. A checagem por nome deixou passar; a checagem de MX, não.

Duas observações para rodar isso em produção. Atualize a lista de domínios de forma agendada em vez de comitá-la uma única vez, e mantenha DISPOSABLE_MX curta e selecionada à mão: inclua um host só quando todos os domínios que você viu nele forem descartáveis.

O que mostrar ao usuário

Diga claramente que você precisa de um endereço que a pessoa vá manter, e deixe que ela tente de novo. Um cadastro bloqueado com um erro vago parece um formulário quebrado.

Algo como: "Não aceitamos endereços de e-mail temporários. Use um endereço que você ainda vai ter no mês que vem." Não revele qual lista ou checagem deu correspondência; isso só ajuda alguém a trocar para o próximo domínio.

Faça a checagem no servidor. Uma cópia no cliente serve como dica enquanto a pessoa digita, mas qualquer um pode contorná-la, e mandar uma lista de 8.000 linhas para todo navegador aumenta o peso da página sem ganho de segurança.

Onde isso se encaixa no resto

Bloquear descartáveis é uma camada, não uma defesa de cadastro completa:

• Erros de digitação como gmial.com são outro problema, com outra solução (sugerir, não bloquear). Veja como pegar erros de digitação no cadastro.
• Endereços com sinal de mais e pontos do Gmail permitem que uma única caixa real crie várias contas. Isso é questão de normalização, não de descartáveis: endereços com sinal de mais e abuso de teste grátis.
• Bots preenchendo o formulário em escala exigem limites de taxa e um desafio: como barrar cadastros falsos sem prejudicar usuários reais.
• Saber se a caixa postal existe exige uma checagem SMTP, que o DNS não responde. Veja como checar um endereço sem enviar nada.

Você pode checar um domínio à mão com o nosso verificador de e-mail descartável ou ver os servidores de e-mail dele com a ferramenta de consulta MX.

A versão curta

1. Compare o domínio, e cada domínio pai, com uma lista de descartáveis atualizada automaticamente.
2. Consulte o MX. Bloqueie NXDOMAIN e MX nulo. Não bloqueie "sem MX" sem checar o registro A.
3. Bloqueie hosts MX que só atendem caixas temporárias. Nunca bloqueie provedores compartilhados como Google, Microsoft ou Cloudflare.
4. Em erro de DNS, deixe passar, e dê ao usuário uma mensagem clara e uma segunda chance.

A lista pega os serviços que todo mundo conhece. A checagem de MX pega os domínios que eles registraram na semana passada.