E-mails catch-all: como funcionam e como detetá-los

A CaptainVerify verificou mais de 126 milhões de endereços de email em 2025. Cerca de 2,5% do volume recai sobre um domínio catch-all. Aplicada apenas aos endereços alojados num domínio de empresa, excluídos os webmails para o grande público que pesam quase três quartos do total verificado, a proporção aproxima-se dos 11%, ou seja quase um endereço profissional em cada 9. Esta medida incide sobre endereços. As taxas bem mais altas que se encontram noutros lados contam domínios, que é outra unidade: um único domínio em catch-all tanto pode ter uma mão-cheia de endereços na sua base como ter centenas. Num ficheiro B2B de 50 000 contactos, isso dá na ordem de 5 500 linhas cuja validade fica indecidível antes do envio.

O domínio que aloja estes endereços deteta-se em poucos segundos com um comando SMTP. Os 2 níveis tratam-se em separado: a deteção do domínio depende de um teste técnico reproduzível, a decisão de enviar depende dos seus limiares de bounce.

O que é um endereço catch-all?

Um catch-all é uma regra de encaminhamento definida ao nível do domínio: o servidor de receção aceita as mensagens endereçadas a qualquer caixa do domínio, declarada ou não.

A regra vive na configuração do domínio recetor, por trás do seu registo MX. Nenhuma caixa tem a etiqueta em si mesma. A expressão « endereço catch-all » circula por atalho e designa qualquer endereço cujo domínio aplica este modo de recurso.

Um exemplo torna a mecânica evidente. O domínio exemplo.com declara david@exemplo.com e ativa um catch-all. Um correspondente escreve daivd@exemplo.com, 2 letras trocadas. Num domínio normal, o servidor recusa este endereço no momento do RCPT TO e devolve um erro permanente ao remetente, um dos códigos de resposta SMTP que é preciso saber ler. Em exemplo.com, a mensagem entra e aterra na caixa de recurso. O erro de escrita passa despercebido.

Catch-all, alias, reencaminhamento e subendereçamento: não confundir

Um alias declara um endereço suplementar que aponta para uma caixa existente. Um reencaminhamento pega num endereço declarado e faz seguir o seu correio para outro destino. O subendereçamento acrescenta um sufixo depois de um sinal mais, do tipo david+imprensa@exemplo.com, que o servidor devolve à caixa de base. Estes 3 mecanismos incidem sobre endereços conhecidos do servidor, que recusa tudo o que sai da sua lista. O catch-all atua depois dessa lista, sobre as partes locais que nenhuma regra declara.

Para que serve o endereço catch-all?

Um catch-all recupera o correio enviado para um endereço mal escrito e priva um atacante da resposta que lhe diria que endereços existem no domínio.

O primeiro uso é banal. Os erros de escrita abundam nos nomes compostos e as caixas de colaboradores que já saíram continuam a receber correio durante meses. O catch-all apanha esse correio.

O segundo uso é defensivo. Um servidor que responde 550 nos endereços desconhecidos fornece um oráculo gratuito: o atacante submete uma lista de nomes próprios e guarda os que o servidor aceita. O domínio em catch-all responde 250 a toda a gente e deixa de fazer essa triagem por ele.

O reverso chega na caixa de recurso. Um domínio que aceita tudo atrai as campanhas de dicionário, esses envios massivos que tentam contacto@, admin@, apoio@, rh@ e algumas centenas de nomes próprios até que alguma coisa fique. A triagem cai então sobre a equipa que abre a caixa, com o trabalho de limpeza de lista que isso pressupõe do lado do remetente.

Como detetar um domínio catch-all

Um domínio catch-all deteta-se submetendo ao servidor um endereço tirado ao acaso: se o servidor aceita um endereço improvável, aceita também todo o resto.

O teste SMTP passo a passo: MX, EHLO, MAIL FROM, RCPT TO

1. Resolver os registos MX do domínio e reter aquele que tem o valor de preferência mais baixo, o MX primário. Na ausência de MX, o correio recai sobre o registo A do domínio.
2. Abrir uma ligação na porta 25 para esse servidor e cumprimentar com EHLO seguido de um nome de anfitrião que resolve em DNS.
3. Anunciar MAIL FROM com um envelope vazio ou um endereço de teste realmente contactável.
4. Enviar RCPT TO sobre o endereço a verificar, depois anotar o código de retorno e o texto que o acompanha.
5. Enviar RCPT TO sobre um endereço aleatório do mesmo domínio, do tipo k7v29xq4m@exemplo.com.
6. Fechar a sessão com QUIT, sem nunca passar ao comando DATA.

O sinal lê-se no endereço aleatório, a primeira aceitação serve apenas para verificar que a sessão se comporta normalmente. Preveja um RSET entre os 2 comandos RCPT TO, porque um servidor corta muitas vezes a sessão depois de um destinatário errado. Fechar antes de DATA evita entregar uma mensagem e só deixa nos registos remotos o rasto de uma abertura de sessão. O IP que sonda tem de dispor de um registo PTR válido, sob pena de uma recusa de política ser lida por engano como um endereço inválido.

250 OK contra 550: ler a resposta do servidor

A RFC 5321 de outubro de 2008 fixa a regra na sua secção 3.3: o servidor responde 550 ao RCPT TO quando o destinatário não é entregável, com uma mensagem do tipo « no such user ». A RFC 3463 de janeiro de 2003 precisa o código alargado associado na sua secção 3.2: 5.1.1 assinala um endereço de destino inválido e uma falha definitiva. Um 250 devolvido no endereço aleatório estabelece que o domínio aceita tudo no RCPT TO. A reserva conta: certas gateways antispam colocadas à frente aceitam também qualquer destinatário nesta fase sem aplicar um catch-all. A rejeição diferida descrita mais abaixo produz a mesma resposta. Estes códigos incidem sobre o envelope, ao passo que a forma do endereço depende da sintaxe definida pelas RFC.

O que falseia o teste: MX partilhado, greylisting, tarpitting e rejeição diferida

O MX partilhado encabeça os falsos sinais. Centenas de milhares de domínios apontam para os mesmos servidores de correio nos grandes alojadores. A política de destinatários regula-se domínio a domínio por trás desse MX comum, portanto o nome do servidor não diz nada sobre o modo de recurso.

O greylisting produz outro ruído. O servidor responde com um erro temporário em 4xx no primeiro contacto e espera uma nova tentativa para se pronunciar. A CaptainVerify espera até 30 minutos e relança a verificação antes de concluir. Os endereços que ficam mudos depois desse relançamento passam a estado desconhecido e são recreditados. O tarpitting pertence à mesma família: o servidor abranda deliberadamente as suas respostas para desencorajar as sondas.

A rejeição diferida complica ainda mais a leitura. O servidor aceita o destinatário no RCPT TO, depois gera um bounce assim que engole a mensagem. O teste vê um 250 limpo enquanto o envio real vai produzir um erro permanente alguns minutos mais tarde.

O que significa o estado accept_all num relatório de verificação

O estado accept_all, chamado ok4all nos relatórios CaptainVerify, indica que o domínio aceita todos os endereços e que a verificação para portanto ao nível do domínio.

A documentação CaptainVerify arruma o ok4all na família dos endereços arriscados e anuncia o efeito sem rodeios: a taxa de bounce sobe e a taxa de abertura desce. O relatório diz portanto 2 coisas numa linha. O domínio está qualificado, a pessoa por trás do endereço fica por confirmar através do envio.

É possível verificar um endereço num domínio catch-all?

O protocolo não decide, uma vez que o servidor devolve a mesma resposta a todos os endereços do domínio. O que continua possível é estimar uma probabilidade e ordenar o segmento em conformidade.

Olhe primeiro para o que se esconde por trás do registo MX do domínio. Quando aponta para uma gateway de segurança, do tipo Proofpoint, Mimecast, Barracuda ou Microsoft Defender para Office 365, é a gateway que responde por conta do domínio, antes mesmo de interrogar a caixa real. O estado accept_all traduz então uma arquitetura de filtragem mais do que uma regra de recurso decidida pela empresa. O caso é frequente nas grandes contas.

Vem depois a forma do endereço. Num domínio cujas caixas seguem uma convenção visível, nome.apelido por exemplo, um endereço que respeita essa convenção tem uma probabilidade de validade bem mais alta do que uma cadeia arbitrária. Compare as suas linhas umas com as outras: as que saem do molde vão para um segmento de teste, as outras passam em prioridade.

Um verificador acrescenta por fim os seus próprios sinais: a antiguidade do domínio, a reputação do fornecedor de correio, a dimensão da organização e o histórico observado em envios anteriores. O resultado dá um índice de confiança que serve para ordenar um segmento antes do envio.

Criar ou desativar um catch-all conforme o alojador

A comutação regula-se na consola de administração do domínio: modo do domínio aceite no Microsoft 365, regra de encaminhamento no Google Workspace, endereço predefinido no cPanel.

Google Workspace

O Google Workspace não propõe nenhuma função catch-all nativa. A Google publica em contrapartida uma página de ajuda dedicada à caixa de recolha e chama ao tipo de conta visado Unrecognized ou Catch-all. A configuração passa por uma regra de encaminhamento, em Apps depois Gmail depois Routing, com a ação Change envelope recipient aplicada às contas inativas e não reconhecidas. O correio endereçado a uma caixa desconhecida parte então para um endereço de recolha designado. Para voltar atrás, elimine essa regra de encaminhamento: o domínio recomeça logo a recusar os destinatários que não conhece.

Microsoft 365

O comportamento depende do modo do domínio aceite, em Mail flow depois Accepted domains. Em modo Authoritative, o domínio rejeita os destinatários desconhecidos e ativa o Directory-Based Edge Blocking, que corta a mensagem na fronteira do serviço. O modo Internal relay faz seguir o correio dos destinatários desconhecidos para outro servidor e produz de facto um comportamento de recurso.

cPanel

A função chama-se Default Address. Propõe devolver um erro ao remetente durante a sessão SMTP, comportamento predefinido e exato contrário do catch-all. Pode também encaminhar o correio dos endereços desconhecidos para uma caixa existente, ou deitá-lo fora em silêncio. A documentação cPanel etiqueta ela própria a opção que descarta a mensagem em silêncio como Not Recommended, por uma razão de fundo: o remetente nunca fica a saber que a sua mensagem desapareceu.

O que colocar no lugar de um catch-all

A saída passa por endereços declarados mais do que por uma regra de recurso. Crie aliases sobre os erros de escrita mais frequentes dos seus nomes de domínio e mantenha uma caixa genérica de contacto realmente lida. O subendereçamento assume o lugar para rastrear os seus formulários sem multiplicar as caixas. O domínio recupera uma lista de destinatários limpa. Os seus correspondentes recebem um erro imediato quando se enganam.

Catch-all com ou sem bounce

2 configurações distintas escondem-se por trás desta questão. O catch-all aceita o destinatário desconhecido no RCPT TO e entrega a mensagem numa caixa de recurso, sem bounce de espécie alguma. A rejeição diferida também aceita no RCPT TO, depois fabrica um relatório de não entrega depois de ter engolido a mensagem.

Este segundo modo tem um custo para toda a gente. Quando o envelope de origem é falsificado, o que é a norma no spam, o relatório de não entrega parte para um terceiro inocente cujo endereço serviu de isco. O fenómeno tem um nome, o backscatter. Alimenta as listas de bloqueio. Compreendê-lo ajuda também a triar os seus próprios retornos, entre hard bounce e soft bounce.

Deve incluir os endereços catch-all nas suas campanhas?

Enviar para endereços catch-all faz subir a taxa de bounce e descer a taxa de abertura, 2 curvas que as plataformas de envio vigiam para decidir o que se segue. É por aí que a reputação de remetente se degrada, mensagem após mensagem.

O risco real: limiar de bounce, taxa de reclamação, reputação de remetente e spam traps

Os limiares de bounce vêm das plataformas de envio. A Amazon SES coloca o seu contador sob revisão acima de 5% de bounce e pode suspender os envios aos 10%. A documentação Microsoft para o Dynamics 365 Customer Insights, atualizada em agosto de 2026, distingue 2 níveis: uma taxa de bounce aceitável não passa de 2% na maioria dos casos. O próprio produto tolera até 8% antes de reagir. Os 2% pertencem portanto à boa prática, os 8% ao limiar realmente aplicado. Voltemos ao ficheiro de 50 000 contactos e às suas cerca de 5 500 linhas em catch-all. Se metade rejeitar, o contador passa os 5% antes mesmo de ter contado o resto da base, acima da barra que desencadeia a revisão da conta. Os limiares de bounce aplicados pelas plataformas de envio variam depois de um ator para o outro.

Os limiares de reclamação vêm dos fornecedores de correio e contam-se à parte. As regras da Google para os remetentes, aplicáveis desde 1 de fevereiro de 2024, pedem uma taxa de reclamação abaixo de 0,10% e fixam um limite a nunca atingir em 0,30%, para qualquer remetente de mais de 5 000 mensagens por dia para o Gmail. O Sender Hub do Yahoo pede para ficar abaixo de 0,3%. Estes 2 atores publicam limiares de reclamação e nenhum limiar de bounce.

Fica o tema das spam traps. A Spamhaus documentou o ciclo em fevereiro de 2022: um endereço abandonado rejeita em erro permanente muitas vezes durante 12 meses ou mais, depois o domínio volta a acendê-lo como armadilha. Uma base deixada sem limpeza há 2 anos contém portanto, estatisticamente, endereços que mudaram de natureza entretanto.

Reduzir a incerteza antes do envio

A verificação prévia da lista faz a primeira triagem. Retira os inválidos e isola os ok4all num segmento dedicado. Fica uma base sobre a qual o bounce volta a ser previsível. Veja depois a origem da recolha: uma lista construída em opt-in simples ou em duplo opt-in produz claramente menos bounces do que um ficheiro comprado. Considere por fim a antiguidade, uma vez que o ciclo descrito pela Spamhaus corre sobre todos os endereços adormecidos. Este panorama das ferramentas de verificação de emails detalha as abordagens disponíveis.

Validar pelo engagement depois do primeiro envio

O segmento ok4all trata-se como um teste. Envie primeiro para 5 a 10% do segmento. Meça o bounce e a abertura, depois compare estes 2 valores com os do resto da campanha. Um desvio fraco autoriza a subir a percentagem no envio seguinte. Um desvio nítido indica um segmento a deixar de lado ou a retrabalhar.

Ao fim de 2 envios sem abertura nem clique, um endereço em catch-all provou a sua inutilidade e sai da lista. Antes da sua próxima campanha, isole as linhas ok4all de uma amostra da sua base e compare a taxa de bounce com a do resto: o veredicto sai numa hora e vale por todas as estimativas.

Perguntas frequentes

Um domínio catch-all é detetável?

Sim, em poucos segundos. Um comando RCPT TO sobre um endereço aleatório do domínio basta: uma resposta 250 num endereço improvável revela o modo de recurso. A validade de cada endereço individual, essa, fica indecidível por este teste.

Que parte de uma base B2B está em causa?

Em mais de 126 milhões de endereços verificados pela CaptainVerify em 2025, cerca de 2,5% saíram em catch-all. O perímetro dos domínios de empresa leva esta proporção a quase 11%. Uma base B2B de 100 000 contactos contém portanto na ordem de 11 000 linhas deste tipo, a isolar antes do envio.

O catch-all protege do spam?

Aumenta o spam recebido, uma vez que qualquer endereço inventado no domínio encontra uma caixa. O seu benefício está noutro lado: o servidor deixa de responder 550 nos endereços desconhecidos e priva o atacante do oráculo que lhe permitiria enumerar os endereços válidos.

É preciso apagar os endereços catch-all da lista?

A eliminação pura justifica-se quando a sua plataforma de envio aplica um limiar de bounce baixo, à imagem dos 5% que desencadeiam uma revisão de conta na Amazon SES. Num IP dedicado que o próprio controla, um segmento separado e um envio por lotes continuam a ser uma opção razoável.

Que fazer de um estado desconhecido num relatório?

Assinala um servidor que ficou mudo apesar do relançamento automático efetuado nos 30 minutos. A CaptainVerify recredita estas verificações. Uma nova passagem mais tarde decide na grande maioria dos casos.