Encaminhar e-mail para outro endereço: autenticação e diagnóstico

Você cria uma regra de encaminhamento. Envia um teste. Funciona. Segue em frente.

Depois, um cliente diz que não recebeu sua resposta. Nenhuma devolução ou notificação de falha visível. A mensagem parece ter se perdido entre servidores; os registros podem esclarecer o que aconteceu.

Isso pode ocorrer quando você encaminha e-mail para outro endereço: seu servidor abre uma nova conexão SMTP com o destino. O destino verifica SPF usando seu IP, não o do remetente original. Se esse IP não estiver autorizado para o domínio do remetente do envelope, SPF pode falhar. Sem uma assinatura DKIM válida e alinhada, DMARC também falha. Com p=reject, o destinatário pode rejeitar a mensagem conforme sua política; isso não significa sempre descarte silencioso ou ausência de devolução.

Não é necessariamente um erro de configuração. O encaminhamento pode entrar em conflito com a autenticação moderna. O guia completo de configuração e correção do encaminhamento de e-mail aborda os cenários de ponta a ponta. Este artigo foca a autenticação: tipos de falha, códigos de erro e medidas corretivas.

Por que a autenticação pode falhar no encaminhamento

Ao encaminhar e-mail, o MTA destinatário verifica SPF com o IP do servidor que encaminha, não com o do remetente original. Cada mensagem tem duas camadas de identidade que podem perder o alinhamento. SPF valida o envelope; DMARC exige SPF ou DKIM válido e alinhado com o domínio do remetente visível.

A sequência: o servidor A envia ao servidor de encaminhamento B, que abre outra conexão TCP com C. C vê o IP de B. SPF pergunta ao DNS do domínio do remetente do envelope: "Este IP está autorizado a enviar pelo seu domínio?" Se o domínio original não autorizar B e o envelope for mantido, SPF pode falhar. Não é um resultado inevitável de todo encaminhamento.

DMARC precisa de apenas um mecanismo SPF ou DKIM válido e alinhado. Uma assinatura DKIM original que continue válida e alinhada pode manter a aprovação DMARC. Alterações nas partes assinadas podem invalidar DKIM, dependendo dos cabeçalhos assinados e da canonicalização. Sem um mecanismo válido e alinhado, DMARC falha; p=reject solicita rejeição, sujeita à política local do destinatário.

Três tipos de falha para prever

Sem medidas adequadas no servidor, o encaminhamento pode apresentar estes três padrões. Os códigos são exemplos dependentes do provedor, não respostas obrigatórias para todas as falhas. Identificar o padrão ajuda a direcionar o diagnóstico.

1. Bloqueio de saída do Microsoft 365 (550 5.7.520)

O Microsoft 365 pode bloquear encaminhamento externo por considerá-lo um risco de exfiltração de dados. Se uma regra encaminha para fora do tenant e a política efetiva não permite, o Exchange Online pode bloquear a mensagem antes da saída.

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

É um bloqueio de política, não um erro de protocolo. Um administrador deve revisar o escopo autorizado:

1. Abra o portal Microsoft 365 Defender.
2. Acesse Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Edite a política de filtro de spam de saída aplicável aos usuários ou grupos autorizados.
4. Defina Automatic forwarding como On - Forwarding is enabled apenas nesse escopo aprovado.

Habilitar globalmente aumenta a exposição se alguma conta for comprometida. Limite a exceção a quem precisa dela, aplique MFA e monitore o volume de saída após a mudança. Verifique também outras restrições de encaminhamento vigentes.

2. Falha dos dois mecanismos de DMARC

Esse problema pode ser difícil de detectar na caixa de entrada. SPF pode falhar pela mudança de IP se o remetente original do envelope for mantido. DKIM ainda pode fazer DMARC passar com uma assinatura válida e alinhada. Uma alteração relevante no corpo ou em um cabeçalho assinado pode invalidá-la; nem toda alteração faz isso.

Modificações que podem quebrar DKIM durante o trânsito:

• Antivírus adicionando um rodapé: "Verificado por [Nome do produto]"
• Tags de assunto do gateway de destino: [EXT] ou [EXTERNAL], se esse cabeçalho estiver assinado
• Avisos de "Remetente externo" inseridos no corpo HTML
• Software de listas reescrevendo cabeçalhos assinados ou adicionando rodapés de cancelamento de inscrição

Se nem SPF nem DKIM oferecerem um resultado válido e alinhado, DMARC (RFC 7489) falha. Com p=reject, o domínio solicita rejeição, mas o destinatário decide o tratamento final. Pode haver rejeição SMTP, quarentena ou outra ação local; não se deve presumir descarte sem devolução. Consulte os registros e relatórios disponíveis.

3. Loops de roteamento (554 5.4.14)

Um loop ocorre quando servidores devolvem repetidamente a mesma mensagem uns aos outros até atingir o limite de saltos. Pode gerar uma notificação de falha, mas o prazo e o código dependem do sistema. Também pode congestionar filas e atrasar outras mensagens.

Situações para revisar:

• O usuário A encaminha para B; B tem uma regra que encaminha de volta para A.
• A encaminha para B, que tem resposta de ausência. Se as regras permitirem respostas repetidas e as proteções forem insuficientes, a resposta pode passar novamente pelo encaminhamento e criar um loop; isso não ocorre automaticamente em todos os sistemas.
• Um endereço catch-all encaminha para uma caixa que encaminha para um endereço inexistente do mesmo domínio, entrando novamente no catch-all.

554 5.4.14 Hop count exceeded - possible mail loop

Verifique toda a cadeia de roteamento, incluindo respostas automáticas e destinos catch-all, antes de ativar encaminhamento em produção.

As medidas: SRS e ARC

Dois mecanismos do servidor podem melhorar a autenticação do encaminhamento, sem garantir entrega. SRS reescreve o remetente do envelope para permitir que SPF passe com a configuração correta. ARC preserva uma cadeia autenticada de resultados que o destinatário pode decidir usar apesar de uma falha DMARC. Ambos precisam de suporte no servidor, não apenas de uma regra no cliente.

SRS: Sender Rewriting Scheme

SRS reescreve o remetente do envelope (P1) com um domínio que você controla. Em vez de manter alice@bank.com, cujo domínio talvez não autorize seu servidor, o encaminhador usa um Return-Path como este:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF agora verifica seu domínio. Pode passar se o registro autorizar o IP de saída e a avaliação DNS for concluída corretamente. Isso não alinha automaticamente esse domínio com o From visível original para DMARC.

O hash e o timestamp permitem validar e rotear devoluções: uma notificação enviada a um endereço SRS válido pode ser decodificada e devolvida à Alice. Esses endereços têm validade limitada e finalidade específica. A validação SRS não substitui controles de destinatários e de relay necessários para evitar um relay aberto.

ARC: Authenticated Received Chain

SRS pode corrigir SPF sem restaurar o alinhamento entre envelope e cabeçalho. ARC (RFC 8617) não fecha essa lacuna. O servidor adiciona um selo criptográfico que preserva os resultados de autenticação observados no recebimento e permite verificar a cadeia.

Google e Microsoft podem considerar ARC de intermediários que julgam confiáveis, conforme suas políticas. Uma cadeia ARC válida e boa reputação não garantem aceitação nem chegada à caixa de entrada: o destinatário mantém a decisão final.

Pense em ARC como um registro de cadeia de custódia. Cada intermediário participante adiciona uma declaração assinada dos resultados observados. Destinatários posteriores podem verificar a cadeia e decidir confiar nela quando o alinhamento SPF ou DKIM não basta mais para DMARC.

Gmail e Microsoft 365 oferecem suporte a ARC em determinados fluxos; confira os cabeçalhos e a configuração efetiva do caminho usado. Sem ARC no seu servidor, falta esse contexto adicional, mas DMARC ainda pode passar com uma assinatura DKIM original válida e alinhada.

Implementação: dois caminhos

Para reduzir problemas de autenticação no encaminhamento, você pode administrar seu MTA ou escolher um provedor que confirme suporte SRS e ARC para seu fluxo. Nenhum caminho elimina todos os riscos de entrega; ambos exigem testes e monitoramento.

Opção A: Postfix + postsrsd (autogerenciado)

Em um servidor Linux com Postfix, postsrsd pode gerenciar SRS. Este exemplo mostra a integração TCP de versões antigas. As versões modernas usam socketmap, incompatível com essas tabelas TCP; consulte a documentação da versão instalada, adapte a configuração e teste antes de aplicá-la:

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Responsabilidades dessa abordagem:

• Gerenciar as chaves secretas SRS. Um vazamento permite forjar endereços SRS; mantenha controles independentes de relay e destinatários.
• Configurar exclusões de domínios locais conforme sua topologia e versão, evitando reescritas indevidas de mensagens internas.
• Gerenciar a reputação do IP de saída, que influencia a entrega ao Gmail e Outlook sem determiná-la sozinha.
• Configurar ARC separadamente: postsrsd não basta para assinar ARC.

É uma opção viável com configuração validada. Também exige manutenção contínua, que alguns provedores podem assumir em parte.

Opção B: TrekMail (encaminhamento gerenciado)

Se escolher TrekMail, confirme antes o suporte SRS automático e ARC para seu plano e fluxo de encaminhamento. Verifique também qual tráfego usa relays SMTP gerenciados. Não presuma que essas funções estejam incluídas em todos os planos, nem que reputação e entrega sejam garantidas.

Para fundadores solo: pagar $6/mês por caixa apenas para encaminhar info@yourdomain.com à caixa pessoal pode representar um custo alto por usuário. A referência de Starter é $3.50/mês para até 50 domínios, sem cobrança por usuário; confirme preço atual, limites e inclusão do encaminhamento externo. Veja como funciona o encaminhamento de caixas no TrekMail.

Para agências que administram DNS de vários clientes, diagnosticar SPF pode consumir tempo e margem. Um painel comum pode simplificar a gestão, desde que cubra os fluxos necessários. Se estiver escolhendo entre aliases e regras completas de caixa, o guia de encaminhamento por alias explica as diferenças.

Checklist antes de encaminhar e-mail para outro endereço

Confira estes quatro pontos antes de ativar uma regra em produção. Eles reduzem os riscos descritos, mas não substituem testes de entrega e análise dos registros.

1. SRS ativo quando necessário. Confira o cabeçalho Return-Path de um teste entregue. Se o fluxo usar SRS, deve mostrar o domínio de encaminhamento e um formato SRS válido; verifique também SPF.
2. Evitar alterações no conteúdo assinado. Configure as proteções para não inserir rodapés de antivírus, tags no assunto ou avisos de "Remetente externo" que invalidem DKIM. Mantenha a análise de segurança e proteções equivalentes, por exemplo avisos fora do conteúdo assinado. A canonicalização e os cabeçalhos assinados determinam quais alterações afetam a assinatura.
3. Proteção contra loops. Revise regras inversas, respostas de ausência, destinos catch-all e limites de saltos. Uma resposta automática não cria necessariamente um loop, mas o comportamento efetivo deve ser testado.
4. Política de saída M365. No Exchange Online, autorize "Automatic Forwarding" apenas para usuários ou grupos aprovados na política de saída do Defender. Confira outras restrições e evite habilitar globalmente por padrão.

Quando não encaminhar e-mail para outro endereço

Às vezes, não é preciso encaminhar externamente. Para reunir mensagens de vários domínios em uma caixa do mesmo sistema, um alias de domínio pode evitar um salto SMTP externo adicional. Os domínios ainda precisam de configuração correta; as responsabilidades SPF/DKIM não desaparecem por completo.

A comparação entre alias de domínio e caixa de e-mail ajuda a escolher um alias ou uma regra completa de encaminhamento. Se estiver migrando de provedor, confirme a disponibilidade e os limites da ferramenta de migração IMAP do TrekMail: copiar mensagens existentes do servidor de origem não substitui a transição do recebimento de mensagens novas.

Resumo

Ao encaminhar e-mail, o destino vê o IP do encaminhador. Se o remetente original do envelope for mantido e esse IP não estiver autorizado, SPF pode falhar. DMARC ainda pode passar com DKIM válido e alinhado. Sem um mecanismo de autenticação alinhado, falha; o tratamento depende do destinatário e a existência de devolução depende do fluxo.

As medidas ficam no servidor: SRS reescreve o remetente do envelope com um domínio controlado e pode permitir que SPF passe; ARC fornece contexto autenticado em que o destinatário pode decidir confiar. Nenhum garante sozinho alinhamento DMARC ou entrega. Você pode administrá-los no Postfix ou confirmar sua disponibilidade em uma plataforma.

Para delegar chaves SRS, ARC e gestão de reputação, confirme o que TrekMail inclui no seu caso. A referência de Starter é $3.50/mês para até 50 domínios, tarifa fixa sem cobrança por usuário; valide preço, recursos e condições atuais. Veja todos os planos.