Encaminhamento por alias: riscos e como corrigir

Você configurou o encaminhamento de e-mail por alias: contact@yourdomain.com aponta para o seu Gmail. Tudo funcionou durante meses. Então um cliente enviou uma mensagem sobre um contrato assinado. Você nunca a recebeu. Só descobriu três semanas depois, quando o negócio já havia sido perdido.

Na sua conta, nenhuma notificação de falha, nenhuma mensagem na pasta de spam. Apenas um e-mail ausente e uma oportunidade perdida.

Isso pode acontecer quando a combinação de alias e encaminhamento encontra políticas DMARC rigorosas. A falha pode passar despercebida pelo destinatário. Entender o funcionamento dos protocolos ajuda a reduzir o risco. Este guia explica os pontos de falha, apresenta os códigos de erro que você deve procurar nos logs e descreve dois mecanismos que ajudam a autenticar mensagens encaminhadas.

Se precisar começar pela configuração básica, leia o guia de configuração e correção do encaminhamento de e-mail. Este artigo trata das possíveis falhas.

O que o encaminhamento por alias realmente faz

Um alias de e-mail é uma regra de roteamento: não tem caixa de entrada, login ou cota de armazenamento próprios. Quando alguém escreve para sales@yourdomain.com, seu servidor recebe a mensagem e a encaminha para outro destino, geralmente uma conta pessoal do Gmail ou Outlook. É uma solução prática muito usada por pequenas empresas para endereços de função. No encaminhamento externo, porém, mensagens podem se perder sem que o destinatário perceba.

O encaminhamento externo por alias abre uma nova conexão SMTP para enviar a mensagem recebida ao destino. Esse novo salto pode comprometer a autenticação: seu servidor está transmitindo uma mensagem que não criou e precisa preservar e avaliar informações de autenticação de terceiros.

As duas camadas de um e-mail

Todo e-mail tem duas camadas distintas que raramente aparecem no uso cotidiano. Entender essa diferença explica por que o encaminhamento pode comprometer a autenticação.

Quando client@bank.com escreve para seu alias sales@yourdomain.com, o servidor de bank.com envia a mensagem. No exemplo, SPF passa porque bank.com autorizou seus próprios IPs de envio.

Quando seu servidor encaminha a mensagem para founder@gmail.com, abre outra conexão SMTP. Agora é o seu servidor que estabelece a conexão. Sem reescrita, o remetente do envelope continua sendo o original; o cabeçalho ainda mostra client@bank.com.

O Gmail verifica SPF para bank.com usando o IP do seu servidor, que bank.com não autorizou. SPF falha. Se o registro DMARC de bank.com tiver p=reject e também não houver uma assinatura DKIM válida e alinhada, o Gmail poderá rejeitar a mensagem conforme sua política de recebimento. Isso não significa necessariamente exclusão imediata sem aviso: uma notificação de falha pode chegar ao remetente original, enquanto você, destinatário do alias, não recebe nenhuma informação.

Três tipos de falha no encaminhamento por alias

O encaminhamento pode falhar em camadas diferentes. Cada tipo de falha tem sintomas e medidas de correção próprios.

1. Falha SPF

SPF verifica se o IP da conexão SMTP está autorizado pelo registro DNS do domínio de MAIL FROM ou HELO. No novo salto do encaminhamento, o destino vê seu IP em vez do IP original. Se o remetente do envelope permanecer inalterado e seu IP não estiver autorizado para esse domínio, SPF falhará no destino. Esse é o primeiro problema de autenticação.

2. Rejeição DMARC

DMARC exige que SPF ou DKIM passe e esteja alinhado com o domínio do cabeçalho From:. No cenário descrito, SPF já falhou. Se conteúdos assinados forem alterados durante o trajeto, por exemplo pela inclusão de rodapés ou pela modificação de cabeçalhos assinados, a assinatura DKIM original também poderá falhar. Sem autenticação válida e alinhada, o destinatário pode aplicar a política DMARC: p=quarantine recomenda quarentena, frequentemente a pasta de spam; p=reject recomenda rejeição.

3. Descarte sem aviso ao destinatário

O pior resultado é o servidor de destino descartar a mensagem sem enviar um NDR, ou relatório de não entrega. O remetente original não recebe uma notificação, e nada aparece na sua caixa de entrada. Esse comportamento depende do sistema que recebe a mensagem. Para você, a falha pode permanecer invisível, fazendo o encaminhamento parecer confiável até faltar um e-mail importante.

Códigos de erro para procurar nos logs SMTP

Se mensagens encaminhadas estão desaparecendo, consulte seus logs SMTP ou peça os registros de NDR ao provedor. Estes três códigos podem indicar problemas de encaminhamento.

Bloqueio do Microsoft 365 (5.7.520)

O Microsoft Exchange Online pode bloquear o encaminhamento externo automático pelas políticas de segurança da organização. A configuração padrão usual busca evitar a saída não autorizada de dados, mas também pode bloquear encaminhamentos legítimos. Verifique a configuração atual do seu ambiente.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Correção: no portal Microsoft 365 Defender, revise a política de filtragem de spam de saída e autorize encaminhamentos externos apenas nos casos aprovados. Regras de redirecionamento também precisam respeitar as políticas vigentes; não são uma forma garantida de contornar um bloqueio de segurança.

Loop de roteamento (5.4.14 / 5.4.6)

Um loop pode ocorrer quando dois aliases encaminham mensagens um para o outro ou quando um catch-all encaminha para um endereço que volta a enviar mensagens ao seu domínio.

554 5.4.14 Hop count exceeded - possible mail loop

Correção: revise as regras de transporte. Uma armadilha comum é um catch-all em *@yourdomain.com cujo destino responde automaticamente a toda mensagem recebida. Com regras de retorno inadequadas, essa combinação pode gerar tráfego repetido; uma resposta automática sozinha não é necessariamente um loop de transporte.

Falha de autenticação DMARC (550 5.7.1)

O servidor de destino rejeitou a mensagem encaminhada porque não encontrou autenticação DMARC válida e alinhada ao domínio do remetente. O encaminhamento pode ter causado essa falha.

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

Esse erro pode ocorrer quando o encaminhamento compromete DMARC, mas sozinho não comprova a causa. Confira cabeçalhos e logs, SRS e ARC no servidor de e-mail, a assinatura DKIM original e os registros DNS relevantes. Um único ajuste DNS não é uma solução universal.

As medidas: SRS e ARC

Uma lista de permissões local não substitui a política do servidor de destino. Ele considera a política DMARC publicada pelo remetente original e suas próprias regras. SRS e ARC são mecanismos complementares no MTA, ou agente de transferência de mensagens, que podem ajudar no encaminhamento. Em um serviço hospedado, a implementação cabe ao provedor; eles não garantem a entrega.

SRS (Sender Rewriting Scheme)

SRS reescreve o remetente do envelope, representado no Return-Path, usando seu próprio domínio antes de encaminhar a mensagem. A verificação SPF no destino pode então passar, desde que seu servidor esteja corretamente autorizado no registro SPF desse domínio.

Sem SRS:
Envelope From: client@bank.com
IP de envio: seu servidor de encaminhamento
Resultado SPF no exemplo: FAIL, seu IP não está no registro de bank.com

Com SRS:
Envelope From: SRS0=Hash=TT=bank.com=client@yourdomain.com
IP de envio: seu servidor de encaminhamento
Resultado SPF no exemplo: PASS, seu IP está autorizado para yourdomain.com

SRS também inclui um hash e um carimbo de data e hora no endereço reescrito. A validação desses dados e um prazo de validade limitado, geralmente de alguns dias, ajudam a restringir a reutilização indevida. Essa proteção depende da implementação e não elimina todo risco de abuso.

ARC (Authenticated Received Chain)

SRS pode permitir que SPF passe no destino, mas não restaura o alinhamento DMARC de SPF. DMARC compara o domínio do cabeçalho From: (bank.com) com os resultados de autenticação. Com SRS, o envelope mostra yourdomain.com, mas From: continua mostrando bank.com. Os domínios não coincidem. O alinhamento SPF para DMARC falha; uma assinatura DKIM válida e alinhada ainda pode fazer DMARC passar.

ARC, definido na RFC 8617, acrescenta uma cadeia verificável de informações de autenticação. Seu servidor registra e sela os resultados observados no recebimento e assina o conjunto ARC antes de encaminhar. Assim, pode documentar que SPF e DKIM passaram quando a mensagem chegou, caso esse tenha sido o resultado real.

Gmail e Outlook podem considerar selos ARC de encaminhadores confiáveis na decisão de recebimento. Eles verificam a cadeia e podem usar os resultados originais documentados mesmo quando a verificação DMARC atual falha. A aceitação depende da confiança no encaminhador e das demais políticas do destinatário.

Nenhum dos mecanismos é apenas uma configuração DNS, embora a autenticação relacionada possa depender de registros DNS. Sem reescrita SRS e selos ARC na camada de transporte, o encaminhamento externo por alias pode ficar mais vulnerável a políticas DMARC rigorosas. O resultado também depende da preservação de uma assinatura DKIM válida e alinhada.

Duas armadilhas operacionais

Mesmo com SRS e ARC, duas configurações comuns ainda podem causar problemas.

Exposição do endereço pessoal nas respostas

O encaminhamento funciona apenas no sentido de recebimento. Quando você recebe uma mensagem encaminhada no Gmail e clica em Responder, o endereço From pode ser founder@gmail.com, não sales@yourdomain.com. O cliente acaba vendo seu endereço pessoal em vez do profissional.

Alternativa: no Gmail, configure “Enviar e-mail como” em Configurações → Contas. Informe o alias e as credenciais SMTP de saída do seu domínio, se essa configuração for suportada. Depois, confirme que o Gmail usa o servidor desejado e que as respostas mostram o endereço do domínio. Consulte os detalhes de conexão nas configurações do SMTP gerenciado do TrekMail.

Isso pode funcionar, mas o procedimento descrito acrescenta três etapas de configuração por conta. Quando você altera a senha SMTP, pode ser necessário atualizar também as credenciais salvas no Gmail.

A armadilha do catch-all encaminhado

Evite encaminhar um catch-all (*@yourdomain.com) para fora do domínio. Spammers testam partes locais aleatórias em domínios conhecidos, como billing@, admin@ e noreply12345@. O catch-all recebe essas tentativas e pode encaminhá-las ao destino externo.

Se o Gmail receber milhares de mensagens de spam por dia encaminhadas pelo seu servidor, a reputação do IP pode ser prejudicada. E-mails legítimos também podem começar a cair no spam, inclusive os enviados pelas suas caixas reais. Recuperar essa reputação pode levar semanas, depois de meses de construção.

Se precisar de um catch-all para receber mensagens de endereços não cadastrados, direcione-o a uma caixa local e faça a revisão manual. Veja a documentação de encaminhamento de caixas no TrekMail para configurar o recurso. A entrega local reduz a amplificação externa de spam, mas não substitui a filtragem e o acompanhamento.

Encaminhamento por alias ou caixa real: qual usar?

O guia de alias e caixa de e-mail no domínio apresenta a matriz de decisão completa. Aqui está o resumo específico para encaminhamento:

Evite usar o encaminhamento por alias como substituto permanente de uma caixa real apenas para reduzir custos. Se o provedor cobra por usuário, esse incentivo é compreensível. Se não cobra, a escolha pode criar trabalho operacional desnecessário: configurações extras, casos especiais e falhas de autenticação que aparecem justamente nas mensagens mais importantes.

Como o TrekMail trata o encaminhamento

Implementar SRS e ARC por conta própria exige, conforme a arquitetura, configurar o roteamento do Postfix e os serviços SRS, administrar chaves de assinatura ARC e acompanhar sua rotação. É uma tarefa de administração de servidores que muitos operadores preferem deixar com o provedor.

Na descrição de recursos da fonte, o encaminhamento de caixas dos planos Pro e Agency do TrekMail usa uma camada de transporte com OpenARC. A aplicação automática de selos ARC está prevista para os encaminhamentos suportados; você informa o destino no painel. Esse processamento ocorre no MTA, não por uma simples mudança no DNS. Confira a disponibilidade atual do recurso e o suporte específico a SRS e ARC.

Em muitos casos, a opção mais simples é não encaminhar. O modelo de preço fixo descrito na fonte para o TrekMail não cobra separadamente por usuário ou caixa. Nesse modelo, o preço de uma caixa support@yourdomain.com não muda apenas porque uma pessoa ou dez pessoas a acessam; ainda é necessário respeitar os limites do plano e administrar os acessos com segurança. Dentro dessas condições, deixa de existir o incentivo de custo para encaminhar a uma conta pessoal do Gmail e configurar “Enviar como” a cada novo domínio.

• Pequenas e médias empresas: dê a support@ um acesso IMAP próprio. O acesso direto simplifica a separação das identidades. Confira o remetente das respostas no cliente; assim, muitas vezes é possível dispensar uma configuração separada de “Enviar como”.
• Agências: crie caixas dedicadas para os endereços de função dos clientes, em vez de encaminhar para contas pessoais da equipe. Com permissões adequadas e clientes bem configurados, a equipe pode acessar diretamente e responder com um remetente consistente.

Se também estiver configurando SPF, DKIM e DMARC do zero nos seus domínios, o guia de fundamentos de segurança para e-mail empresarial reúne a configuração básica de autenticação.

Conclusão

O encaminhamento de e-mail por alias pode atender a usos pouco críticos. Estas situações aumentam o risco:

1. O remetente original usa DMARC rigoroso (p=quarantine ou p=reject) e não há autenticação válida e alinhada
2. Seu servidor não implementa SRS, de modo que SPF pode falhar no destino se o remetente do envelope permanecer inalterado
3. Seu servidor não implementa ARC; SRS sozinho não restaura o alinhamento SPF para DMARC, mas DKIM válido e alinhado preservado pode fazer DMARC passar
4. Você encaminha um catch-all externamente e pode amplificar spam
5. Você precisa responder com o alias, algo que o encaminhamento sozinho não oferece

As medidas são obter suporte adequado aos protocolos no provedor, especialmente SRS e ARC, ou substituir o alias de encaminhamento por uma caixa com login direto. Com cobrança por usuário, o encaminhamento parece atraente no papel. No modelo de preço fixo do TrekMail descrito na fonte, esse incentivo de custo deixa de existir dentro dos limites de cada plano.

Na fonte, o plano Pro do TrekMail começa em $10/mês: até 100 domínios, encaminhamento de caixas com selos ARC e nenhuma cobrança separada por caixa. O teste gratuito de 14 dias descrito ali exige cartão de crédito; o Nano não. Confira os preços, recursos e condições atuais.