Os endereços de e-mail descartáveis existem por um motivo legítimo — as pessoas não querem entregar uma identidade permanente a cada formulário da internet — e criam um problema operacional real para quem mantém uma base de contatos. Este guia explica o que são os provedores de e-mail descartável, como a detecção funciona na prática, por que manter uma lista estática é o mais frágil dos métodos disponíveis e como montar uma abordagem de detecção que continua funcionando conforme novos provedores surgem.
TL;DR / PRINCIPAIS PONTOS
- Um endereço descartável é uma caixa postal real e entregável, com vida curta. Ele costuma passar na verificação de sintaxe, na checagem de MX e na verificação por SMTP — por isso a validação genérica de e-mail não o detecta.
- Listas de domínios ficam desatualizadas rápido. Os provedores rotacionam centenas ou milhares de domínios alias, e qualquer lista mantida manualmente fica obsoleta em poucas semanas.
- O registro MX é o sinal mais durável. Os domínios alias mudam o tempo todo; os servidores de e-mail por trás deles mudam com muito menos frequência, então classificar pelo MX captura domínios que ainda não constam em lista nenhuma.
- Listas open source são o ponto de partida certo, não a linha de chegada: repositórios mantidos pela comunidade oferecem ampla cobertura de graça e são atualizados continuamente.
- Bloquear é uma decisão de produto, não de dados. Bloquear domínios descartáveis no cadastro também barra usuários legítimos preocupados com privacidade. Pontuar e condicionar costuma ser melhor do que rejeitar.
- Onde os dados de zona ajudam: os pacotes de zona enriquecidos trazem o registro MX de cada domínio, o que permite encontrar todos os domínios de um TLD que compartilham infraestrutura de e-mail com um provedor descartável conhecido.
- O que os pacotes contêm: O formato do download varia conforme o pacote e é informado na página do produto. Nenhum endereço de e-mail e nenhum dado pessoal de contato de qualquer tipo.
Índice
- O que são provedores de e-mail descartável e por que as listas envelhecem
- Métodos de detecção, ordenados por quanto tempo continuam funcionando
- Uma lista inicial de provedores conhecidos
- Montando um conjunto de detecção baseado em MX a partir de dados de zona
- Erros comuns na validação de e-mail
- Perguntas frequentes
- Conclusão
- Recursos relacionados
O que são provedores de e-mail descartável e por que as listas envelhecem
Um endereço de e-mail descartável — também chamado de temporário ou burner — é uma caixa postal que um serviço cria sob demanda, normalmente sem cadastro, e descarta depois de minutos ou dias. O usuário recebe uma caixa de entrada no navegador, recebe o e-mail de confirmação e nunca mais volta. Alguns provedores oferecem caixas públicas, em que qualquer endereço do domínio pode ser lido por quem adivinhar o nome; outros geram aliases privados que encaminham para uma caixa postal real que o destinatário já possui.
O detalhe crítico para quem escreve código de validação é que essas são caixas postais reais e funcionais. O domínio tem registros MX válidos, o servidor de e-mail aceita mensagens para o endereço e o handshake de verificação por SMTP é bem-sucedido. A validação de sintaxe passa, a validação de DNS passa e a checagem de existência da caixa postal passa. Nada no conjunto padrão de validação distingue um endereço descartável de um permanente, porque, no nível do protocolo, não há diferença. A detecção, portanto, consiste em identificar o provedor, não em testar o endereço.
É aí que mora a dificuldade. Um único serviço de e-mail descartável costuma operar de dezenas a milhares de domínios alias, que existem justamente para que o bloqueio por domínio não funcione. Os domínios rodam em rodízio, são aposentados quando caem em listas de bloqueio públicas e são substituídos por outros recém-registrados. Uma lista compilada à mão há três meses já não tem os domínios registrados desde então — e os provedores sabem exatamente como essas listas são compiladas.
Também vale ser preciso quanto à dimensão do problema, em vez de repetir um percentual dramático. A prevalência de endereços descartáveis varia enormemente conforme o produto: um app de consumo que oferece uma recompensa imediata no cadastro tem uma taxa completamente diferente da de uma ferramenta B2B que exige e-mail corporativo e uma demo agendada. Meça a sua própria taxa antes de desenhar uma resposta a ela. Qualquer número citado sem fonte e sem metodologia — inclusive em artigos sobre o tema — deve ser tratado como enfeite.
Precisa de dados de MX de um TLD inteiro?
Os pacotes de zona enriquecidos incluem o registro MX de cada domínio da zona.
Ver datasets → | Ver preços →
Métodos de detecção, ordenados por quanto tempo continuam funcionando
As abordagens de detecção variam bastante em quão bem sobrevivem ao contato com um provedor que está ativamente tentando escapar delas. Grosso modo, em ordem de durabilidade:
1. Classificação por MX (a mais durável)
Domínios alias são baratos e descartáveis; infraestrutura de e-mail não é. Um provedor com dois mil domínios geralmente aponta todos eles para o mesmo punhado de servidores de e-mail. Resolva o registro MX do domínio do e-mail e compare o host de correio com a infraestrutura conhecida de provedores descartáveis: você captura domínios registrados hoje de manhã que não aparecem em lista alguma.
Esse é o método que mais vale a pena desenvolver, e é o que os dados de zona enriquecidos sustentam diretamente, já que o MX é uma coluna do arquivo. O processo de construção está descrito na próxima seção.
2. Listas open source mantidas pela comunidade
Vários repositórios públicos acompanham domínios descartáveis e aceitam contribuições contínuas — o projeto disposable-email-domains, bastante usado, é o ponto de partida habitual, e a maioria dos validadores comerciais parte de fontes semelhantes. A cobertura é ampla, o custo é zero e atualizar é um git pull. A fraqueza é intrínseca: uma lista está sempre atrás dos domínios mais novos, e um domínio que deixou de ser descartável raramente é removido.
Use uma delas como linha de base e espere que capture a cauda longa dos provedores conhecidos, não os recém-criados.
3. APIs comerciais de validação
Os validadores pagos combinam correspondência com listas, classificação por MX, sondagem SMTP e sinais comportamentais do tráfego de toda a sua base de clientes — esse último insumo é o que você não consegue replicar. São a escolha pragmática para barrar cadastros em tempo real, quando você precisa de resposta em cem milissegundos e não quer manter o pipeline. O custo escala por checagem e a classificação de cada fornecedor difere nas margens, então teste dois sobre a mesma amostra antes de fechar.
4. Heurísticas de registro e infraestrutura
Fracas isoladamente, úteis em conjunto. Um domínio registrado há poucos dias, que resolve para uma rede de hospedagem cheia de sites efêmeros, sem conteúdo web e com name servers genéricos, tem mais chance de ser infraestrutura descartável do que um domínio de quinze anos com um site real por trás. Trate esses fatores como insumos de uma pontuação, nunca como regra de rejeição isolada — todo negócio novo e legítimo também tem um domínio registrado há poucos dias.
5. Listas de bloqueio de domínios estáticas mantidas à mão (a menos durável)
A abordagem padrão e a que falha mais rápido. Algo é acrescentado quando um colega percebe um bounce; nada nunca é removido; ninguém é dono do arquivo. Em poucos meses, é uma peça histórica, não um controle. Se essa é a sua abordagem atual, substituí-la por uma lista open source atualizada automaticamente é a mudança de maior valor disponível.
Uma observação sobre o que fazer com um resultado positivo
Detecção e política são decisões separadas. Bloquear todo domínio descartável no cadastro também afasta usuários preocupados com privacidade que teriam convertido — e há muitos deles. Meios-termos comuns: permitir o cadastro, mas reter ações irreversíveis até que um endereço seja confirmado; exigir verificação antes de estender um trial; deixar passar cadastros com domínio descartável, mas excluí-los de campanhas pagas de reengajamento. Para listas de prospecção B2B a conta é mais simples — um endereço descartável vai gerar bounce ou nunca ser lido, então removê-lo antes do envio protege a entregabilidade sem nenhuma desvantagem real.
Uma lista inicial de provedores conhecidos
Estes são serviços de e-mail descartável antigos e amplamente conhecidos. É um ponto de partida para testar sua lógica de detecção, não uma lista de bloqueio completa — cada um deles opera domínios alias adicionais, e novos provedores surgem continuamente.
| Provedor | Modelo | Nota de detecção |
|---|---|---|
| Mailinator | Caixa pública, qualquer endereço do domínio | Muitos domínios alias, infraestrutura de MX compartilhada |
| Guerrilla Mail | Caixa temporária, por sessão | Vários domínios em rodízio, incluindo sharklasers.com |
| 10 Minute Mail | Caixa com expiração automática | Domínios de vida curta, hosts de correio consistentes |
| YOPmail | Caixa pública, sem cadastro | Grande conjunto de domínios alias publicado |
| Temp-Mail | Caixa temporária com domínios em rodízio | O conjunto de domínios muda com frequência; o MX é bem mais estável |
| Maildrop | Caixa pública | Poucos domínios, fácil de identificar |
| Dispostable | Caixa pública | Domínio principal estável |
| Serviços de alias com encaminhamento | Alias privado que encaminha para uma caixa postal real | Entregável e muitas vezes permanente — classifique à parte |
Essa última linha importa mais do que parece. Os serviços de alias com encaminhamento são muito usados por pessoas preocupadas com privacidade que realmente querem receber a mensagem, e o endereço costuma continuar funcionando por anos. Colocá-los no mesmo balde das caixas públicas descartáveis vai custar usuários reais. Dê a eles uma categoria própria e uma política própria.
Montando um conjunto de detecção baseado em MX a partir de dados de zona
O objetivo é uma lista de hosts de correio associados a provedores descartáveis, mais todos os domínios de uma zona que apontam para eles. Esse conjunto é bem mais durável que uma lista de domínios, porque sobrevive ao rodízio de aliases.
Passo 1 — Obtenha dados de MX das zonas que lhe interessam. Os pacotes de zona enriquecidos incluem o registro MX de cada domínio. Navegue por /zones/ para ver os arquivos de zona de 716 TLDs e suas versões enriquecidas, com a contagem de linhas exibida antes da compra, e por /datasets/ para as 27 coleções curadas entre zonas. O catálogo completo de 1.538 pacotes está em /packages/. Os pacotes começam em $3.50 e o download é imediato, em ZIP, exportado na hora da compra. O plano Pro custa $29/mês (50 pacotes, 10 datasets, 30.000 chamadas de API); o Enterprise, $99/mês (200 pacotes, 50 datasets, 300.000 chamadas de API) — veja /pricing/.
Passo 2 — Descompacte e confira o schema.
unzip com-enriched.zip
head -3 com-enriched.csv
# domain,ns,mx,ip,cms
Passo 3 — Comece pelos domínios de provedores conhecidos. Parta de uma lista open source de domínios descartáveis e da tabela acima, e coloque os domínios em um arquivo:
curl -sL https://raw.githubusercontent.com/disposable-email-domains/disposable-email-domains/master/disposable_email_blocklist.conf \
> seed-domains.txt
wc -l seed-domains.txt
Passo 4 — Extraia os hosts de correio usados por esses domínios. Cruze a lista inicial com o arquivo de zona para coletar os valores de MX, que se tornam a sua impressão digital de infraestrutura:
-- mail hosts used by known disposable domains, most common first
SELECT z.mx, count(*) AS domains
FROM read_csv_auto('com-enriched.csv') z
JOIN read_csv_auto('seed-domains.txt', header=false, columns={'domain':'VARCHAR'}) s
ON z.domain = s.domain
WHERE z.mx IS NOT NULL AND z.mx <> ''
GROUP BY z.mx
ORDER BY domains DESC;
Passo 5 — Expanda de volta para todos os domínios que compartilham essa infraestrutura. É este o passo que encontra o que nenhuma lista tem ainda:
-- all domains in the zone pointing at a known disposable mail host
SELECT domain, mx
FROM read_csv_auto('com-enriched.csv')
WHERE mx IN (SELECT mx FROM disposable_mx_hosts);
Passo 6 — Revise antes de colocar em produção. Não publique o resultado sem examinar. Alguns hosts de correio atendem tanto domínios descartáveis quanto legítimos, e uma plataforma compartilhada vai gerar falsos positivos que custam cadastros reais. Ordene o resultado por host de MX, inspecione os maiores grupos por amostragem e promova um host à lista de bloqueio apenas quando seus domínios forem consistentemente descartáveis.
Passo 7 — Atualize com periodicidade. Compre o mesmo pacote novamente de tempos em tempos e rode o pipeline outra vez. Novos domínios alias surgem apontando para hosts de correio que você já conhece, e comparar snapshots revela esses domínios sem nenhum trabalho manual.
# list zone-file packages
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://webtrackly.com/api/v1/packages/?type=zone"
# technology packages matching a keyword
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"
# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://webtrackly.com/api/v1/packages/com-zone/"
A API expõe o catálogo de pacotes, então isso pode rodar sem supervisão; a referência está em /api/. Não é um endpoint de validação de e-mail nem um serviço de consulta de domínios — a lógica de classificação permanece no seu pipeline, onde você pode ajustá-la.
Erros comuns na validação de e-mail
-
Depender de uma lista de domínios mantida à mão.
- O que dá errado: A detecção se degrada silenciosamente conforme os provedores trocam de domínio, e ninguém percebe até a taxa de bounce subir.
- A solução: Automatize as atualizações a partir de uma lista open source mantida ativamente e acrescente a classificação por MX, para que novos domínios alias sejam capturados no primeiro contato.
-
Tratar a verificação por SMTP como detecção de descartáveis.
- O que dá errado: O handshake é bem-sucedido — a caixa postal realmente existe — e o endereço é marcado como válido.
- A solução: Reconheça que entregabilidade e permanência são propriedades diferentes. A sondagem SMTP agressiva ainda coloca o seu IP em greylist, o que é um segundo custo sem nenhum benefício.
-
Bloquear domínios descartáveis de forma absoluta no cadastro.
- O que dá errado: Usuários legítimos preocupados com privacidade são afastados, e os abusadores determinados simplesmente usam o próximo domínio.
- A solução: Pontue em vez de rejeitar. Condicione as ações que de fato custam caro — operações irreversíveis, extensões de trial, envios de saída — em vez da conta em si.
-
Confundir webmail gratuito com e-mail descartável.
- O que dá errado: Grandes provedores de e-mail de consumo caem na lista de bloqueio e uma parcela enorme de clientes reais é rejeitada.
- A solução: Mantenha três categorias distintas — descartável, webmail gratuito de consumo e corporativo — com três políticas distintas. Um endereço de consumo pode ser um sinal B2B fraco, mas não é um sinal falso.
-
Tratar domínios catch-all como válidos.
- O que dá errado: Um servidor catch-all aceita mensagens para qualquer endereço, então a verificação retorna "válido" para endereços que não existem e a mensagem é descartada silenciosamente.
- A solução: Marque catch-all à parte, como "não verificável", e defina a política explicitamente, em vez de deixá-lo escondido dentro da contagem de válidos.
-
Validar uma vez e nunca mais.
- O que dá errado: Endereços se deterioram — pessoas mudam de emprego, domínios expiram, caixas postais são encerradas — e uma lista validada há um ano não é uma lista validada.
- A solução: Revalide antes de qualquer envio grande e trate a recência do engajamento como um sinal de primeira classe, ao lado da validade sintática.
-
Citar uma taxa de prevalência que você não mediu.
- O que dá errado: Um número tirado de um artigo orienta uma decisão de política, e a sua taxa real acaba sendo uma ordem de grandeza diferente.
- A solução: Instrumente o seu próprio fluxo de cadastro, classifique uma amostra real e desenhe a resposta em torno da taxa que você mediu.
Perguntas frequentes
P: O que é um endereço de e-mail descartável?
R: Uma caixa postal criada sob demanda, normalmente sem cadastro, e descartada depois de minutos ou dias. É um endereço real e entregável — por isso as checagens de sintaxe, DNS e SMTP passam todas.
P: Por que a validação de e-mail padrão não os detecta?
R: Porque, no nível do protocolo, não há nada a detectar. O domínio tem MX válido, o servidor aceita a mensagem, a caixa postal existe. A detecção precisa identificar o provedor, não testar o endereço.
P: Uma lista pública de domínios descartáveis é suficiente?
R: Como linha de base, sim; como solução completa, não. Os provedores operam grandes conjuntos rotativos de domínios alias justamente para derrotar o bloqueio por domínio. Combine a correspondência por lista com a classificação por MX.
P: Por que o registro MX é um sinal melhor que o domínio?
R: Domínios alias são baratos e mudam constantemente. A infraestrutura de e-mail por trás deles muda muito mais devagar, então classificar pelo host de correio captura domínios que ainda não constam em lista nenhuma.
P: Devo bloquear endereços descartáveis no cadastro?
R: Depende do seu produto. Bloquear também afasta usuários legítimos preocupados com privacidade. Condicionar ações caras ou irreversíveis a uma verificação costuma ser uma troca melhor do que rejeitar a conta. Para listas de e-mail de saída, removê-los antes do envio é simplesmente correto.
P: A WebTrackly valida endereços de e-mail?
R: Não. A WebTrackly distribui dados de domínio em massa como arquivos para download. Os pacotes de zona enriquecidos incluem registros MX, que são o insumo para montar a detecção baseada em MX; a lógica de validação em si fica no seu próprio pipeline ou com um fornecedor de validação.
P: Os pacotes contêm endereços de e-mail?
R: Não. Os arquivos contêm domínio, name servers, MX, IP resolvido e CMS detectado. Não há endereços de e-mail, telefones nem dados pessoais de contato em nenhum pacote.
P: Qual é o tamanho do catálogo?
R: 1.538 pacotes — 716 arquivos de zona, 716 conjuntos de zona enriquecidos, 79 listas de sites por tecnologia e 27 datasets curados — cobrindo 285.582.781 domínios nos pacotes de zona, dos quais 163.422.083 são .com. O dataset de todos os domínios registrados tem 272.614.863 linhas.
P: Como mantenho os dados atualizados?
R: Cada pacote é exportado no momento da compra. Compre o mesmo pacote de novo mais tarde e compare os dois arquivos para ver quais domínios são novos.
P: O que a API faz?
R: Ela expõe o catálogo. GET /api/v1/packages/?type=zone lista os pacotes de zona, ?type=technology&q=wordpress filtra pacotes de tecnologia e /api/v1/packages/{slug}/ retorna os detalhes do pacote, com autenticação por bearer token.
Conclusão
A detecção de e-mails descartáveis é um problema de manutenção, não de consulta. Os provedores trocam de domínio mais rápido do que qualquer lista consegue absorver, então a pergunta não é qual lista baixar, e sim qual sinal continua funcionando quando os domínios mudam. Esse sinal é a infraestrutura de e-mail: os domínios alias são descartáveis por concepção, os servidores por trás deles não.
Uma stack que funciona é feita em camadas — uma lista open source atualizada automaticamente para amplitude, classificação por MX para os domínios que a lista ainda não viu e um fornecedor de validação onde você precisa de uma resposta em tempo real no cadastro. Alimente tudo isso com a taxa de prevalência que você mediu, não com um número tirado de um artigo, mantenha os serviços de alias com encaminhamento em uma categoria própria e pontue em vez de rejeitar. Se quiser construir a camada de MX por conta própria, os pacotes de zona enriquecidos trazem o registro MX de cada domínio da zona — exatamente o insumo que esse passo exige.
Explore o catálogo de datasets →
Recursos relacionados
- Catálogo de pacotes — 1.538 bases de domínios para download
- Arquivos de zona por TLD — .com, .net, .de e mais de 700
- Datasets curados — todos os domínios registrados, servidores MX, e-commerce
- Documentação da API — acesso ao catálogo com bearer token
- Preços — compras avulsas a partir de $3.50