A resposta curta#
Um domínio catch-all — também chamado de domínio accept-all — é configurado para
aceitar mensagens para qualquer endereço naquele domínio, real ou não. Quando uma
ferramenta de verificação pergunta ao servidor de e-mail se uma caixa postal
específica existe, um servidor catch-all diz sim para tudo, então a resposta não
carrega informação alguma. O endereço pode até ser entregável, mas nenhuma
ferramenta consegue confirmar isso sem de fato enviar a mensagem.
A Qualisend reporta esses endereços como risky com o motivo
low_deliverability e uma sinalização de catch-all — nunca como "válido".
Essa última frase é toda a posição editorial deste guia: uma caixa postal por trás de um domínio catch-all é inconfirmável, e qualquer produto ou artigo que lhe diga o contrário está escolhendo um rótulo lisonjeiro para a mesma incerteza.
Como a detecção de catch-all realmente funciona#
A detecção de catch-all é a etapa 7 do pipeline de verificação, um teste no nível do domínio, e a técnica é refrescantemente pouco sofisticada. Junto com o endereço sobre o qual você perguntou, o verificador sonda uma caixa postal deliberadamente absurda no mesmo domínio — uma sequência de caracteres que ninguém jamais registraria. Se o servidor aceitar isso também, o domínio aceita tudo, e nenhuma resposta por caixa postal daquele servidor pode ser confiável.
Aqui está a parte relevante da conversa SMTP contra um domínio normal, em que o servidor de fato consulta sua lista de caixas postais:
> RCPT TO:<jane@example.com>
< 250 2.1.5 OK
> RCPT TO:<x9f2kq77c@example.com>
< 550 5.1.1 The email account that you tried to reach does not exist
O 550 para o endereço sem sentido é o que torna o 250 para jane@
significativo: esse servidor rejeita caixas postais desconhecidas, então uma aceitação é uma resposta
de verdade.
Agora a mesma sondagem contra um domínio catch-all:
> RCPT TO:<jane@example.com>
< 250 2.1.5 OK
> RCPT TO:<x9f2kq77c@example.com>
< 250 2.1.5 OK
Ambos retornam 250. O servidor disse sim a um endereço que não pode existir, então
seu sim para jane@ não prova nada. jane@example.com pode ser uma caixa postal real e ativa
— ou um erro de digitação que vai gerar bounce assim que você enviar uma campanha para ele.
De fora, no momento da verificação, os dois são indistinguíveis.
Por que a própria detecção pode ser inconclusiva#
Na prática, o quadro é mais confuso do que duas transcrições limpas. Servidores de e-mail
são ativamente hostis a estranhos fazendo perguntas: eles aplicam
greylisting a remetentes desconhecidos com adiamentos temporários
4xx, limitam a taxa de sondagens repetidas do mesmo IP, respondem lentamente
de propósito (tarpitting) ou derrubam a conexão no meio da conversa. Gateways corporativos de filtragem adicionam seu próprio comportamento — muitos
aceitam tudo no limite do SMTP e só avaliam o destinatário
depois, o que os faz parecer catch-all de fora, independentemente do
que as caixas postais por trás deles diriam.
Disso decorrem duas consequências. Primeira, o mesmo endereço pode produzir vereditos
diferentes em dias diferentes, porque foi o humor do servidor que mudou, não a
caixa postal. Segunda, um verificador honesto precisa de um veredito unknown (com motivos
como timeout ou unavailable_smtp) para as conversas que nunca chegaram
a uma resposta conclusiva, e deve tratar unknown como "tentar de novo mais tarde" em vez de
silenciosamente arquivá-lo como válido ou inválido. Uma ferramenta que nunca diz "unknown" não é
mais precisa — é menos honesta sobre a mesma realidade da rede.
Por que as ferramentas de verificação divergem sobre catch-alls#
Passe a mesma lista B2B por vários verificadores e você verá a discordância silenciosa do setor: uma ferramenta marca um endereço como "válido", outra o chama de catch-all, uma terceira lhe dá uma pontuação opaca de 87 sem nenhuma explicação. Todas estão olhando para o mesmo comportamento de SMTP. O que difere é o que cada uma se dispõe a afirmar sobre ele.
O problema de incentivo é simples: "válido" vende melhor do que "não temos como saber". Um verificador que reporta 95% da sua lista como entregável parece mais preciso do que um que reporta 70% entregável e 25% risky — até o exato momento em que a campanha sai e os bounces chegam. Alguns fornecedores apostam nisso com alegações de "resolução de catch-all" ou confiança pontuada por IA que silenciosamente arredonda endereços inconfirmáveis para enviáveis.
Testes de terceiros já documentaram esse modo de falha diretamente. Em uma comparação prática de 2026 que rodou 127.000 verificações em listas B2B, três das sete ferramentas testadas marcaram entre 15 e 42 endereços catch-all conhecidos como "válidos" — endereços que os testadores tinham semeado especificamente como inconfirmáveis. Uma ressalva que aplicaríamos a qualquer fonte desse tipo, inclusive as que nos elogiam: testes comparativos costumam ser publicados por empresas com algo a vender (esse vem de um fornecedor de automação de vendas), então leia-os pelas tabelas brutas por categoria e pela metodologia, não pelos rankings.
O jogo de esconde-esconde das pontuações#
Fique atento à pontuação de confiança opaca. Um "87/100" cru sobre um endereço catch-all parece precisão, mas responde a uma pergunta que ninguém fez. A pergunta que importa — essa caixa postal existe? — tem uma resposta conhecida para um domínio catch-all: inconfirmável. Embrulhar isso em um número de dois dígitos não acrescenta informação; esconde a categoria do problema. Uma pontuação só é útil quando você consegue ver o que a produziu, e é por isso que todo veredito da Qualisend expõe seus insumos: o status, o código do motivo, as sub-sinalizações, o provedor de MX do domínio e o que a conversa SMTP de fato retornou. Evidência que você pode ler vence um número em que você tem de confiar.
A posição da Qualisend é a entediante: um endereço catch-all é reportado como
risky com o motivo low_deliverability, a sinalização de catch-all ativada e uma
pontuação de confiança intermediária — nunca arredondada para cima como entregável. Todo veredito
vem acompanhado de sua evidência — o provedor de MX do domínio e o detalhe da sondagem — para que
você possa ver por que o veredito é o que é, em vez de confiar em um número cru.
Você pode comparar como nós e outros fornecedores lidamos com catch-alls em nossas páginas
de comparação, por exemplo Qualisend vs ZeroBounce e
Qualisend vs NeverBounce.
Competitor behavior referenced on our comparison pages was last verified July 2026.
Se você está avaliando verificadores, três perguntas cortam o marketing rapidamente:
- O que exatamente vocês reportam para um domínio catch-all? Se a resposta for "válido" ou uma pontuação crua, agora você sabe como a ferramenta lida com a incerteza em todo o resto também.
- Consigo ver a evidência por endereço? Registros MX, provedor e a resposta SMTP são fatos verificáveis; um veredito sem eles é uma opinião.
- Vocês alguma vez retornam "unknown"? Um fornecedor que alega uma resposta conclusiva para todo endereço em toda execução está descrevendo uma rede que não existe.
Quão comuns são os domínios catch-all?#
O número público mais atribuível vem dos
próprios dados agregados da ZeroBounce:
mais de 9% dos ~11 bilhões de endereços que eles processaram em 2025 retornaram como
catch-all, e eles observam que listas B2B com forte presença corporativa costumam chegar a 30% ou
mais. Outros fornecedores publicam números tão altos quanto 40–60% dos endereços B2B —
tipicamente sem nomear a fonte dos dados, então trate qualquer número de prevalência
não atribuído como marketing. O resumo honesto: cerca de um em cada dez endereços no geral,
várias vezes isso em listas B2B corporativas, e o único número que importa é
o da sua própria lista — que a verificação lhe informa diretamente. Figures above last verified July 2026.
O que os números refletem: configurações catch-all são muito mais comuns
em listas B2B do que em listas de consumidores. Google Workspace e Microsoft 365 ambos tornam
o roteamento catch-all uma simples configuração de administrador, e muitas empresas o ativam para que
endereços com erro de digitação (jhon.smith@ em vez de john.smith@) ainda cheguem
a alguém. Gateways de segurança corporativa adicionam outra camada: appliances que aceitam
a mensagem primeiro e filtram depois se comportam como accept-all no momento do SMTP mesmo quando
há caixas postais reais por trás deles. Grandes provedores de consumo, por outro lado, rejeitam
caixas postais desconhecidas no momento do RCPT — gmail.com não é um domínio catch-all.
A consequência prática: se você vende para empresas, uma fatia relevante da sua lista voltará como risky/catch-all não importa qual verificador você use, e sua estratégia de envio precisa de uma resposta para essa fatia — não de uma ferramenta que a rerrotule.
Espere que a proporção varie conforme a forma como a lista foi construída. Listas de newsletter de consumidores dominadas por endereços Gmail, Outlook.com e Yahoo verão pouquíssimos vereditos de catch-all. Listas construídas a partir de digitalização de cartões de visita, cadastros de webinars com e-mails corporativos ou prospecção de vendas contra domínios de empresas verão muito mais — e quanto mais velha a lista, mais desses domínios terão trocado de provedores de e-mail ou configurações desde que o endereço foi coletado.
Você deveria enviar para endereços catch-all?#
Não existe uma resposta honesta de sim/não. A decisão certa depende de onde o endereço veio, quanto um bounce lhe custa neste momento e quanta folga de reputação de remetente você tem. A única resposta universalmente ruim é tratar endereços catch-all exatamente como confirmados em um envio de volume total.
"Folga de reputação" vale a pena detalhar, porque é a variável que a maioria dos remetentes ignora. Um domínio com um longo histórico de envios limpos e forte engajamento consegue absorver um lote de bounces de catch-all como ruído. Um domínio novo, um IP novo ou um remetente se recuperando de uma temporada na caixa de spam não conseguem — os mesmos bounces caem sobre um histórico fino e movem o ponteiro. Quanto mais arriscada sua situação atual, mais rigoroso você deve ser com a fatia inconfirmável da sua lista.
| De onde o endereço veio | Recomendação |
|---|---|
| Cadastro opt-in recente no seu próprio formulário | Envie. Uma pessoa real o digitou minutos ou semanas atrás — essa intenção supera a incerteza. Fique de olho na taxa de bounce do segmento. |
| Opt-in mais antigo, sem engajamento há 6+ meses | Segmente e limite o ritmo. Envie lotes pequenos e remova endereços que permaneçam em silêncio após uma tentativa de reengajamento. |
| Lista comprada ou raspada | Não envie. Catch-all somado a uma lista comprada é a combinação mais arriscada em e-mail — endereços inverificáveis de uma fonte sem responsabilização. |
| Prospecção outbound B2B | Lotes pequenos e limitados a partir de um domínio aquecido, com o retorno dos bounces revisado após cada lote antes de ampliar. |
Seja qual for sua escolha, mantenha os envios catch-all em um segmento próprio. Hard bounces desse segmento são sua resposta real chegando com atraso — eles lhe dizem quais endereços catch-all nunca existiram, e causam dano à reputação que você quer contido e mensurável, não diluído por toda a sua lista. Se você não tem certeza de quanto dano de bounce consegue absorver, leia por que a taxa de bounce é a métrica que os provedores de caixa postal realmente observam.
Como reduzir o risco de catch-all sem mentir para si mesmo#
Nenhuma dessas técnicas "verifica" um endereço catch-all. O que elas fazem é encolher a incerteza ao longo do tempo e limitar o dano enquanto você aprende:
- Segmente e limite o ritmo. Endereços catch-all vão para o próprio grupo de envio, a uma fração do seu volume normal, para que o retorno dos bounces permaneça atribuível e contido.
- Envios-semente. Antes de uma campanha grande, envie primeiro para uma pequena fatia do segmento catch-all. Leia os resultados de bounce, depois decida quão amplo ir.
- Engajamento é a única confirmação de verdade. Um endereço sinalizado como catch-all que já abriu ou clicou é, para fins práticos, confirmado — há um humano por trás dele. Priorize catch-alls engajados; trate os frios com desconfiança.
- Monitore a taxa de bounce do segmento separadamente. Os provedores leem taxas sustentadas de hard bounce como um sinal de qualidade do remetente, então acompanhe o segmento catch-all em relação aos seus limites habituais em vez de deixá-lo se esconder no agregado.
- Política de descarte. Um endereço catch-all que permanece em silêncio ao longo de vários envios deve deixar a lista. Silêncio também é dado.
- Conserte a captação. Verifique no ponto de captura para que erros óbvios de digitação de domínios corporativos sejam pegos na porta — cada endereço corporativo malformado que você rejeita no cadastro é um morador permanente a menos do seu futuro segmento catch-all.
Se sua lista vive no Klaviyo, o guia passo a passo de limpeza aplica este manual de ponta a ponta — exportar, verificar, suprimir e segmentar os catch-alls.
Uma nota honesta sobre o roadmap: heurísticas conseguem ranquear endereços catch-all por qualidade provável — o provedor de MX do domínio, o tipo de gateway e o engajamento passado todos carregam sinal, e a Qualisend já lhe mostra essa evidência por endereço. Mas ranquear não é confirmar. Nada confirma uma caixa postal por trás de um domínio catch-all a não ser enviar para ela, e uma ferramenta que alega o contrário está vendendo o rótulo, não o fato.
Catch-all vs vereditos relacionados#
Catch-all é uma de várias situações do tipo "não dá para abençoar isso por completo", e elas pedem ações diferentes — e é por isso que colapsá-las em um único balde (ou uma única pontuação) perde exatamente a informação de que você precisa. Uma caixa postal cheia geralmente se cura sozinha; um endereço descartável nunca vai; um catch-all precisa de uma política de envio; um timeout só precisa de outra tentativa. Suprimir todos igualmente joga fora assinantes alcançáveis, e enviar para todos igualmente convida bounces. Veja como as situações mapeiam para o vocabulário de status e motivo da Qualisend:
| Situação | Status | Código do motivo | O que realmente significa |
|---|---|---|---|
| Domínio catch-all | risky | low_deliverability + sinalização de catch-all | O servidor aceita todos os endereços; esta caixa postal é inconfirmável. |
| Caixa postal cheia | risky | low_deliverability + sinalização de caixa postal cheia | A caixa postal existe, mas está acima da cota — a mensagem pode gerar bounce até ela ser esvaziada. |
| Endereço descartável | risky | low_quality + sinalização de descartável | Uma caixa de entrada temporária que vai deixar de existir — entregável hoje, inútil amanhã. |
| Endereço de função (info@, support@) | deliverable, sinalização de role | accepted_email | Uma caixa postal real lida por uma equipe em vez de uma pessoa — tudo bem enviar, fraco para prospecção. |
| Nenhuma resposta clara do servidor | unknown | timeout / unavailable_smtp /
unknown | A infraestrutura não respondeu de forma conclusiva — vale tentar de novo mais tarde, não é um veredito sobre a caixa postal. |
| Rejeitado ou inexistente | undeliverable | rejected_email / invalid_email /
invalid_domain | O endereço vai gerar bounce — suprima-o. |
A distinção que mais importa na prática: risky significa "chegamos ao servidor e aprendemos algo preocupante", enquanto unknown significa "não conseguimos uma resposta conclusiva desta vez". Endereços risky precisam de uma política de envio; endereços unknown, na maioria das vezes, precisam de uma nova tentativa.
Perguntas frequentes#
É seguro enviar para um endereço de e-mail catch-all?#
Às vezes. Um endereço catch-all vindo de um cadastro opt-in recente geralmente vale o envio; um endereço catch-all vindo de uma lista comprada, não. O enquadramento honesto é que "catch-all" descreve o comportamento do domínio, não a qualidade do endereço — então a segurança de enviar depende de onde o endereço veio e se ele alguma vez engajou. Envie para catch-alls em um segmento próprio e limitado e deixe o retorno dos bounces resolver o que a verificação não consegue.
Por que meu verificador disse "válido", mas o e-mail retornou?#
A causa mais comum é exatamente o tema deste guia: o domínio era catch-all, o servidor disse sim à sondagem de verificação como diz sim a tudo, e a ferramenta arredondou isso para "válido". A caixa postal nunca existiu, e a verdade chegou como um hard bounce na hora do envio. Endereços também podem morrer no intervalo entre a verificação e o envio, mas resultados persistentes de "verificado, mas retornou" em listas B2B costumam ser otimismo de catch-all.
Alguma ferramenta consegue verificar por completo um endereço catch-all?#
Não. Isso é uma característica do SMTP, não uma limitação de um fornecedor específico: um servidor que aceita todos os endereços não dá ao verificador nada que distinga caixas postais reais das falsas. Ferramentas que alegam "resolver" catch-alls apoiam-se em heurísticas, dados históricos ou sinais de engajamento — que conseguem, de forma útil, ranquear endereços por qualidade provável, mas não conseguem confirmar uma caixa postal. A única confirmação é um e-mail entregue e com engajamento.
Qual é a diferença entre accept-all e catch-all?#
Nenhuma — são dois nomes para a mesma configuração (você também verá "caixa postal curinga"). "Accept-all" descreve o comportamento do servidor; "catch-all" descreve a caixa postal que captura a mensagem. As ferramentas de verificação usam os termos de forma intercambiável.
Endereços catch-all prejudicam minha entregabilidade?#
Não por si só — ter endereços catch-all em uma lista é normal, especialmente em B2B. O dano vem de enviar às cegas: a parcela de endereços catch-all que nunca existiu vai gerar hard bounce, e hard bounces sustentados são o sinal que os provedores de caixa postal punem. Verifique a lista para que os inentregáveis confirmados já tenham saído, depois envie para o segmento catch-all restante gradualmente, para que quaisquer bounces apareçam cedo, em pequeno número, onde custam pouco.
Como faço para checar se um domínio é catch-all?#
Você precisa de um verificador que realize uma conversa SMTP real, porque a detecção de catch-all exige sondar o servidor (veja as transcrições acima). Uma verificação completa da Qualisend faz isso para cada endereço e informa a sinalização de catch-all junto com o provedor de MX do domínio e o detalhe da sondagem — o plano gratuito inclui 100 créditos para testar na sua própria lista. Note que nosso verificador de e-mail gratuito roda apenas checagens de sintaxe, DNS e erro de digitação — sem sondagem SMTP — então ele consegue descartar endereços, mas não consegue detectar catch-all; isso exige a verificação completa.
