O e-mail catch-all é uma regra que direciona mensagens para destinatários desconhecidos do domínio a um destino específico. Para ghost@yourdomain.com, um servidor pode rejeitar o destinatário com 550 sem necessariamente fechar a conexão. Catch-all pode responder 250 OK ao destinatário; isso ainda não é aceitação final do conteúdo após DATA.
Em 2026, recuperar um erro de digitação continua útil, mas volume, reputação e dados pessoais exigem controles. Os efeitos dependem do uso e da configuração.
Este guia explica SMTP, cinco áreas de risco, autenticação do encaminhamento e opções de configuração.
O que é catch-all?
O e-mail catch-all, também chamado accept-all ou regra curinga, direciona destinatários desconhecidos de um domínio válido a uma rota padrão. Em vez de rejeição 550 por endereço inexistente, o servidor pode admitir o destinatário e entregar a mensagem se ela passar pelos outros controles.
Painéis usam accept-all e catch-all para esse comportamento: destinatários sem correspondência em RCPT TO têm uma rota padrão. No TrekMail, revise Domínios → Roteamento, chamado Conexão nas interfaces anteriores, → Caixa catch-all e escolha um destino permitido. Confira aplicação da mudança e trajeto real, sem presumir efeito instantâneo.
Do fim dos anos 1990 até 2026, o tráfego automatizado mudou a necessidade de controles. Catch-all pode ocultar quais endereços existem numa sondagem, mas destinatários inventados também podem aumentar processamento e armazenamento.
Por que ativar catch-all e o que avaliar
Dois motivos comuns são recuperar contatos mal endereçados e evitar licenças adicionais. Compare-os com aliases explícitos, necessidades reais de caixas e carga de recebimento.
Recuperar erros de digitação
Uma empresa pode temer perder contato por suport@ em vez de support@. Catch-all pode recuperá-lo e também receber tráfego inventado. Defina responsável e revisão que permita encontrar correio útil entre mensagens indesejadas.
Para erros conhecidos, crie aliases específicos. Com support@, adicione, por exemplo, suport@ ao mesmo destino. Isso limita destinatários arbitrários, sem substituir filtros e controles.
O custo das licenças
Uma referência histórica Google Workspace e Microsoft 365 situa licenças em $6-30 por usuário por mês. support@, billing@, jobs@ e marketing@ com quatro licenças independentes poderiam somar até $120/mês nesse exemplo. Aliases, caixas compartilhadas e licenças existentes podem ter condições diferentes; catch-all não é obrigatório.
Compare custo completo, permissões e controles. Armazenamento agrupado pode mudar o cálculo sem eliminar sozinho os riscos. Consulte os planos do TrekMail e condições atuais.
Como funciona no SMTP
Em RCPT TO, o remetente indica o destinatário antes de transmitir o conteúdo. O servidor pode admitir ou rejeitar e depois aplicar outros controles. Segurança depende também de autenticação, filtros, rotas e aceitação final.
Rejeição de destinatário desconhecido
S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 550 5.1.1 User unknown
(connection closed - zero bytes of message body transferred)
Não há destinatário válido ghost e o servidor devolve 550. O exemplo simplifica a troca: a conexão não precisa fechar e comandos SMTP já foram transmitidos. Não se aceita conteúdo para esse destinatário, mas a transação pode ter outros destinatários válidos.
O fluxo catch-all
S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 250 OK
(full message body, headers, attachments transferred)
→ routed to catchall-bucket@yourdomain.com
A rota admite o destinatário desconhecido. A aceitação final do conteúdo vem depois e pode depender de filtros durante DATA. Se aceitar a mensagem, o servidor precisa gerenciar entrega, armazenamento e erros sem avisar identidades falsificadas.
Em escala, rejeitar destinatários desconhecidos pode poupar análises e armazenamento. Catch-all pode aumentar a carga, mas não exige aceitar todo conteúdo antes de filtrar. Confira limites e etapas de filtragem com o provedor.
Os 5 riscos operacionais
Admitir destinatários inventados amplia o recebimento e pode aumentar tráfego indesejado. É uma alteração no servidor, não promessa ligada à propagação DNS. Avalie as áreas seguintes antes de ativar.
Risco 1: sondagens de diretório e volume
Ataques de coleta de endereços testam milhões de nomes: admin, david, invoice, hr, webmaster, noreply. Buscam distinguir destinatários admitidos dos rejeitados.
Uma resposta 550 pode revelar um endereço inexistente, sem obrigar o atacante a parar. Catch-all dificulta distinguir endereços criados dos inventados. Passar de 50 mensagens diárias a 50,000 é um cenário de carga que pode consumir cotas e filtros e ocultar correio legítimo.
Risco 2: backscatter e reputação de envio
Backscatter ocorre com avisos posteriores a uma identidade de envelope falsificada. Um exemplo:
- Um atacante envia a
random-gibberish@yourdomain.comnum domínio com catch-all. - Falsifica MAIL FROM, refletido em
Return-Pathna entrega, como uma vítima:victim@gmail.com. Um cabeçalho fornecido pelo atacante não determina de forma confiável a identidade de envelope. - O servidor aceita definitivamente a mensagem depois de admitir o destinatário.
- Um filtro posterior detecta mensagem indesejada e sinaliza falha interna.
- Se o servidor gerar NDR para o remetente de envelope, refletido em
Return-Path, envia avictim@gmail.com. - A vítima recebe aviso não solicitado de uma mensagem que não enviou.
Esse tráfego pode prejudicar reputação e contribuir para listas como ips.backscatterer.org. Rejeite durante SMTP quando adequado ou use quarentena segura sem respostas a identidades falsificadas. Veja como investigar reputação do domínio.
Risco 3: responsabilidade das rotas
Uma mensagem para partnerships@company.com pode cair na caixa comum. Sem responsável, pode ficar dias sem revisão. Defina proprietário, acesso e rotina conforme a urgência do tráfego.
Aliases explícitos permitem definir quem recebe cada endereço. Confira o destino de partnerships@ e documente responsabilidades; o alias não garante sozinho uma resposta.
Risco 4: suporte de prestadores de serviços gerenciados
Para agências com 50+ domínios, prepare respostas a incidentes como:
- “A caixa está cheia e lenta”: revise cota, armazenamento e volume.
- “Recebo spam demais”: revise filtros e destinatários admitidos.
- “Não encontro a mensagem do cliente”: ela pode estar, por exemplo, na página 400 da caixa comum.
- “Meus envios chegam em spam”: investigue autenticação, reputação e avisos indevidos.
Numa comparação entre catch-all e aliases, reduzir incidentes em 30-40% pode ser objetivo ilustrativo de planejamento, não resultado medido ou prometido. Registre volume real e tempo de revisão antes e depois da mudança.
Risco 5: minimização e proteção de dados
O artigo 5(1)(c) do GDPR exige minimização conforme a finalidade aplicável. Catch-all pode coletar informações desnecessárias, mas a avaliação depende de objetivo, base legal, acesso e retenção. Defina quais dados chegam e como são tratados.
Localizar dados entre 500,000 mensagens pode complicar pedidos de exclusão. Se doctor@yourclinic.com direciona informações de saúde a uma caixa comum, revise papéis, autorizações, fluxos e salvaguardas HIPAA quando aplicáveis. Acesso de técnicos não determina sozinho uma infração: é preciso avaliar o tratamento real.
SPF, DKIM e DMARC com catch-all
Catch-all não quebra diretamente esses protocolos. Resultados dependem de remetentes, identidades, assinaturas e alterações no encaminhamento. Separar autenticação, reputação e rota ajuda no diagnóstico.
| Protocolo | O que verifica | Pontos a revisar |
|---|---|---|
| SPF | Autorização de IP para a identidade SMTP avaliada, normalmente MAIL FROM | Catch-all não muda SPF; encaminhar com envelope original pode usar IP não autorizado |
| DKIM | Assinatura criptográfica das partes assinadas dos cabeçalhos e conteúdo | Alterar partes assinadas pode afetar a assinatura; nem toda mudança a invalida |
| DMARC | SPF ou DKIM bem-sucedido e alinhado ao domínio From visível | DKIM válido e alinhado pode satisfazer DMARC apesar de falha SPF no encaminhamento |
Ao encaminhar, revise IP intermediário e identidades reais. Relatórios DMARC dizem respeito ao domínio From original, não sempre ao domínio do intermediário. Google Postmaster Tools fornece dados agregados elegíveis do Gmail pessoal, não registro completo de catch-all ou de toda falha de autenticação.
O problema do encaminhamento
Encaminhar tudo ao Gmail pessoal pode parecer conveniente, mas exige controle de remetentes, filtros, autenticação e acesso. Um destinatário desconhecido não deve criar encaminhamento indiscriminado.
Por que a autenticação pode falhar
O destinatário vê conexão pelo seu IP intermediário, enquanto From: pode conservar bank@chase.com. SPF avalia a identidade SMTP, não esse cabeçalho sozinho. Confira envelope e assinaturas:
- SPF: com MAIL FROM do domínio original, o IP intermediário precisa ser autorizado por aquele domínio.
- DKIM: rodapé, assunto ou anexo alterado pode invalidar a assinatura se atingir partes assinadas; existem outras causas.
- DMARC: basta SPF ou DKIM bem-sucedido e alinhado. Se nenhum atende, o destinatário aplica as políticas pertinentes.
O resultado pode ser rejeição, atraso, quarentena, spam ou outra ação, não sempre exclusão silenciosa. Para p=reject, confira resultado real, logs e avisos. O guia de diagnóstico e configuração do encaminhamento detalha as verificações.
SRS e ARC quando precisa encaminhar
Para migração ou fluxo antigo, revise dois mecanismos: SRS reescreve envelope e ARC transmite resultados anteriores assinados. A necessidade depende do trajeto; DKIM original válido e alinhado pode satisfazer DMARC sem ambos.
SRS (Sender Rewriting Scheme)
SRS reescreve o remetente de envelope para SPF avaliar o domínio usado pelo intermediário, possivelmente o seu domínio. O SPF dele precisa autorizar o IP real do encaminhamento.
Antes de SRS
Envelope From:alice@example.comDepois de SRS
Envelope From:SRS0=HASH=TT=example.com=alice@your-forwarder.comO destinatário avalia SPF de
your-forwarder.com. Confira autorização do IP e resultado efetivo da avaliação.
SRS não resolve sozinho o alinhamento DMARC. From: mantém alice@example.com, enquanto envelope usa your-forwarder.com, sem alinhamento entre esses domínios. DKIM original válido e alinhado pode satisfazer DMARC; alterar partes assinadas pode impedir isso. Veja encaminhamento com SRS.
ARC (Authenticated Received Chain)
ARC permite transmitir resultados anteriores de autenticação em cabeçalhos assinados. Uma declaração não estabelece confiança automaticamente: cadeia e identidade do assinante precisam ser verificadas.
O destinatário pode considerar uma cadeia ARC válida de um intermediário confiável. RFC 8617 define o mecanismo; entrega ainda depende das políticas do destinatário.
Validade criptográfica, confiança no assinante e reputação de envio são relacionadas, mas distintas. Receber milhares de mensagens não prova sozinho que um intermediário não seja confiável. Evite backscatter e encaminhamento abusivo e confira decisões reais sem prometer entrega por ARC.
Configurar catch-all com controles
Para recuperar erros, migrar ou manter compatibilidade, defina escopo, responsáveis e filtros. Estas três estratégias oferecem critérios, não isolamento ou segurança automáticos.
Estratégia A: destino de revisão separado
Use recebimento controlado com permissões e revisão adequadas. Uma caixa de quarentena não é sozinha uma sandbox de segurança.
- Crie
catchall-quarantine@yourdomain.comcom acesso restrito, sem Send As, encaminhamento nem respostas automáticas. - Direcione apenas destinatários desconhecidos do domínio autorizado a essa caixa.
- No Microsoft 365, atribuir SCL 9 solicita classificar a mensagem como spam altamente provável; a política define spam, quarentena e notificações. Não aplique cegamente a todo catch-all: confira o efeito com o administrador.
- Uma revisão semanal pode servir de referência; ajuste ao tráfego e urgência sem ignorar mensagens legítimas pendentes.
No TrekMail, confira destino dedicado e visualizações disponíveis. Uma visualização filtrada não isola armazenamento nem permissões: revise acesso, filtros, cota e busca de mensagens mal direcionadas.
Estratégia B: Microsoft 365, DBEB e Internal Relay
Para domínios autoritativos, DBEB (Directory-Based Edge Blocking) pode rejeitar destinatários desconhecidos conforme o diretório. Confira configuração e presença de todos os endereços válidos.
Internal Relay Mode desativa DBEB sem criar catch-all sozinho. Diretório, conectores, rotas e prevenção de loops devem atender à topologia. Não mude o tipo do domínio apenas para admitir desconhecidos: um administrador autorizado precisa revisar o desenho e a carga.
Estratégia C: padrões limitados no Postfix
Padrões parciais precisam de mapa compatível, como PCRE ou regexp, revisado e ancorado corretamente. Num mapa hash comum, o exemplo seguinte é literal, não um padrão curinga funcional:
# /etc/postfix/virtual
sales-*@yourdomain.com sales-bucket@yourdomain.com
Um padrão real revisado poderia cobrir sales-q1@, sales-webinar@ e sales-2026@ sem admitir admin@ ou hr@. O mapa hash mostrado não faz isso automaticamente. Confira ancoragem, domínio, expansão de aliases e loops antes de outra implementação.
| Estratégia | Mensagens indesejadas | Administração | Usos a avaliar |
|---|---|---|---|
| Catch-all completo → caixa ativa | Volume pode aumentar | Revisão e filtros contínuos | Com controles adequados ao caso |
| Destino de revisão | Depende de filtros e acesso | Revisão conforme necessidade | Erros e migrações |
| Internal Relay + SCL=9 (M365) | Não é receita catch-all autônoma | Revisão de políticas e topologia | Desenhos Exchange justificados |
| Padrões parciais Postfix | Menos destinatários arbitrários | Manutenção de mapa compatível | Endereços de campanha delimitados |
| Sem catch-all, com aliases explícitos | Spam ainda pode ocorrer | Gestão de endereços e filtros | Destinatários conhecidos |
Aliases e rotas explícitas como alternativa
Aliases explícitos definem endereços e responsáveis e limitam destinatários arbitrários. Podem atender a muitas necessidades sem catch-all, mas não eliminam spam, falhas de autenticação ou obrigações de proteção de dados.
Aliases, caixas e catch-all: critérios de decisão
| Alias explícito | Caixa completa | Destino catch-all | |
|---|---|---|---|
| Armazenamento | Normalmente usa o destino, não outra caixa | Sim, conforme serviço | Conforme destino e retenção |
| Exposição a spam | Endereço conhecido; exige filtros | Endereço conhecido; exige filtros | Inclui destinatários desconhecidos |
| Autenticação | Revisar quando há encaminhamento | Verificar entrada e saída | Revisar encaminhamento e identidades |
| Custo por usuário | Conforme plano e limites | $6-30/mês como referência histórica de licenças | Custo operacional e condições do serviço |
| Dados pessoais | Definir finalidade, acesso e retenção | Definir finalidade, acesso e retenção | Pode coletar informações desnecessárias |
| Responsabilidade | Definir proprietário e rota | Definir proprietário e acesso | Definir revisão e responsáveis |
Inclua filtragem, armazenamento, suporte e acompanhamento de reputação na comparação. O impacto depende do tráfego e serviço. Para escolher alias ou caixa, veja definição, configuração e usos dos aliases de e-mail.
Quais endereços criar?
Liste endereços realmente usados. Estes cinco exemplos não são um máximo suficiente para toda empresa:
hello@ouinfo@: consultas gerais ao responsável designado.support@: suporte ao helpdesk ou caixa compartilhada.billing@: faturas e pagamentos ao financeiro.jobs@oucareers@: recrutamento ao RH ou integração ATS autorizada.noreply@: envio transacional; defina tratamento das respostas legítimas sem excluí-las cegamente.
Cinco aliases podem atender ao exemplo, mas outros negócios precisam de mais. Para helo@ em vez de hello@, rejeição 550 pode permitir correção pelo remetente, sem garantir que ele a faça. Evite deixar correio útil três semanas sem revisão numa caixa comum.
O modelo do TrekMail para catch-all
Confira quais planos TrekMail permitem catch-all e seus destinos, limites e preços atuais. A cobrança pode facilitar mais endereços explícitos sem tornar catch-all necessário ou eliminar riscos.
Exemplo de licenças por usuário
Com referência histórica de $6-30/mês por caixa, support@, billing@ e jobs@ com três novas licenças poderiam acrescentar até $90/mês. Confira preços e alternativas de aliases ou recursos compartilhados antes de mudar rotas para economizar.
Compare o plano TrekMail
Revise espaço agrupado por conta, domínios, caixas e limites. Como referências históricas, Starter a $3.50/mês menciona 50 domínios e Pro a $10/mês menciona 100. Confira condições atuais e custos de endereços adicionais sem presumir capacidade ilimitada ou gratuidade universal.
Para migração ou compatibilidade, configure destino separado com acesso e filtros adequados. Caixas distintas não garantem isolamento de cota ou recursos compartilhados. Leia a documentação da caixa catch-all do TrekMail e confira configuração atual.
Revise duas possibilidades conforme o plano atual: encaminhamento de caixa a vários destinos com cópia local opcional e destino catch-all externo quando permitido. Pro e Agency são citados para essa segunda opção, mas permissões, rotas e condições precisam ser verificadas. Um domínio estacionado também exige recebimento e autenticação controlados. Veja roteamento de domínio sem caixa local.
Para comparar opções, consulte um possível teste gratuito de 14 dias e requisitos atuais, incluindo cartão quando necessário. No modelo Nano com SMTP próprio, configure esse serviço para todas as saídas e respostas.
Perguntas frequentes
Estas perguntas ajudam a avaliar ou remover catch-all e preparar as verificações necessárias.
O que é e-mail catch-all?
É uma regra do servidor que direciona destinatários desconhecidos do domínio a uma rota padrão. Em vez de rejeitar com 550, pode admitir o destinatário e depois aplicar filtros e aceitação final da mensagem. Accept-all e roteamento curinga são nomes de interfaces; confira o comportamento real.
É seguro usar catch-all?
Depende de finalidade, filtros, acesso, volume, retenção e destino. Pode aumentar carga ou avisos indevidos, sem causar sozinho falhas de autenticação ou infrações. Use destino controlado e revisão adequada à urgência, sem aplicar cegamente pontuação máxima nem ignorar correio legítimo.
Pode afetar a entregabilidade de saída?
Indiretamente, se avisos chegam a identidades falsificadas ou tráfego abusivo é encaminhado. Autenticação exige revisar envelope, assinaturas e From original; relatórios não dizem respeito sempre ao intermediário. Investigue resultados concretos em vez de presumir degradação inevitável.
Qual a diferença entre catch-all e alias?
Alias define endereço e rota. Catch-all admite destinatários desconhecidos do domínio conforme políticas e os direciona ao destino padrão. Cinco aliases podem atender a um exemplo simples; necessidades reais definem quantos criar.
Pode usar com Google Workspace ou Microsoft 365?
Confira recursos atuais e permissões. No Google Workspace, prepare uma regra de entrada em Gmail → Roteamento para destinatários inativos ou desconhecidos que substitua o destinatário de envelope pela caixa escolhida, sem incluir usuários ativos ou grupos. No Microsoft 365, Internal Relay desativa DBEB sem criar catch-all sozinho: exige diretório, conectores e rotas compatíveis sem loops. Um administrador autorizado deve validar a topologia antes de alterá-la. Aliases e caixas compartilhadas podem evitar licenças adicionais conforme condições.
Como desativar catch-all?
Identifique primeiro destinatários legítimos e prepare aliases ou caixas. No cPanel/WHM, revise Início → E-mail → Endereço padrão e escolha rejeição SMTP com erro, não aceitação seguida de exclusão silenciosa. No Google Workspace, revise Gmail → Roteamento, ou Roteamento padrão se ali houver uma regra antiga, e remova a regra após verificar rotas. No Microsoft 365, use modo autoritativo apenas com diretório completo e conectores revisados. No TrekMail, confira Domínios → domínio → Roteamento, Conexão nas interfaces anteriores, → Caixa catch-all → Sem catch-all. Uma janela de 24-48 horas pode orientar acompanhamento, não é prazo obrigatório de estabilização.
O que usar no lugar?
Defina aliases e rotas para os endereços realmente usados. Cinco ou menos podem bastar num caso simples, não em todos. Compare caixas compartilhadas, licenças e planos atuais. Escolha conforme recebimento, responsáveis e controles, sem presumir que cobrança elimina problemas de autenticação ou reputação.
