Caixa catch-all: 3 padrões seguros de configuração

Uma caixa catch-all instrui o servidor a aceitar toda mensagem enviada ao domínio, mesmo quando o destinatário não existe. Em vez de rejeitar typo@yourdomain.com com um erro 550, ele aceita o conteúdo. Isso pode ser útil, mas também abre caminho para spam, phishing e ataques de coleta de diretórios.

Sem proteções, um catch-all pode aumentar rapidamente o lixo eletrônico e prejudicar a reputação do domínio, conforme o volume, os filtros e a resposta operacional. Ativá-lo é simples; isolá-lo e administrá-lo corretamente é a parte difícil.

Este guia apresenta três padrões de isolamento para reduzir os riscos em Microsoft 365, uma stack Linux ou Google Workspace. A implementação exata depende da versão, da topologia e das políticas do provedor. Se você ainda não sabe se precisa do recurso, leia primeiro nossa explicação sobre e-mail catch-all de domínio.

O que é uma caixa catch-all?

É uma caixa que recebe as mensagens enviadas ao domínio quando nenhum endereço existente corresponde ao destinatário. Se alguém escreve para misspelled-name@yourdomain.com, a mensagem chega à caixa designada em vez de ser rejeitada.

O servidor passa a aceitar tudo que corresponda à regra. Bots de spam, tentativas de phishing e varreduras automatizadas podem receber uma resposta 250 OK. Sem isolamento e filtragem adequados, esse tráfego se mistura ao e-mail legítimo e pode afetar segurança, operação e reputação.

A regra principal: nunca encaminhe para uma caixa principal

Em determinadas configurações, o tráfego catch-all ignora o bloqueio de borda baseado em diretório (DBEB), fazendo o servidor aceitar o conteúdo antes de validar um destinatário normal. Direcioná-lo para ceo@company.com ou outra caixa ativa cria risco de segurança e ruído operacional.

Todos os padrões abaixo seguem o mesmo princípio: isolar o fluxo catch-all do e-mail de produção.

Padrão 1: depósito de quarentena (Microsoft 365 / Exchange)

Essa abordagem pode servir a organizações que precisam preservar e-mails catch-all por motivos jurídicos ou de descoberta, mas não querem alertas constantes. Ela deve ser validada conforme as obrigações de retenção e conformidade.

Como funciona

1. Recebimento: o servidor aceita mensagens para destinatários desconhecidos.
2. Marcação: uma regra de transporte identifica uma mensagem externa que não foi destinada a um usuário válido.
3. Classificação: a regra define o nível de confiança de spam (SCL) como 9, uma pontuação alta.
4. Armazenamento: a mensagem segue para uma caixa compartilhada como catchall-sink@yourdomain.com.

Configuração no PowerShell

Primeiro, defina o domínio como "Internal Relay" no centro de administração do Exchange, o que desativa o DBEB para esse fluxo. Depois de avaliar o efeito no ambiente, execute:

# Create the sink (shared mailbox - no license needed)
New-Mailbox -Shared -Name "CatchAll Sink" -PrimarySmtpAddress catchall-sink@yourdomain.com

# Create the transport rule
New-TransportRule -Name "Catch-All Routing & Suppression"
    -FromScope "NotInOrganization"
    -SentTo "catchall-sink@yourdomain.com"
    -RedirectMessageTo "catchall-sink@yourdomain.com"
    -SetSCL 9
    -ExceptIfRecipientBelongsTo "All Valid Users Group"

Por que SCL 9? Nessa configuração, SCL 9 classifica as mensagens como lixo eletrônico de acordo com as políticas do Exchange. Revise a caixa em uma frequência definida, por exemplo semanalmente, e confirme se retenção e exceções funcionam como esperado.

Padrão 2: fluxo marcado (Postfix / Linux)

Em uma stack própria com Postfix e Dovecot, uma caixa separada pode ser desnecessária. Outra opção é inserir um cabeçalho e usar regras no servidor ou cliente para separar o tráfego.

Como funciona

1. Recebimento: luser_relay aceita a mensagem para destinatários locais desconhecidos.
2. Modificação: o MTA insere o cabeçalho X-Catch-All: True.
3. Filtragem: regras Sieve movem a mensagem para uma pasta exclusiva.

Configuração do Postfix

# /etc/postfix/main.cf
# Route unknown local users to a specific alias
luser_relay = catchall_alias

# /etc/postfix/virtual
# Map the alias to a real user
catchall_alias    realuser@yourdomain.com

Importante: luser_relay só funciona para domínios locais. Para vários domínios virtuais, use virtual_alias_maps com um curinga quando a configuração e a ordem dos mapas forem compatíveis:

# /etc/postfix/virtual
@example.com      realuser@example.com

Se você configurar encaminhamento de e-mail junto com regras catch-all, confirme que os mapas virtuais não se sobrepõem. Regras concorrentes podem enviar mensagens ao destino errado.

Filtro Sieve

Não dependa de uma inspeção visual para separar o tráfego. Automatize o filtro e teste os cabeçalhos realmente preservados pelo MTA:

if header :contains "X-Original-To" "catchall_alias" {
    fileinto "Junk/CatchAll";
    stop;
}

Padrão 3: curinga parcial (roteamento por expressão regular)

Essa abordagem é mais restritiva quando você não precisa de um catch-all completo. Em vez de aceitar *@domain.com, ela permite apenas padrões específicos, como sales-*@domain.com, e rejeita o restante.

Como funciona

Configure o MTA ou provedor para aceitar endereços que correspondam a uma expressão regular, como sales-webinar@ e sales-q1@, enquanto rejeita alvos de maior risco como admin@ ou hr@. A sintaxe e a disponibilidade variam entre provedores.

Configuração no Google Workspace

1. Acesse Apps > Google Workspace > Gmail > Default Routing.
2. Em Specify Envelope Recipients, selecione "Pattern Match".
3. Informe a expressão: ^sales-.*@yourdomain\.com$
4. Defina a ação para alterar o destinatário do envelope para sales-team@yourdomain.com.

Resultado esperado: sales-promo@yourdomain.com é aceito e admin@yourdomain.com é rejeitado com 550 quando a regra está ativa e nenhuma outra rota corresponde. Isso pode reduzir bastante a superfície exposta a ataques de coleta de diretórios.

Os endereços precisam funcionar como aliases de e-mail? É possível combinar curingas parciais com encaminhamento de aliases quando o provedor, a autenticação e as regras de entrega oferecem suporte.

Como evitar um loop de roteamento do catch-all

Um dos problemas mais perigosos é o loop de roteamento. Ele pode acontecer assim:

1. O catch-all aceita e-mail para ghost@domain.com.
2. Uma regra o encaminha automaticamente para external@gmail.com.
3. O Gmail o rejeita por falha de SPF/DMARC.
4. O Gmail devolve o NDR a ghost@domain.com.
5. O catch-all aceita a devolução.
6. A regra encaminha a devolução ao Gmail.
7. O ciclo continua até exceder MaxHopCount.

Podem aparecer erros como 5.4.14 Hop count exceeded ou 5.4.6 Routing loop detected. Em um domínio movimentado, isso pode aumentar a fila de saída e acionar bloqueios antispam em poucas horas, conforme os limites e controles do provedor.

Lista de prevenção

• Confira os cabeçalhos: verifique se o MTA respeita X-Loop e Delivered-To no caminho real.
• Bloqueie respostas automáticas: configure as regras para ignorar mensagens com o cabeçalho Auto-Submitted: auto-generated.
• Particularidade do Microsoft 365: a política de spam de saída normalmente bloqueia encaminhamento externo por padrão, com o erro 5.7.520 Access denied. Ativá-lo em Outbound Spam Filter Policy pode aumentar o risco de backscatter; avalie a troca e teste com cuidado.

Para conhecer outros riscos de encaminhamento entre provedores, veja nosso guia sobre encaminhamento de aliases de e-mail.

Por que tantos catch-alls existem e quando evitá-los

Muitas empresas ativam catch-all para reduzir licenças por usuário. Se você precisa de support@, billing@ e jobs@, mas não quer pagar $18/mês por usuário ao Google ou Microsoft, o recurso pode parecer uma solução inteligente.

Sem controles apropriados, ele vira dívida técnica e risco para a reputação.

Uma alternativa é um provedor que não cobre por usuário. A TrekMail descreve armazenamento compartilhado em vez de preço por assento:

• Plano Nano: $0, sem cartão.
• Starter: $3.50/mês com teste de 14 dias.
• Pro: $10/mês com teste de 14 dias.
• Agency: $23.25/mês com teste de 14 dias.

Dentro dos limites do plano, você pode criar support@, billing@ e jobs@ como caixas reais ou aliases no domínio personalizado. Como existem no diretório, um servidor configurado corretamente pode rejeitar destinatários inválidos na borda com uma resposta 550. Isso pode reduzir o risco para a reputação, que também depende de autenticação, conteúdo, volume e práticas de envio. Esses endereços não exigem os padrões catch-all acima.

Se você administra vários domínios como MSP ou empresa em expansão, compare custo e carga operacional antes de manter soluções improvisadas. A caixa catch-all da TrekMail oferece uma rede de segurança dentro dos limites do plano, mas ainda precisa de isolamento, filtros, monitoramento e DNS correto.

Conclusão

Uma caixa catch-all não é ruim por natureza. O risco está no catch-all sem proteções. Escolha um padrão compatível com sua stack, como depósito de quarentena no Exchange, fluxo marcado no Postfix ou curinga parcial no Workspace, e mantenha o tráfego separado do e-mail de produção. Sempre teste o comportamento real.

Outra opção é reduzir a complexidade usando endereços e aliases reais em um plano adequado ao volume. Antes de migrar, confirme preços, limites, armazenamento, DNS, autenticação e compatibilidade dos dados.