Encaminhamento de e-mail do domínio: diagnóstico, SRS e ARC

O encaminhamento de e-mail do domínio abre uma nova conexão SMTP com o destino. Se o servidor mantiver o remetente original do envelope, seu IP pode não estar autorizado por esse domínio. Essa diferença pode prejudicar a entrega; a visibilidade das notificações de falha depende do roteamento e dos logs disponíveis.

Sem autenticação adequada, mensagens encaminhadas podem ser filtradas pelo Gmail, rejeitadas com código 550 pelo Yahoo ou bloqueadas por políticas do Microsoft 365. Os provedores não respondem todos da mesma forma, e uma falha nem sempre fica visível na caixa de destino.

Este guia apresenta três padrões úteis em 2026, exemplos de erros dos principais provedores e uma lista de verificações que você pode percorrer em menos de dez minutos. Para configurar todo o fluxo, consulte nosso guia completo de configuração e correção do encaminhamento.

Por que o encaminhamento de e-mail do domínio pode falhar no SPF

O SPF pode falhar quando seu servidor realiza a nova entrega SMTP, mas o Return-Path mantém o domínio original. O destino consulta o SPF desse domínio para verificar se ele autoriza o IP da conexão. Caso não autorize, a verificação pode falhar. Uma política DMARC p=reject não determina, sozinha, que a mensagem seja apagada: uma assinatura DKIM original válida e alinhada ainda pode permitir a aprovação no DMARC.

Veja um exemplo da sequência de falha:

1. alice@bank.com envia para info@yourdomain.com. O SPF do banco autoriza seus próprios servidores.
2. Seu servidor entrega novamente para you@gmail.com. O Gmail vê o IP do seu servidor, mas o Return-Path ainda indica bank.com.
3. Se esse IP não estiver autorizado pelo SPF de bank.com, a verificação pode falhar.
4. Se o servidor alterar o corpo ou um cabeçalho assinado, o DKIM também pode falhar, dependendo da assinatura e da canonicalização. Sem outro resultado válido e alinhado, o DMARC falha e o destinatário pode aplicar sua política de rejeição.

Uma notificação de falha pode voltar ao remetente do envelope ou aparecer nos logs das filas. Verifique esses registros antes de concluir que a mensagem desapareceu sem aviso.

Encaminhar um catch-all pode ampliar o risco. O spam recebido também é reenviado a partir do IP do encaminhador. Esse tráfego pode prejudicar sua reputação e levar à filtragem ou rejeição de mensagens legítimas, mas não é uma evolução inevitável nem exclusiva do Gmail.

Se você ainda está avaliando essa arquitetura, veja as vantagens e limitações do encaminhamento por alias antes de escolher a configuração.

Os 3 padrões de encaminhamento voltados à entregabilidade

Esses três padrões tratam riscos diferentes. Eles podem ser combinados conforme a infraestrutura e a política do destinatário, mas não são requisitos universais nem garantias de entrega. Preservar uma assinatura DKIM original válida e alinhada é especialmente importante.

1. Sender Rewriting Scheme (SRS)

O SRS reescreve o remetente do envelope usando o domínio do encaminhador. O destino pode então avaliar o SPF desse domínio, que precisa autorizar o IP de saída. O endereço codificado permite devolver as notificações de falha ao remetente original quando a implementação e a rota estão configuradas corretamente.

Antes do SRS:

MAIL FROM: <alice@bank.com>

Depois do SRS:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

A limitação: o SRS pode resolver a verificação SPF do envelope, mas normalmente não fornece alinhamento SPF com o From original para o DMARC. Uma assinatura DKIM válida e alinhada ainda pode permitir a aprovação no DMARC. Se essa assinatura ficar inválida, o SRS sozinho não restaura o alinhamento.

2. Authenticated Received Chain (ARC)

O ARC (RFC 8617) protege o histórico dos resultados de autenticação ao passar por intermediários. O encaminhador adiciona cabeçalhos assinados que registram suas verificações; eles não comprovam, sozinhos, que o remetente é legítimo.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google e Microsoft podem considerar uma cadeia ARC válida de um intermediário confiável ao decidir a entrega. Isso pode ajudar quando a autenticação final falha, mas a aceitação depende da política do destinatário e não é garantida.

A confiança é essencial: uma assinatura ARC válida ou um domínio novo não obtém automaticamente a confiança do destinatário. A reputação e a relação com o intermediário podem influenciar.

3. Encaminhamento passivo: preservação do DKIM

Preservar a mensagem original é importante, com ou sem SRS e ARC. Evite inserir rodapés ou reescrever cabeçalhos assinados. O DKIM assina o corpo e determinados cabeçalhos conforme regras de canonicalização: alterações relevantes podem invalidar a assinatura, mas nem toda mudança de um byte invalida todas as assinaturas.

Falhas difíceis de diagnosticar podem surgir de uma alteração discreta. Um filtro acrescenta “Esta mensagem foi verificada pelo MailGuard” ao corpo e pode invalidar sua assinatura. Os logs de envio talvez não indiquem isso; um dkim=fail (body hash did not verify) em Authentication-Results no destino oferece uma pista, se você tiver acesso à mensagem.

Esse padrão depende de uma assinatura DKIM válida e alinhada sobreviver a todo o percurso. Se o SPF não estiver alinhado e o DKIM ficar inválido, o DMARC pode falhar. O destinatário ainda decide como tratar a mensagem e se considera o ARC.

Como os principais provedores tratam falhas de encaminhamento

Microsoft, Google e Yahoo podem bloquear o encaminhamento por políticas, rejeitar mensagens durante o SMTP com código 550 ou filtrá-las depois. Reputação e autenticação influenciam. Os códigos abaixo são exemplos: interprete o diagnóstico completo, a etapa de entrega e os logs, sem presumir uma resposta universal.

Microsoft 365 (Exchange Online)

Uma política antispam de saída do Defender pode bloquear o encaminhamento externo automático. Se o bloqueio ocorrer no tenant de origem, a mensagem pode não chegar ao seu encaminhador. Confira a política efetiva antes de alterar a autenticação.

Uma notificação 5.7.520 pode ir para o remetente do envelope, e não para a caixa de destino. Consulte o rastreamento da mensagem e os logs pertinentes; não presuma que a notificação será sempre invisível.

Google Workspace / Gmail

Um exemplo de rejeição explícita é 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. Ela pode aparecer se o DMARC falhar para um domínio com p=reject. A ausência de SRS ou ARC não basta para prever isso: o DKIM original válido e alinhado pode aprovar o DMARC, enquanto o SRS sozinho não fornece esse alinhamento.

Encaminhar spam de um catch-all pode prejudicar a reputação do IP. O resultado pode ser filtragem ou rejeição, com sinais diferentes nas respostas SMTP e nos logs. Isso não significa necessariamente uma perda silenciosa e progressiva de todas as mensagens.

Yahoo / AOL

O Yahoo pode rejeitar com código 550 mensagens encaminhadas que não atendam às suas políticas de autenticação. Adicionar [FWD] ou [External] a um assunto assinado pode invalidar o DKIM; sem SPF alinhado, o DMARC pode falhar. Isso não significa rejeição de 100% dessas mensagens nem perda de todo o correio em instalações sem SRS/ARC: importam a assinatura preservada, a política e o diagnóstico completo.

Lista de diagnóstico do encaminhamento

Quando o encaminhamento de e-mail do domínio falhar, siga esta sequência antes de mudar a configuração:

1. Leia Authentication-Results no destino (“Mostrar original” no Gmail; origem da mensagem no Outlook), se a mensagem estiver disponível.

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → verifique o domínio do envelope, o IP e o SRS; esse resultado sozinho não identifica a causa.
   dkim=fail (body hash) → investigue alterações do corpo e problemas de assinatura.
   Ambas as falhas podem causar falha no DMARC se não houver outro resultado válido e alinhado; a rejeição depende do destinatário.
2. Procure loops de roteamento. 5.4.14 Hop count exceeded aponta para excesso de saltos. Mapeie todo o percurso e procure ciclos como A→B→C→A.
3. Teste o comportamento de Reply-To. A resposta costuma ir para Reply-To quando existe, ou para From quando não existe. Confira o destino esperado e ambos os cabeçalhos antes de atribuir uma resposta ao encaminhador à reescrita de From.
4. Audite todos os componentes que tocam a mensagem. Filtros antispam, antivírus, listas de discussão e ferramentas antiphishing podem alterar conteúdo assinado. Verifique as transformações e os logs de cada salto.
5. Confira o volume do catch-all. Um volume alto de spam encaminhado pode prejudicar a reputação e a entrega, mesmo que algumas mensagens passem nas verificações de autenticação.

Se você tem dúvidas entre encaminhamento e roteamento por endereço, compare aliases de domínio com caixas de e-mail. Eles atendem a necessidades diferentes e mudam os riscos que você precisa gerenciar.

A infraestrutura de encaminhamento do TrekMail

No Postfix auto-hospedado, uma arquitetura pode incluir postsrsd para SRS, OpenARC para ARC, rotação de chaves RSA e preservação do conteúdo assinado. São componentes independentes que devem ser testados separadamente; nem todos são necessários em cada arquitetura.

Uma assinatura DKIM adicional do encaminhador pode fazer parte do projeto, mas não é uma exigência universal do ARC. Ela não substitui a assinatura original alinhada nem restaura o alinhamento com o From original se usar outro domínio. Verifique a preservação do DKIM, a cadeia ARC e a política do destinatário em vez de atribuir toda falha à ausência de uma nova assinatura.

O projeto descrito para o TrekMail combina OpenARC, assinatura DKIM adicional e SRS, com um percurso que preserva o conteúdo. Confira a implementação atual e os cabeçalhos das mensagens de teste. Defina o destino nas configurações de encaminhamento da caixa; a entrega também depende do destinatário.

A oferta descrita inclui encaminhamento nos planos Pro ($10/mês) e Agency ($23.25/mês), com um teste grátis de 14 dias que exige cartão para começar. Nano ($0, 10 domínios, SMTP próprio) e Starter ($3.50/mês, 50 domínios) são apresentados sem encaminhamento. Confirme preços, limites e recursos atuais na comparação completa de planos em trekmail.net/pricing.

Conclusão

A entregabilidade do encaminhamento de e-mail do domínio em 2026 depende da autenticação e do percurso. O SRS pode resolver o SPF do envelope sem alinhar o From original; o ARC fornece um histórico protegido que o destinatário pode considerar; preservar o DKIM original válido e alinhado ajuda na aprovação do DMARC. Combine as medidas adequadas à sua arquitetura sem tratá-las como garantia de entrega.

Comece por Authentication-Results no diagnóstico. Interprete os resultados com os cabeçalhos e os logs de cada salto: um único cabeçalho nem sempre reconstrói todo o percurso.

Se você prefere não administrar o Postfix, configurar e-mail profissional no seu domínio com o TrekMail pode levar cerca de 15 minutos, conforme os pré-requisitos. Confira os recursos atuais de encaminhamento e teste a entrega aos seus destinos.