Você configura um encaminhamento: contact@yourdomain.com vai para o Gmail. No início funciona; depois faltam mensagens de clientes. Os logs mostram, por exemplo, 550 5.7.1 Unauthenticated email ou 550 5.7.26 This message does not have authentication information. Esses erros exigem investigação e não provam, sozinhos, uma falha de SRS. O encaminhamento de email com SRS trata um problema típico: seu servidor abre uma nova conexão SMTP, mas mantém o remetente original no envelope. Se o domínio dele não autoriza seu IP, SPF pode falhar. Com DMARC em p=reject, o destinatário pode rejeitar se não houver SPF ou DKIM válido e alinhado ao From visível. A rejeição SMTP pode gerar uma notificação de falha; mensagens não desaparecem sempre em silêncio.
SRS, sozinho, não resolve tudo. Mesmo após uma configuração correta, outras falhas de autenticação ou política podem impedir a entrega. O guia de configuração e correção do encaminhamento de email apresenta outros cenários e formas de diagnóstico.
O que é encaminhamento de email com SRS?
O encaminhamento de email com SRS, Sender Rewriting Scheme, reescreve o endereço do remetente do envelope antes de entregar a mensagem a outro destino. O domínio original é substituído pelo domínio do encaminhador no caminho técnico de retorno. SPF pode passar se o DNS atual desse domínio autorizar o IP de saída. O From visível continua igual. SRS atua no envelope, não é criptografia; usuários podem consultar Return-Path nos cabeçalhos completos.
O Postfix pode integrar SRS pelo daemon postsrsd. O Microsoft 365 oferece suporte em certas rotas de saída e configurações híbridas, assim como algumas plataformas gerenciadas. Suporte e configuração dependem da versão, da rota e da oferta atual. SRS ajuda no conflito entre encaminhamento tradicional e SPF, mas não garante atendimento ao DMARC.
Por que o encaminhamento pode falhar: o novo salto SMTP
Encaminhar cria um novo salto SMTP. Isso não faz SPF falhar necessariamente, mas a mudança do IP de saída pode prejudicá-lo. O Header From, definido no RFC 5322, é o remetente visível, como From: alice@client.com. O remetente do envelope, definido no RFC 5321, MAIL FROM, é o endereço técnico de retorno e a identidade usada por SPF. Ele costuma ficar oculto na interface normal, mas aparece nos cabeçalhos completos.
A sequência abaixo mostra como um salto de encaminhamento não autorizado pode levar à rejeição:
- Alice envia como
alice@client.com. Sua configuração SPF autoriza o servidor dela; SPF passa na chegada ao seu servidor. - Seu servidor abre uma nova conexão para
you@gmail.com. Agora quem envia é seu IP. - O remetente do envelope continua
alice@client.com, mas client.com não autoriza o IP do seu servidor neste exemplo. - O Gmail verifica SPF para
client.com. Sem autorização para seu IP, SPF falha. - Se
client.compublica a política DMARCp=rejecte também não há DKIM válido e alinhado, o Gmail pode rejeitar. O resultado e as possíveis notificações dependem da política do destinatário.
Como SRS ajuda o SPF
O encaminhamento de email com SRS troca o domínio do remetente do envelope pelo domínio do encaminhador antes do novo envio. O destinatário passa a verificar SPF nesse domínio. O sucesso exige autorização correta para o IP realmente utilizado. Header From permanece igual, enquanto notificações de falha podem retornar pelo domínio de encaminhamento. Esse processamento precisa corresponder à implementação utilizada.
Os componentes de um endereço SRS
Com SRS ativo, um endereço de retorno simples pode se tornar um endereço estruturado protegido por um valor de autenticação criptográfica:
Antes do SRS:MAIL FROM: <alice@client.com>
Depois do SRS:MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>
| Componente | Tipo no exemplo | Finalidade |
|---|---|---|
SRS0 | Prefixo | Indica a primeira reescrita; outro encaminhamento pode usar SRS1. |
4fac | Valor de autenticação | No exemplo de implementação, HMAC truncado (SHA1) com um segredo local compartilhado; dificulta notificações de falha falsificadas, mas não as impede completamente. |
PM | Marca de tempo | No exemplo, marca de tempo cíclica em Base32. Validar a idade pode limitar reutilizações, mas não elimina todo replay ou backscatter. |
client.com | Domínio original | Preserva o domínio de origem para processar notificações de falha. |
alice | Usuário original | Parte local do endereço original. |
@yourdomain.com | Domínio de encaminhamento | Domínio que reescreve. Para SPF passar, sua configuração precisa autorizar o IP do encaminhador. |
Em um segundo encaminhamento (A → B → C), pode ser usada a sintaxe SRS1. A representação depende da implementação e não se limita simplesmente ao hash e à marca de tempo. Ela limita o crescimento adicional em comparação com encapsular novamente toda a string SRS0. Ainda é necessário conferir o limite de 64 caracteres da parte local definido no RFC 5321; qualquer endereço não cabe nele automaticamente.
Por que SRS não basta: o alinhamento DMARC
Muitos administradores ativam o encaminhamento de email com SRS e esperam uma solução completa. Porém, SPF passar não garante alinhamento DMARC. O DMARC exige SPF ou DKIM válido com um domínio alinhado ao Header From. Após a reescrita, SPF pode passar para yourdomain.com, enquanto Header From continua em client.com. Os domínios diferentes não estão alinhados neste exemplo. No alinhamento relaxado, domínios com o mesmo domínio organizacional podem ser compatíveis; pertencer à mesma empresa, por si só, não basta.
Sem SPF alinhado, DKIM válido e alinhado ainda pode satisfazer DMARC. Um encaminhador pode prejudicar a assinatura se alterar partes assinadas, por exemplo:
- Adicionar
[EXTERNAL]ao início de um assunto assinado - Inserir rodapés de antivírus ou avisos legais no conteúdo assinado
- Converter codificação de 8 bits para 7 bits
- Reescrever delimitadores MIME
O efeito dessas alterações no DKIM depende das partes assinadas e da canonicalização. Se ambos os caminhos de autenticação alinhada falham, DMARC falha. O destinatário pode então filtrar ou rejeitar conforme sua política, mesmo que a reescrita SRS esteja correta.
Apoio adicional com ARC (Authenticated Received Chain)
ARC, definido no RFC 8617, permite que um intermediário registre e proteja resultados de autenticação realmente observados. Não deve declarar um sucesso que não observou. Ele utiliza três cabeçalhos:
- ARC-Authentication-Results: registra resultados SPF/DKIM/DMARC observados no recebimento
- ARC-Message-Signature: assina cabeçalhos selecionados e o corpo no momento da assinatura; alterações posteriores relevantes podem invalidá-la
- ARC-Seal: assinatura criptográfica que vincula e protege a cadeia ARC
Se o destinatário confia no signatário ARC e na cadeia válida, pode considerar essas informações ao decidir aceitar uma mensagem apesar da falha DMARC posterior. ARC não transforma isso em DMARC aprovado nem garante aceitação. O Gmail avalia ARC em produção desde 2019; a decisão de confiança continua com o destinatário.
Para encaminhamentos em 2026, encaminhamento de email com SRS, preservação do conteúdo assinado e ARC são componentes importantes a avaliar. Nem sempre todos são necessários, e os três juntos não garantem o resultado. Rota, autenticação e política do destinatário são determinantes.
Configurar SRS por plataforma
A configuração varia bastante. Postfix precisa de uma integração adequada; Microsoft 365 depende da rota e das políticas de segurança; Google Workspace tem seu próprio comportamento e limites. Confira versões e configurações atuais, sem pressupor ativação padrão ou mudanças obrigatórias em todos os casos.
Postfix em Linux autogerenciado
Uma integração comum do Postfix usa postsrsd. O exemplo de instalação abaixo deve ser conferido na distribuição e na versão antes de qualquer aplicação autorizada:
apt-get install postsrsdO exemplo de mapas TCP abaixo para /etc/postfix/main.cf é uma integração mais antiga. Faça backup das configurações e combine cuidadosamente os novos mapas com os existentes. Confira versão, sintaxe suportada, portas, sockets, caminhos e permissões:
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipientImportante: a variável SRS_EXCLUDE_DOMAINS em /etc/default/postsrsd depende da versão. Confira quais domínios locais e rotas precisam ficar fora da reescrita. Exceções ausentes podem causar reescritas indesejadas ou, junto de outras regras, loops; não provocam necessariamente toda falha descrita. Teste entrada, saída e notificações de falha.
Microsoft 365
O Microsoft 365 pode aplicar SRS em rotas de saída compatíveis. Confira o comportamento atual em ambientes híbridos e conectores. O erro 550 5.7.520 Access denied, Your organization does not allow external forwarding indica uma política de encaminhamento de saída, não uma falha comprovada de SRS.
Altere essa política de segurança somente com autorização e revisão restrita do escopo necessário, não para contornar proteções. A interface administrativa e as opções de encaminhamento automático podem mudar. O comando abaixo é um exemplo de conector; confira se o parâmetro existe e é compatível com a versão real do PowerShell e o tipo de conector:
Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $trueGoogle Workspace
O Google Workspace tem comportamento próprio de encaminhamento. Entre os pontos a investigar estão os seguintes, que não são exclusivos da plataforma:
- Limites de volume: encaminhamento catch-all e grandes fluxos de spam podem acionar cotas ou proteções. Confira os limites atuais; suspensão total da conta não é inevitável.
- Loops e mensagens ausentes: a detecção de loops pode suprimir encaminhamentos que retornam. Logs e rastros disponíveis dependem da conta, da permissão e do evento; não ver um log não prova descarte universal sem rastros.
Investigar falhas no encaminhamento com SRS
Cabeçalhos completos oferecem pistas importantes, mas nem sempre mostram toda a causa. Envie um teste do ProtonMail pelo encaminhador e examine os cabeçalhos no destino. Se a mensagem não chegar, consulte respostas SMTP, logs e rastreamento disponível. Nem todo erro aparece no cabeçalho final.
Verificação 1: Return-Path
Exemplo sem reescrita SRS visível:Return-Path: <original@protonmail.com>
Exemplo com reescrita SRS:Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>
Return-Path inalterado pode indicar integração ausente, serviço parado ou uma rota excluída de propósito. Isso não prova, sozinho, que postsrsd falhou. Confira o caminho realmente percorrido.
Verificação 2: Authentication-Results
Procure spf=pass nos cabeçalhos de autenticação confiáveis do destinatário e confira se o domínio avaliado é o domínio SRS. Se ainda aparecer dmarc=fail, falta SPF ou DKIM válido e alinhado. DKIM pode estar ausente, inválido ou usar um domínio não alinhado mesmo com assinatura válida. Confira conteúdo assinado, alterações e alinhamento, sem atribuir automaticamente a falha a mudanças no corpo.
Verificação 3: DNS
dig yourdomain.com TXT +shortConfira SPF do domínio de encaminhamento e se a rota de retorno está acessível. MX é comum, mas, sem ele, ainda pode existir uma rota implícita por registros A/AAAA. Alguns destinatários consideram se o domínio recebe notificações de falha; ter MX, sozinho, não comprova essa capacidade.
Verificação 4: logs do Postfix
grep "srs_forward" /var/log/mail.logMensagens como hash mismatch ou timestamp expired podem indicar chaves diferentes entre nós, rotação de chaves, problemas de horário ou configuração, atrasos ou reutilização de endereços antigos. Não provam, sozinhas, um ataque de replay. Investigue o contexto completo.
Quando preferir caixas diretas ao encaminhamento
O encaminhamento de email com SRS trata um conflito estrutural de saltos SMTP adicionais. SRS, preservação do conteúdo assinado e, quando aplicável, ARC acrescentam dependências. Encaminhar pode parecer barato diante de licenças por usuário, mas operação e diagnóstico também entram na conta. Caixas diretas podem ser mais adequadas.
Compare os dois modelos e seus requisitos reais:
| Encaminhamento de email com SRS | Caixa hospedada (TrekMail) | |
|---|---|---|
| Alinhamento SPF | Ausente no exemplo com domínios diferentes | Possível com autorização e alinhamento corretos |
| DKIM | Alterações em conteúdo assinado podem prejudicar a assinatura | Configurar e verificar assinatura nas rotas suportadas |
| DMARC | Exige SPF ou DKIM válido e alinhado; ARC pode influenciar a decisão do destinatário | Configurar autenticação e alinhamento e testar mensagens reais |
| Complexidade | Integração postsrsd adequada, ARC quando aplicável e alterações controladas | Assistente descrito conforme suporte atual |
| Custo por usuário | $0 no exemplo, mais operação e diagnóstico | Armazenamento compartilhado dentro de um plano; conferir preços e limites |
| Vários domínios | Configuração do servidor para as rotas necessárias | Até 1,000+ domínios no plano adequado descrito; conferir condições |
O TrekMail descreve planos com armazenamento compartilhado entre caixas e domínios, em vez de cobrança individual por caixa. Você paga por um plano limitado, não apenas por armazenamento ou uso ilimitado. Compare com uma configuração comum de encaminhamento para Gmail ou leia as considerações sobre encaminhar aliases. A comparação entre alias de domínio e caixa postal ajuda na decisão inicial.
Ao receber diretamente em uma caixa TrekMail, você elimina esse salto externo de encaminhamento; SRS e ARC não precisam ser configurados para essa rota de recebimento. Outras rotas podem continuar precisando deles. O assistente descrito ajuda com SPF, DKIM e DMARC, mas não substitui autorização e testes. Ser o servidor MX autoritativo de recebimento não autoriza automaticamente a saída SMTP.
Teste o TrekMail gratuitamente: Nano é descrito sem cartão, e Starter com teste de 14 dias a partir de $3.50 mensais e SMTP gerenciado. Confira elegibilidade, recursos e condições atuais, inclusive para provedores SMTP próprios e credenciais.
Resumo
O encaminhamento de email com SRS é um componente importante em 2025-2026, mas não uma obrigação universal para toda rota. Sem reescrita, SPF pode falhar no salto de encaminhamento. DMARC restritivo pode levar à rejeição se também não houver DKIM válido e alinhado. Com SRS, SPF pode passar para o domínio do encaminhador sem alinhar ao From original. DKIM válido e alinhado ainda pode satisfazer DMARC.
No Postfix, SRS exige integração compatível com a versão e exceções verificadas. No Microsoft 365, comportamento e possíveis mudanças autorizadas de política dependem da rota e do suporte atual; um exemplo PowerShell não é uma instrução universal. No Workspace, confira cotas reais, roteamento e logs disponíveis, sem presumir suspensão em todos os casos.
SRS, assinaturas DKIM preservadas e ARC podem ajudar em conjunto, mas não garantem entrega confiável em qualquer situação. Avalie os componentes necessários à sua rota. Ou escolha uma caixa direta no destino adequado e evite o salto adicional de encaminhamento.
