O encaminhamento de e-mail provavelmente é uma das primeiras configurações que você faz ao ter um domínio. E, com frequência, também é a primeira que para de funcionar sem dar sinais.
À primeira vista, parece simples: pegar a mensagem enviada para info@yourdomain.com e redirecioná-la para sua conta @gmail.com. Na prática, o encaminhamento é uma operação intermediária que entra em conflito direto com os principais modelos de confiança da internet atual: SPF, DKIM e DMARC. Quando a configuração está errada, o e-mail não necessariamente retorna com um erro evidente. Ele simplesmente desaparece.
Para quem fundou uma empresa, um encaminhamento quebrado pode significar perder mensagens de investidores. Para um provedor de serviços gerenciados que administra 50 domínios de clientes, pode significar uma enxurrada de chamados numa segunda-feira de manhã.
Este guia explica como o encaminhamento de e-mail realmente funciona no nível do protocolo, por que ele falha de maneiras previsíveis e como criar uma configuração capaz de lidar com políticas DMARC rígidas em 2026.
O modelo mental: por que encaminhar e-mail é mais complexo do que parece
Antes de corrigir um encaminhamento com defeito, você precisa entender o que acontece na camada SMTP. Não se trata de repassar um bilhete. É como reenviar uma carta pelo correio, e essa diferença é muito importante.
Quando o Servidor A envia um e-mail ao seu servidor, o Servidor B que fará o encaminhamento, e o Servidor B o retransmite ao destino final, o Servidor C, ocorre uma mudança crítica de identidade. O servidor de destino vê o endereço IP do Servidor B, não o do Servidor A. Essa é a origem de quase todas as falhas de encaminhamento.
Envelope e cabeçalho: as duas identidades de um e-mail
Todo e-mail tem duas camadas de identidade distintas, e o encaminhamento tira as duas de sincronia:
- O envelope (P1): usado pelos servidores de e-mail para rotear fisicamente a mensagem. Contém o
Return-Path. O SPF valida essa camada. - O cabeçalho (P2): exibido pelo cliente de e-mail como o endereço do remetente. As verificações de alinhamento do DKIM e do DMARC usam essa camada.
O problema acontece da seguinte forma. Ao encaminhar uma mensagem, seu servidor abre uma nova conexão SMTP com o destino. O SPF compara o IP de envio com o registro SPF do remetente original, mas o IP do seu encaminhador não está autorizado nesse registro. O SPF falha. Se o remetente original aplicar uma política DMARC rígida (p=reject) e você não tiver implementado o SRS, o servidor de destino recusará a mensagem.
Uma analogia concreta: Alice envia uma carta para Bob. Bob coloca a carta de Alice em um novo envelope, escreve seu próprio endereço de retorno e a envia para Carol. Carol pergunta a Alice se ela enviou a carta pelo endereço de Bob. Alice responde que não. Isso é uma falha de DMARC, e o servidor de e-mail de Carol age de acordo.
Entender essa separação entre envelope e cabeçalho é fundamental. Todas as correções deste guia partem desse conceito.
Encaminhamento, aliases e catch-all: entenda a diferença
Os administradores confundem esses três métodos de roteamento o tempo todo. Escolher o método errado é o caminho mais rápido para abrir um chamado de “e-mail desaparecido” que leva três horas para diagnosticar.
Encaminhamento de e-mail
Recebe um e-mail enviado a um endereço e o entrega a um servidor totalmente diferente, por exemplo, de contact@startup.com para founder@gmail.com. Há um salto de rede. As cadeias de autenticação se rompem se você não cuidar delas explicitamente. É a melhor opção para consolidar vários domínios em uma só caixa de entrada. Risco: alto sem tratamento adequado de SRS e ARC. Veja nossa análise detalhada sobre os prós e contras da combinação de alias e encaminhamento de e-mail.
Aliases de e-mail
Um alias é outro nome para uma caixa postal existente no mesmo servidor. As mensagens para support@company.com são entregues na mesma caixa postal de admin@company.com. Não há salto de rede nem mudança na autenticação. É ideal para uma pessoa que desempenha várias funções. Risco: baixo. Para comparar melhor quando os aliases deixam de ser suficientes e quando é necessário ter uma caixa postal completa, consulte nosso guia de decisão entre alias e caixa postal.
Catch-all (roteamento curinga)
Aceita qualquer e-mail enviado a um endereço inexistente no seu domínio, ou seja, *@domain.com. É útil para capturar erros de digitação ou endereços descartáveis de campanhas. Risco: crítico se estiver direcionado ao Gmail. Toda mensagem de spam enviada ao seu domínio chegará à sua caixa de entrada, e o Gmail acabará tratando seu servidor de encaminhamento como fonte de spam. Se você usa catch-all, mantenha essa função isolada. Abordamos todos os prós e contras em nosso guia para configurar e-mail empresarial.
| Método | Salto de rede? | Risco de autenticação | Mais indicado para |
|---|---|---|---|
| Encaminhamento | Sim | Alto (SPF/DMARC falha) | Roteamento entre domínios ou provedores |
| Alias | Não | Nenhum | Várias funções, mesma caixa postal |
| Catch-all | Depende da configuração | Crítico (ímã de spam) | Captura de erros de digitação, endereços descartáveis |
Padrões de configuração: o bom, o ruim e o que não funciona
Existem três maneiras de configurar o encaminhamento de e-mail. Duas delas costumam causar problemas. Uma foi projetada para operar de modo confiável em produção.
1. Roteamento no provedor (a forma correta)
Esse roteamento acontece no nível do MTA, antes de a mensagem chegar a qualquer caixa postal. O servidor recebe o e-mail, reescreve o envelope usando SRS e o retransmite imediatamente. Nesse modelo, não é necessária uma licença paga de caixa postal, e o encaminhamento normalmente não consome o armazenamento da caixa. SPF e ARC são tratados na camada de infraestrutura.
É nesse modelo que vale a pena investir. As rotas de encaminhamento da TrekMail funcionam assim: você define o destino, e a infraestrutura cuida dos cabeçalhos de autenticação. Consulte o guia de configuração do encaminhamento de caixa postal para ver as etapas exatas.
2. Regras da caixa postal (a forma antiga)
Você provisiona uma conta de usuário completa, paga $6-$30/month por uma licença de que não precisa, entra na conta e cria uma regra na caixa de entrada: “Se chegar uma mensagem, encaminhar para X.”
Há situações específicas em que isso faz sentido: encaminhamento condicional, como “encaminhar apenas faturas”, requisitos de auditoria ou casos em que a mensagem precisa ficar armazenada localmente antes da retransmissão. Porém, na maioria das configurações, você paga por um usuário apenas para rotear mensagens. Essa opção também rompe o DMARC como qualquer outro encaminhamento, e o Microsoft 365 pode bloquear o encaminhamento automático conforme o locatário e a política aplicável. Voltaremos a esse ponto na seção sobre modos de falha.
3. Encaminhamento no cliente (evite completamente)
É uma regra configurada no Outlook Desktop ou no Apple Mail do seu computador. Seu notebook precisa estar ligado, ativo e conectado à internet para que o encaminhamento ocorra. Não funciona enquanto você está viajando. Não funciona durante uma reinicialização. Não funciona às 2am quando chega aquele e-mail importante.
Não existe cenário de produção em que essa seja a escolha certa. Se você depende dela hoje, corrija isso agora.
Checklist para uma configuração segura
Antes de ativar uma rota de encaminhamento, faça estas quatro verificações. Ignorar qualquer uma delas trará problemas mais tarde.
1. Teste de loop
Confirme que o endereço de destino não encaminha de volta para a origem. A→B→A é um loop infinito. Servidores modernos detectam isso com limites de saltos e retornam uma NDR 5.4.14 hop count exceeded, mas, a essa altura, você já prejudicou sua reputação de envio. Mapeie as rotas antes de entrar em produção.
2. Teste de inspeção dos cabeçalhos
Envie uma mensagem de teste a partir de uma conta externa, como um Gmail pessoal, Yahoo ou qualquer conta fora do seu domínio, para o endereço encaminhado. No destino, abra todos os cabeçalhos da mensagem e localize Authentication-Results. O resultado esperado é spf=pass, decorrente da reescrita por SRS, ou dkim=pass. Se aparecer dmarc=fail, sua configuração de encaminhamento ainda não está pronta para produção.
3. Teste de Reply-To
Responda a uma mensagem encaminhada. A resposta vai para o remetente original ou para o endereço do encaminhador? Ela deve ir para o remetente original. Se for enviada ao encaminhador, a configuração do envelope está incorreta e criará um histórico de mensagens confuso para todos os envolvidos.
4. Verificação da política de saída
Se você usa o Microsoft 365 ou o Google Workspace como destino da retransmissão, confirme nas configurações do filtro antispam de saída se o encaminhamento automático é permitido. No M365, ele pode vir bloqueado conforme o locatário e a política aplicável. Se isso não estiver configurado corretamente, as mensagens encaminhadas poderão ser descartadas sem que o remetente original receba qualquer aviso.
Modos de falha comuns
Quando o encaminhamento de e-mail deixa de funcionar, a falha quase sempre assume uma destas formas específicas. Reconhecer o padrão poupa uma hora de leitura aleatória de cabeçalhos.
1. Descarte silencioso pelo DMARC
Essa é a causa mais comum de e-mails que desaparecem em 2026, e ela é invisível: nenhuma NDR, nenhum erro, nenhum sinal. A mensagem simplesmente não chega.
O cenário é o seguinte: um banco, processador de pagamentos ou fornecedor de SaaS envia ao seu domínio uma mensagem com a política DMARC rígida p=reject. Você a encaminha para o Gmail. O IP do seu encaminhador faz o SPF falhar. Se o servidor também alterar o corpo da mensagem, acrescentando um aviso, ou o assunto, adicionando [External], o DKIM também falha. Falha de SPF + falha de DKIM = falha de DMARC. O Gmail recusa a mensagem.
A correção é implementar o SRS no servidor de encaminhamento para que o SPF passe e garantir que o conteúdo não seja modificado, preservando o DKIM. Se você não controla a infraestrutura, precisa de um provedor de encaminhamento que cuide disso. Para entender melhor como as falhas de DMARC se manifestam especificamente nas cadeias de encaminhamento, veja nossa análise de DMARC e e-mail seguro.
2. Bloqueio 550 5.7.520 da Microsoft
Sintoma: o remetente original recebe uma NDR com o código 550 5.7.520 Access denied, your organization does not allow external forwarding.
É o filtro antispam de saída do M365 fazendo exatamente o que foi projetado para fazer: bloquear o encaminhamento automático a endereços externos. Para corrigir, acesse o portal do Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → Set "Automatic forwarding rules" to "On - forwarding is enabled."
O caminho não é intuitivo, e a Microsoft esconde essa opção. No entanto, o código de erro oferece um diagnóstico preciso: ao vê-lo, você sabe exatamente onde deve alterar a configuração.
3. Loop de resposta automática
O usuário A encaminha mensagens para o usuário B. O usuário B configura uma resposta automática. O usuário A envia um e-mail ao usuário B. A resposta automática do usuário B volta para o usuário A. O servidor do usuário A encaminha essa resposta ao usuário B. O servidor do usuário B dispara outra resposta.
Servidores de e-mail modernos usam cabeçalhos como X-Loop e X-Auto-Response-Suppress para detectar e interromper esse comportamento. Configurações antigas ou incorretas ainda podem gerar milhares de mensagens em poucos minutos. Confira as configurações de resposta automática ao criar encaminhamentos entre contas.
4. Quebra de DKIM por modificação
O DKIM assina um hash criptográfico do conteúdo da mensagem. No momento em que qualquer parte assinada é alterada, até mesmo com a inclusão de um rodapé de uma linha, a assinatura se torna inválida. Muitos sistemas de e-mail corporativo acrescentam avisos legais a todas as mensagens enviadas. Se o aviso for inserido depois da criação da assinatura DKIM, ela não será válida no destino.
Se você encontrar dkim=fail (body hash did not verify) nos cabeçalhos de uma mensagem encaminhada, essa quase sempre é a causa.
Fluxo de diagnóstico: do sintoma à correção
| Sintoma | Causa provável | Etapa de diagnóstico |
|---|---|---|
Remetente recebe NDR 5.7.1 |
SPF ou retransmissão recusada | Confira se o IP do encaminhador aparece em alguma lista de bloqueio. Verifique a autenticação SPF nos cabeçalhos. |
Remetente recebe NDR 5.4.14 |
Loop de roteamento | Audite todas as regras de encaminhamento para encontrar caminhos circulares (A → B → A). |
| Sem e-mail e sem NDR (descarte silencioso) | Rejeição por DMARC ou filtro antispam | Confira a pasta de spam ou lixo eletrônico no destino. Procure dmarc=fail nos cabeçalhos. |
550 5.7.520 Access denied |
Bloqueio pela política de saída do M365 | Edite a política antispam de saída no M365 Defender e habilite o encaminhamento automático. |
| O e-mail chega, mas aparece desconfigurado | Falha no hash DKIM do corpo | Procure dkim=fail (body hash did not verify) nos cabeçalhos. Desative a inserção de rodapés ou avisos. |
| A resposta vai para o encaminhador, não para o remetente original | Configuração incorreta de Reply-To ou envelope | Confirme se a configuração de encaminhamento preserva o cabeçalho Reply-To do remetente original. |
Por que o encaminhamento falha em produção: SRS e ARC em detalhes
Regras simples de encaminhamento não bastam para um ambiente de produção. Você precisa de uma infraestrutura que entenda SRS e ARC. Veja exatamente o papel de cada tecnologia e por que as duas são importantes.
SRS: Sender Rewriting Scheme
O SRS corrige a falha de SPF causada pelo salto de rede. Seu servidor de encaminhamento reescreve o endereço do remetente no envelope para que o destino valide o SPF com base no seu domínio, não no domínio do remetente original.
Antes do SRS:
MAIL FROM: alice@bank.comDepois da reescrita por SRS:
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.comO servidor de destino verifica o SPF de forwarder.com, que passa porque seu servidor está autorizado. As mensagens de devolução ainda chegam a alice@bank.com por meio do endereço codificado. O SPF é atendido sem romper o caminho de devolução.
O SRS é essencial. Sem ele, toda mensagem encaminhada de um remetente com SPF rígido falhará na autenticação no destino. Para uma explicação completa sobre o funcionamento do SRS em cadeias de encaminhamento, leia nosso guia detalhado para configurar e-mail com seu domínio. Se você encaminha especificamente para uma caixa de entrada do Gmail, siga nosso passo a passo para encaminhar o e-mail do domínio ao Gmail com segurança e configurar o SRS e o recurso “Enviar e-mail como”.
ARC: Authenticated Received Chain
O SRS corrige o SPF, mas não resolve completamente o alinhamento de DMARC. É aí que entra o ARC. Ele permite que o servidor de encaminhamento assine criptograficamente a mensagem com um selo que declara: “Verifiquei a autenticação desta mensagem quando a recebi, e ela era válida.”
Google e Microsoft reconhecem selos ARC de servidores intermediários confiáveis. Quando um selo ARC está presente e é confiável, esses provedores podem aceitar a mensagem mesmo que as verificações originais de SPF ou DMARC falhem por causa do salto de encaminhamento. Na prática, é um registro da cadeia de custódia da autenticação do e-mail.
O ARC é definido na RFC 8617 e representa o padrão atual para preservar a autenticação em cenários legítimos de encaminhamento de e-mail. Sem o ARC, uma política DMARC rígida p=reject do remetente original poderá impedir que suas mensagens encaminhadas cheguem aos grandes provedores, mesmo com o SRS configurado.
A zona de risco do catch-all
O encaminhamento costuma ser combinado a uma configuração catch-all, e essa combinação merece um alerta específico. Se você direcionar um curinga catch-all ao Gmail, toda mensagem de spam enviada a endereços aleatórios do seu domínio cairá no Gmail. Para o Gmail, a origem será seu servidor de encaminhamento. Em pouco tempo, as denúncias de spam se acumularão contra seu IP, prejudicando também a reputação de envio das mensagens legítimas do seu domínio.
Se precisar de catch-all, isole-o em uma caixa postal dedicada, com filtragem antispam no servidor, em vez de encaminhá-lo a uma caixa de entrada pessoal. O padrão completo de configuração está em nosso guia para configurar e-mail no seu domínio.
Onde a TrekMail entra
A forma antiga de gerenciar o encaminhamento de e-mail exigia criar seu próprio MTA compatível com SRS e ARC ou pagar licenças por usuário apenas para rotear mensagens. Nenhuma das opções fazia sentido para quem administrava mais do que alguns domínios.
Você paga $6/user/month ao Google ou à Microsoft, precisa de 10 endereços de encaminhamento e talvez pague por 10 usuários que não utiliza. A alternativa é atingir os limites de aliases e começar a improvisar soluções. É um imposto sobre o roteamento.
A abordagem da TrekMail é a hospedagem com preço fixo. Você paga por um plano, não por usuários. Segundo a descrição do plano, rotas de encaminhamento, aliases e configuração de catch-all estão incluídos e são gerenciados no nível do servidor, com encaminhamento compatível com SRS incorporado à infraestrutura. Você define a rota, e a plataforma cuida dos cabeçalhos de autenticação, da aplicação de TLS e da entrega. No modelo de preços descrito, não há cobrança por endereço nem necessidade de contornar políticas antispam de saída para ter acesso a uma funcionalidade básica.
Para uma pessoa que administra sozinha uma nova empresa, isso pode significar rotear hello@yourdomain.com de modo confiável para o Gmail em menos de cinco minutos quando a configuração é adequada, sem instalar um servidor de e-mail completo. Para uma equipe, as alterações de roteamento podem ser feitas pelo painel, sem precisar escavar configurações de DNS. Para uma agência que gerencia 100+ domínios de clientes, as regras de encaminhamento podem ser administradas de forma centralizada e aplicadas de maneira consistente, reduzindo falhas de autenticação capazes de gerar escalonamentos de suporte às 6pm de uma sexta-feira.
Segundo a tabela vigente quando este artigo foi preparado, o plano Pro ($10/month, ou $8/month na opção anual) inclui catch-all externo e encaminhamento de caixa postal. O plano Agency ($29/month) é apresentado para 1,000+ domínios e com acesso à API para gerenciar rotas em massa. Os planos pagos são divulgados com uma 14-day free trial (cartão obrigatório).
Veja como a TrekMail trata o encaminhamento em qualquer escala em trekmail.net.
Conclusão
O encaminhamento de e-mail não é um recurso para configurar e esquecer. É uma operação ativa de roteamento que interage com os principais modelos de autenticação da internet. As falhas são previsíveis: o SPF quebra com a mudança de IP, o DKIM quebra quando o conteúdo é alterado e o DMARC rejeita quando o alinhamento falha. Todas elas podem ser corrigidas quando você entende o que acontece na camada do protocolo.
As conclusões práticas são: use encaminhamento no servidor com SRS e ARC, nunca regras no cliente. Teste os cabeçalhos antes de entrar em produção. Fique atento ao bloqueio da política de saída do M365. Mantenha o catch-all isolado. E, se você gerencia encaminhamentos em vários domínios, não pague por usuário apenas para rotear mensagens.
Com a infraestrutura correta, o encaminhamento de e-mail pode funcionar de forma confiável. Com a configuração errada, suas mensagens mais importantes podem desaparecer sem deixar rastros. A escolha não é complicada.
