Um endereço de e-mail catch-all direciona a um destino mensagens para destinatários desconhecidos do seu domínio. Alguém escreve slaes@yourcompany.com em vez de sales@ e a regra pode recuperar esse contato. É útil, mas não significa aceitar qualquer mensagem sem filtros ou condições.
Essa rede de proteção amplia o recebimento para endereços não criados. Pode aumentar a carga de spam e exige controlar rejeições posteriores e autenticação quando há encaminhamento. A conveniência precisa ser avaliada junto do trabalho de filtragem, armazenamento e acompanhamento.
Este guia explica o comportamento SMTP, três riscos a revisar e alternativas para manter o controle do correio. Para rotas e configuração, consulte catch-all do domínio sem perder o controle.
O que é um endereço catch-all?
Um catch-all, também chamado endereço curinga, direciona destinatários desconhecidos de um domínio válido a uma caixa ou rota específica. O servidor pode responder “250 OK” a RCPT TO em vez de “550 User unknown”. Aceitar um destinatário não equivale a aceitar definitivamente a mensagem depois de DATA: filtros e outras políticas continuam relevantes.
Rejeitar destinatários desconhecidos durante SMTP, antes de receber seu conteúdo, é uma política de rejeição por padrão. O catch-all introduz aceitação de destinatários desconhecidos, não uma obrigação de aceitar malware ou spam. Erros legítimos de digitação e endereços inventados podem compartilhar destino se a mensagem passar pelos controles aplicáveis.
Pode ajudar numa migração ou num uso permanente bem delimitado. Os controles precisam acompanhar o tráfego real.
Como o catch-all funciona no SMTP
A distinção aparece em RCPT TO, definido na RFC 5321. O servidor decide sobre aquele destinatário antes de receber o conteúdo da transação. Os exemplos simplificam a troca: comandos e respostas já circularam, e a aceitação final da mensagem vem depois.
Sem catch-all: rejeição do destinatário desconhecido
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 550 5.1.1 User unknown
RESULT: Connection closed. Zero data transferred.A rejeição vale para esse destinatário; não obriga a fechar a conexão. O servidor remetente decide como avisar o usuário, sem necessariamente fazê-lo de imediato. Não se aceita conteúdo para o destinatário rejeitado, embora já tenha havido troca SMTP e a transação possa conter outros destinatários válidos.
Com catch-all: destinatário desconhecido admitido
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 250 2.1.5 OK
RESULT: Server accepts headers, body, and attachments.
Routing logic directs mail to the catch-all mailbox.A resposta admite o destinatário. O servidor pode examinar a mensagem durante DATA e rejeitá-la antes da aceitação final. Se a aceitar, terá de gerenciar conteúdo, filas, filtros e armazenamento. Rejeite tráfego indesejado durante SMTP quando adequado ou mantenha quarentena segura sem avisos a identidades falsificadas.
Três riscos operacionais a revisar
Revise três áreas: carga de sondagens de endereços, avisos de não entrega enviados a terceiros inocentes e autenticação no encaminhamento. Os riscos dependem da implementação e dos controles.
1. Ataques de coleta de endereços (DHA)
Atacantes podem testar milhares de nomes comuns: admin, invoice, hr, accounts, david, noreply, info, billing. Buscam descobrir quais endereços existem e enviar às contas que parecem válidas.
Sem catch-all, respostas 550 podem revelar endereços inexistentes, mas não obrigam o atacante a sair. Se todas as sondagens recebem 250 OK, fica mais difícil distinguir contas criadas de endereços inventados. Essa menor exposição do diretório pode vir acompanhada de mais carga de recebimento e filtragem. Milhares de mensagens para destinatários fictícios podem dificultar encontrar o correio útil.
2. Backscatter e reputação
Há backscatter quando uma mensagem aceita gera depois um aviso de não entrega para uma identidade de envelope falsificada, prejudicando um terceiro. Esse tráfego pode afetar a reputação e aparecer em listas de bloqueio como ips.backscatterer.org.
Exemplo de configuração problemática:
- Um atacante envia malware a random@yourdomain.com com MAIL FROM falsificado como innocent@gmail.com.
- O catch-all admite o destinatário e o servidor aceita depois a mensagem sem rejeitá-la durante SMTP.
- Uma análise posterior detecta malware e sinaliza falha interna.
- Se o servidor gerar um aviso de não entrega (NDR) para innocent@gmail.com, ele chegará a quem não enviou a mensagem.
- O destinatário recebe uma devolução não solicitada, que seu serviço pode considerar tráfego abusivo.
Volume elevado pode prejudicar a reputação ou contribuir para bloqueios. Prefira rejeição durante SMTP ou quarentena segura sem devoluções nem respostas automáticas a identidades falsificadas.
3. Encaminhamento e autenticação SPF
Alguns administradores encaminham *@company.com para Gmail pessoal. O catch-all não quebra SPF por si só: o encaminhamento acrescenta outro servidor e precisa ser avaliado com as identidades SMTP e os resultados do destinatário.
Se o intermediário mantiver o MAIL FROM original, como bankofamerica.com, Gmail pode avaliar um IP não autorizado pelo SPF daquele domínio. O encaminhamento com SRS (Sender Rewriting Scheme) reescreve o envelope; o SPF do domínio utilizado deve autorizar o IP do intermediário. Isso não alinha automaticamente SPF ao From original. DKIM válido e alinhado pode permitir DMARC sem SRS nem ARC. ARC exige cadeia validada e assinante confiável para o destinatário, sem garantir aceitação. Examine logs, avisos e classificação da mensagem.
Alternativas ao catch-all
Aliases explícitos e endereçamento com etiquetas podem atender a muitas necessidades sem admitir destinatários arbitrários. Confira compatibilidade e comportamento no serviço. Um catch-all também pode ser adequado com objetivo claro e controles apropriados.
| Característica | Catch-all | Aliases explícitos | Endereçamento com etiquetas |
|---|---|---|---|
| Sintaxe | *@domain.com | sales@domain.com | user+tag@domain.com |
| Destinatários admitidos | Inclui desconhecidos do domínio, sujeito a controles | Endereços configurados conforme a rota | Etiquetas de destinatários base válidos, se houver suporte |
| Risco de spam | Pode aumentar a carga | Menos endereços admitidos; filtros continuam necessários | Depende de compatibilidade, exposição e filtros |
| Custo no TrekMail | Verificar disponibilidade e condições do plano | Verificar custos e limites atuais | Verificar suporte e condições atuais |
Aliases explícitos definem quais endereços são válidos e permitem rejeitar os demais conforme a configuração SMTP. São uma base prática para muitas operações estáveis. Para organizá-los e distinguir alias de caixa, leia encaminhamento de aliases de e-mail e alias do domínio ou caixa de e-mail.
Licenças: compare a necessidade real de caixas
Preço por usuário pode incentivar a busca de alternativas. Num exemplo histórico de $6/usuário/mês no Google Workspace, sales@, support@ e billing@ como caixas com licenças independentes custariam $18/mês para três endereços. Aliases e caixas compartilhadas podem ter condições diferentes: catch-all não é uma necessidade por princípio.
O armazenamento compartilhado do TrekMail pode mudar o cálculo. Confira a capacidade agrupada da conta, as cotas individuais das caixas, as permissões e os limites do plano atual, sem presumir caixas adicionais gratuitas ou ilimitadas em qualquer modalidade.
| Exemplo histórico de licenças por usuário | Referência histórica do TrekMail | |
|---|---|---|
| 3 caixas funcionais | $18/mês (Google Workspace, exemplo) | $3.50/mês no total (Starter, referência histórica) |
| 50 caixas | $300/mês no exemplo | $3.50/mês no total como referência histórica |
| Necessidade de catch-all | Depende do desenho; aliases e recursos compartilhados podem servir | Depende das necessidades, funções e limites atuais |
| Comportamento SMTP | Pode rejeitar destinatários desconhecidos | Verificar validação e rotas configuradas |
A referência histórica de Starter a $3.50/mês menciona até 50 domínios e 100 caixas por domínio; confira preços e limites vigentes. Configure sales@, support@, billing@, info@ e os endereços realmente necessários. A validação explícita limita destinatários arbitrários, com filtros e controles que precisam ser mantidos.
Uma caixa de revisão para o catch-all
Numa migração com diretório incompleto, recuperar mensagens legítimas para endereços antigos pode ajudar. Use destino separado com acesso restrito. Chamá-lo de quarentena não cria um ambiente isolado seguro: filtros, permissões e cuidado com anexos continuam necessários.
- Crie uma caixa dedicada: catchall-quarantine@yourdomain.com, separada da caixa principal e com acesso limitado.
- Configure a rota: envie apenas destinatários desconhecidos do domínio autorizado a essa caixa.
- Evite notificações e respostas: confira os filtros e avisos do cliente, desative encaminhamentos e respostas automáticas da caixa e evite devoluções a identidades falsificadas, sem suprimir os avisos legítimos de não entrega que forem necessários.
- Revise semanalmente: identifique correio legítimo e crie um alias após verificar quem deve recebê-lo.
- Defina um critério de encerramento: 30 dias sem correio legítimo podem orientar o planejamento; decida conforme os ciclos de tráfego e as necessidades reais.
Assim, o catch-all pode ser uma ferramenta temporária de diagnóstico. Identifique endereços antigos ativos, crie aliases autorizados e reavalie a regra. Um uso permanente exige justificativa e acompanhamento próprios.
Agências: cobertura com endereços explícitos
Ao gerenciar 100+ domínios, preparar aliases padrão pode dar trabalho. Confira se painel e plano atuais do TrekMail oferecem modelos ou operações em lote. Uma lista como postmaster@, abuse@, accounts@, info@ deve atender a cada cliente e suas permissões. Verifique resultados antes de ampliar o alcance de uma operação.
RFC 2142 descreve caixas de contato conforme serviços e responsabilidades aplicáveis. postmaster@ é obrigatório para domínios atendidos por um serviço SMTP ativo de entrega ou retransmissão; abuse@ tem escopo ligado ao serviço e à função correspondentes. Confira acesso, responsáveis e funcionamento sem depender do catch-all.
Quando catch-all pode ser útil
Estes são três exemplos de usos a delimitar:
- Migração ativa: você sai de um sistema antigo e ainda não tem diretório completo.
- Aquisição de domínio: precisa revisar tráfego histórico desconhecido antes de escolher os endereços a manter.
- Ambientes de teste: endereços inventados devem receber num domínio de teste sem criação individual.
Nos três casos, limite o escopo, use destino controlado e revise quando desativar a regra. Há outros usos legítimos: uma configuração permanente bem administrada pode servir quando riscos e objetivos estão claros.
Avalie catch-all por utilidade e custos operacionais
Recuperar um erro de digitação pode ser útil, mas três áreas exigem acompanhamento: carga de spam, backscatter causado por avisos posteriores a identidades falsificadas e autenticação do encaminhamento. Avalie cada uma com tráfego e configuração reais.
Se a motivação for custo, compare licenças, aliases, recursos compartilhados e armazenamento agrupado. O TrekMail pode permitir uma estrutura adequada conforme o plano vigente. Sales@, support@, billing@ e mais 47 endereços são exemplo de organização, não garantia atual de capacidade ou preço único.
Consulte um possível teste gratuito de 14 dias e os requisitos atuais de cartão. Confira também disponibilidade e condições Free/Nano, incluindo modalidade sem cartão nem teste. Somente no modelo Nano descrito você precisa de SMTP externo próprio para todos os envios e respostas; o SMTP gerenciado das modalidades pagas depende das permissões atuais e da configuração de um cliente compatível.
