Catch all email: o que é, como funcionam os endereços catch-all, por que os verificadores não conseguem confirmá-los e como enviar com segurança

Um catch all email é um endereço em um domínio cujo servidor de e-mail aceita qualquer mensagem, seja qual for o nome antes do @. O servidor nunca diz se a caixa existe, então o verificador retorna “catch-all” em vez de válido ou inválido. Nas verificações da própria Spona, 14,25% de 40.000 endereços caíram nessa categoria.

Este guia adota o ponto de vista de quem envia em B2B e mostra o que é um e-mail catch-all na prática. Explica o que o servidor faz durante uma verificação, por que as empresas o configuram assim e como cada verificador chama o resultado. Mostra também o que aconteceu quando um cliente enviou 1.200 e-mails para endereços catch-all. Como configurar uma caixa catch-all ganha uma única resposta, no FAQ.

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

Significado de catch all email: uma caixa que aceita qualquer endereço

O termo tem dois públicos, e cada um entende uma coisa diferente.

Para o administrador de e-mail, catch-all é uma caixa de correio. A Proton descreve o recurso como a opção de “receber todos os e-mails enviados ao seu domínio”, inclusive os destinados a endereços que ninguém criou. Nas palavras da Namecheap, todo e-mail enviado ao seu domínio “que ainda não esteja configurado como conta de e-mail ou alias de e-mail” vai parar ali.

As caixas reais continuam recebendo as próprias mensagens. A Proton observa que o e-mail para um endereço existente “não será entregue ao endereço catch-all”.

Para o remetente, catch-all é um resultado de verificação. A NeverBounce resume em uma linha: accept-all “é uma configuração no servidor de e-mail do destinatário, não um veredito sobre o endereço individual”. O endereço que você verificou pode ser de uma pessoa real, um erro de digitação ou alguém que saiu da empresa há dois anos. O servidor não disse nada, nem num sentido nem no outro.

A grafia varia: catchall email, catch-all email, accept-all email. Os verificadores também dizem “accept all”, e os provedores de hospedagem falam em “wildcard”. Todos descrevem o mesmo comportamento do servidor.

Uma leitura errada causa a maior parte do estrago. Quem ouve catch-all pensa logo em “endereço morto”. O status diz que o domínio aceita tudo. Não diz nada sobre a pessoa ainda estar lá.

Como um domínio catch-all responde à verificação SMTP

O verificador testa um endereço iniciando uma entrega e parando antes que qualquer mensagem saia: conecta-se ao servidor de e-mail do domínio, indica um destinatário e lê a resposta. A RFC 5321, o padrão do SMTP, define essas respostas. Quando o servidor aceita o destinatário, ele “retorna uma resposta ‘250 OK’”. Quando se sabe que o destinatário “não é um endereço entregável”, a resposta é 550.

Em um domínio comum, essa resposta resolve a questão. Um 250 significa que a caixa existe. Um 550 significa que não existe.

Um domínio catch-all responde 250 para tudo. O verificador não consegue distinguir uma caixa real de uma inventada, então faz uma segunda sondagem.

O método do Hunter é perguntar ao servidor se ele aceita e-mail para um endereço “que com certeza não existe”. Se a resposta for sim, o domínio inteiro recebe a marca de accept-all. Todos os endereços desse domínio herdam o rótulo.

O padrão previu isso: um servidor “NÃO DEVE retornar um código 250” a um comando de verificação, a menos que tenha de fato verificado o endereço. Quando não consegue, o código 252 “DEVERIA ser retornado” no lugar. Essa regra vale para o comando VRFY. O servidor catch-all responde na etapa do destinatário, em que um 250 significa que ele vai aceitar a mensagem, não que alguém lê a caixa.

Mais uma cláusula vai importar adiante. Um servidor que aceitou uma mensagem e depois não consegue entregá-la “DEVE gerar uma notificação de ‘e-mail não entregável’” e devolvê-la ao remetente. O sim na porta pode virar um não depois do envio.

Por que as empresas configuram endereços de e-mail catch-all

As páginas de ajuda dos provedores que oferecem o recurso dão dois motivos. Uma migração de e-mail pode acrescentar um terceiro.

Erros de digitação: o exemplo da one.com é um remetente que digita “daivd@domain.com” em vez de david@. Sem catch-all, o servidor recusa a mensagem. Com ele, a mensagem cai numa caixa que alguém confere.

Funcionários que saíram: o Google Workspace permite que o administrador direcione mensagens enviadas a “endereços de e-mail inexistentes ou incorretos” para uma caixa catch-all. A opção de roteamento leva o rótulo “All inactive and unrecognized accounts”, ou seja, todas as contas inativas e não reconhecidas. Assim, os e-mails enviados a quem saiu continuam chegando à empresa. É uma regra de roteamento criada pelo administrador, não um padrão: um domínio hospedado no Google não é catch-all a menos que alguém tenha ativado o recurso.

Migrações: o Microsoft 365 adota a postura oposta, e o Directory-Based Edge Blocking permite que um tenant “rejeite mensagens para destinatários inválidos no perímetro da rede do serviço”. A resposta é “550 5.4.1 Recipient address rejected: Access denied”. A Microsoft orienta os administradores a manter um domínio como “Internal relay” só até o diretório conter todos os destinatários válidos. Até lá, a borda pode aceitar destinatários desconhecidos, e a sondagem de um verificador pode interpretar isso como catch-all.

O preço é o spam. O alerta da one.com para quem ativa o recurso: “a maioria dos e-mails que você capturar será spam”.

Verificação de catch-all email: o que cada verificador retorna

Na verificação de e-mail, “catch-all” significa que o verificador encontrou um servidor que aceita qualquer destinatário e, por isso, não conseguiu testar o seu endereço.

Todo verificador esbarra no mesmo muro. A ZeroBounce diz que e-mails catch-all “são impossíveis de validar sem enviar e-mail para eles” e esperar para ver se geram bounce. A MailerCheck concorda: “não há como saber se são válidos ou inválidos”. O que muda é o rótulo e o que o fornecedor faz em seguida.

Os rótulos vêm das próprias páginas de ajuda e páginas de produto de cada fornecedor. Os preços das checagens mais profundas estão no guia de limpeza de lista de e-mails, não aqui.

Unknown (desconhecido) é outro resultado. A NeverBounce o define como o servidor que não dá “uma resposta definitiva a tempo”, muitas vezes por causa de greylisting ou de um gateway de segurança. Um servidor catch-all respondeu; um servidor unknown, não.

Verifique de novo um unknown amanhã e ele pode se resolver. Verifique de novo um catch-all e você recebe outro 250.

Com que frequência aparecem e-mails catch-all: 40.000 verificações B2B da Spona

A Spona verificou 10.000 endereços candidatos únicos em cada um de quatro países antes de qualquer envio. Os números são dados da Spona, e a fatia que voltou como catch-all foi de 12% no Reino Unido a 16% na Alemanha.

A fatia é calculada sobre todos os endereços candidatos únicos verificados. Cada endereço é aprovado, catch-all ou rejeitado por outro motivo, nunca duas coisas ao mesmo tempo. A Spona não mediu recortes por cargo ou setor, e esses quatro são os únicos países que ela mediu. Nos quatro países juntos, cerca de um em cada sete endereços verificados voltou sem veredito.

Outras fatias publicadas descrevem outras populações. A ZeroBounce constatou que “mais de 9%” de todos os e-mails que verificou eram catch-all, em mais de 11 bilhões de endereços processados. O número da MailerCheck é de 8,6% de tudo o que ela já verificou, mas, por lista de cliente, a mediana sobe para 15,25%. O Hunter conta domínios, não endereços: “38% dos domínios de e-mail” em uma amostra de 2.572 endereços eram accept-all.

Nenhum desses números se compara com a tabela da Spona. Cada um conta uma coisa diferente em uma lista diferente. O que eles têm em comum é a direção: uma minoria considerável de qualquer lista que você verificar.

E-mails catch-all são arriscados para cold email? O que um cliente viu

Sim, e o risco é mensurável. O benchmark atualizado da Spona define a linha de base e exclui por regra os endereços catch-all: “Hard bounce é o número de falhas permanentes de entrega dividido pelos envios tentados ao subconjunto verificado, excluindo endereços catch-all”. Em 20.000 envios desse tipo, a taxa de hard bounce foi de 1,525%.

Um cliente enviou para endereços catch-all mesmo assim e informou o resultado. Em cerca de três meses, os 1.200 envios desse cliente geraram 86 hard bounces, que a Spona registrou como uma coorte separada. Isso dá 7,17%. Relatos assim mantêm o próprio denominador de envios e nunca entram no benchmark.

Lado a lado, a taxa da coorte é cerca de 4,7 vezes a taxa do benchmark.

Duas ressalvas acompanham essa diferença. Os 7,17% vêm dos 1.200 envios de um único cliente: não são uma taxa do setor e não preveem a sua. As duas coortes também diferem em mais do que o rótulo catch-all, então a diferença compara resultados, mas não mede uma causa.

O Hunter fez o próprio teste: uma campanha para 100 endereços accept-all e 100 válidos. O resultado: “A taxa de bounce foi de 27%” no grupo accept-all e de 1% no grupo de controle. Lista diferente, remetente diferente, mesma direção.

O mecanismo é a cláusula da RFC 5321 citada acima. Um servidor catch-all aceita toda mensagem na porta e depois tenta entregá-la internamente. Quando nenhuma caixa corresponde, ele precisa devolver o aviso de não entrega. O alerta da ZeroBounce decorre disso: “endereços de e-mail catch-all inexistentes acabarão gerando bounce” e prejudicando a sua reputação de remetente.

O Hunter lista os três desfechos possíveis de uma mensagem para um domínio accept-all: “entregue, redirecionada para uma caixa catch-all ou bounce posterior”. Você só descobre qual deles depois do envio.

Onde fica o limite: a Twilio escreve que uma taxa de bounce “acima de 2%” indica que é hora de agir e que programas saudáveis ficam abaixo de 1%. Um segmento catch-all que gere bounces como aquela coorte, colocado numa campanha verificada, puxa a taxa da campanha inteira em direção a esse limite.

Como verificar e-mails catch-all além da checagem SMTP

Nenhuma ferramenta consegue confirmar uma caixa por trás de um servidor catch-all. O servidor não diz, e nada mais pode falar por ele. O que as melhores ferramentas fazem é estimar, de três formas.

Pontuações de confiança. O Hunter atribui uma pontuação aos resultados Accept all, baseada “no número e na atualidade das fontes” em que encontrou o endereço. A orientação dele é tratar uma pontuação de “85-100%” como válida, embora o endereço continue com uma chance um pouco maior de bounce. Uma pontuação é uma probabilidade tirada de evidências da web, não uma resposta do servidor.

Sondagens mais profundas. A MillionVerifier diz que um ping mais profundo converte “até 40%” dos e-mails catch-all em Valid ou Invalid, e o restante continua Risky. Esse é o número do fornecedor para o próprio método, nas próprias listas. Trate toda taxa de recuperação do mesmo jeito até testá-la nas suas.

Evidências fora do servidor de e-mail. Um nome que segue o padrão de endereços da empresa, um perfil nesse empregador, uma menção recente no site da empresa. Cada uma aumenta a chance de a caixa existir. O guia de validação de dados B2B cobre esse processo, e nada disso muda a resposta do servidor.

O único teste que funciona é o que custa caro. Enviar uma mensagem e esperar um bounce é o único caminho, como diz a ZeroBounce. Mas a ausência de bounce pode significar só uma caixa catch-all, que, segundo o Hunter, dificilmente é lida. O Hunter aponta que o método levanta “questões éticas”, já que você manda spam para outras empresas para descobrir, e cada bounce fica no histórico do seu domínio.

Como enviar e-mail para um endereço catch-all com segurança: seis passos

1. Mantenha um segmento separado. Endereços catch-all nunca ficam na mesma lista que os verificados. O checklist de higiene de dados os mantém num segmento próprio a cada envio.
2. Limite a fatia. A orientação do Hunter é restringir os endereços accept-all a uma pequena parcela das suas campanhas, de 2% a 5% dos envios. Nessa proporção, um segmento com bounces como os da coorte do cliente acrescentaria no máximo alguns décimos de ponto.
3. Priorize pela evidência. Envie primeiro para os endereços com pontuação de confiança alta, padrão de nome compatível ou menção pública recente. Deixe os palpites sem base para o fim, ou descarte-os.
4. Envie em lotes pequenos e acompanhe. A NeverBounce recomenda enviar “em lotes pequenos” e monitorar quais voltam com bounce. Se o seu provedor exigir uma taxa de bounce “abaixo de 4%”, a NeverBounce diz para enviar de forma seletiva em vez de descartá-los.
5. Pare no primeiro bounce de um domínio. Um hard bounce vindo de um domínio catch-all mostra que a triagem dele falhou para aquele nome. Suprima o endereço na hora e pause o resto daquele domínio até ter um nome melhor.
6. Use a identidade em outro canal. O status catch-all não diz nada sobre a pessoa, então nome, empresa e cargo ainda podem ser úteis. Uma ligação ou uma mensagem no LinkedIn não gera bounce. Um segundo contato na empresa pode ajudar, mas, no mesmo domínio, o endereço dele também é catch-all.

Se você guarda contatos catch-all no CRM, a LGPD inclui a qualidade dos dados entre os princípios do tratamento. O art. 6, V a define como “garantia, aos titulares, de exatidão, clareza, relevância e atualização dos dados”, conforme a necessidade e a finalidade do tratamento. Cabe à ANPD fiscalizar e aplicar sanções quando o tratamento de dados descumpre a legislação.

Como a Spona lida com e-mails catch-all e onde ela deixa a desejar

A Spona encontra leads a partir da descrição do seu cliente ideal feita em um chat, verifica todos os endereços e entrega uma lista pontuada em cerca de 4 minutos. Os endereços catch-all passam pela mesma checagem SMTP que todo o resto. O que acontece depois segue seis regras.

Onde ela se encaixa. Você paga por lead, e um endereço catch-all nunca entra na contagem de e-mails verificados. Um lead Standard Search só com e-mail custa de 3 a 7 créditos. Pelos preços de crédito dos planos, isso dá de US$ 0,024 a US$ 0,07.

Cada nova sessão de busca também tem um custo único de 1.000 créditos.

A regra 3 é a mais útil para registros catch-all. A Spona guarda o registro da pessoa, e o enriquecimento pode acrescentar um número de celular por 35 créditos. Isso dá de US$ 0,28 a US$ 0,35, e a conversa passa para o telefone. Toda busca começa com uma amostra grátis, e o plano gratuito Free inclui 3.000 créditos concedidos uma única vez.

Onde ela deixa a desejar. A Spona também não consegue confirmar uma caixa catch-all; por design, a exportação catch-all não traz nenhuma alegação sobre caixa ou taxa de bounce. Ela não vende ferramenta de resolução nem pontuação de confiança para esses registros, algo que o Hunter e a MillionVerifier oferecem.

A tabela por país cobre só EUA, Reino Unido, Alemanha e França, sem recorte por cargo ou setor. A coorte de 1.200 envios é o relato de um único cliente, registrado porque esse cliente o enviou. A Spona não envia os seus e-mails, então só vê bounces de catch-all quando um cliente os informa.

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

Catch all email: perguntas frequentes (FAQ)

Como configurar um endereço de e-mail catch-all?

Nas configurações de administração do seu provedor de e-mail, não no programa de e-mail. A Proton permite isso em “qualquer plano pago da Proton”, em Settings, All settings, Organization, Domain names e, por fim, Set catch-all. O Google Workspace usa uma regra de roteamento para “All inactive and unrecognized accounts” que “pode levar até 24 horas” para entrar em vigor. O Microsoft 365 funciona ao contrário e rejeita destinatários desconhecidos na borda.

O que é um domínio catch-all?

Um domínio catch-all é aquele cujo servidor de e-mail aceita mensagens para qualquer endereço, inclusive endereços que não existem. Os verificadores o detectam sondando um endereço inventado: um 250 para ele marca o domínio. Todos os endereços do domínio passam então a ter o status catch-all, que descreve o domínio, não a pessoa.

Um e-mail catch-all é um e-mail inválido?

Não. Inválido significa que o servidor recusou o endereço com um 550. Catch-all significa que o servidor o aceitou junto com todo o resto, então o endereço pode muito bem pertencer a uma pessoa real. Nas checagens da Spona, aprovado, catch-all e rejeitado por outro motivo são categorias separadas, e cada endereço cai em apenas uma.

E-mails catch-all geram bounce?

Alguns sim, depois que o servidor os aceitou: ele recebe a mensagem, não encontra nenhuma caixa correspondente e devolve um aviso de não entrega. Os 1.200 envios catch-all de um cliente voltaram com 86 hard bounces. No teste do Hunter, 100 endereços accept-all tiveram uma taxa de bounce de 27%. Nenhum dos dois números prevê o resultado da sua lista.

Devo remover os e-mails catch-all da minha lista?

Não automaticamente. A posição do Hunter é que endereços accept-all “não devem ser descartados automaticamente”, e que ninguém deve tratá-los como totalmente válidos. Mantenha-os num segmento próprio, envie em lotes pequenos para os que têm mais evidência e leve o resto para o telefone ou o LinkedIn. A MailerCheck descreve um período de carência comum de 3 a 6 meses sem aberturas ou cliques antes da remoção.