Você configura um encaminhamento de e-mail. Faz o teste e funciona. Duas semanas depois, o e-mail de um cliente com um contrato não chega. Não está no spam, não há aviso visível de falha na entrega: simplesmente sumiu. Ao consultar os logs, você encontra: 550 5.7.1 Unauthenticated email from domain.com.
Uma configuração ausente ou incorreta de Sender Rewriting Scheme pode contribuir para o problema, mas esse código também tem outras causas. A autenticação de e-mail verifica, entre outros aspectos, se o servidor de envio está autorizado pelo domínio do remetente do envelope. O encaminhamento pode fazer essa verificação falhar no nível do protocolo. O Sender Rewriting Scheme ajuda a resolver esse ponto, mas, mesmo em 2026, não é uma solução completa por si só. Conhecer seus limites é tão importante quanto entender seu funcionamento.
Este guia explica o que o Sender Rewriting Scheme faz, onde pode falhar e como estruturar uma cadeia de encaminhamento funcional. Se você também está investigando problemas mais amplos de entrega, como registros MX incorretos, regras catch-all mal configuradas ou mudanças no DNS que afetaram as rotas, comece pelo guia de configuração e correção do encaminhamento de e-mail.
Por que o SPF pode falhar quando você encaminha e-mails
No encaminhamento, o servidor intermediário envia a mensagem a partir do próprio IP, mas o remetente do envelope pode continuar usando o domínio original. Se o registro SPF desse domínio não autorizar o IP do intermediário, o SPF falha. Com DMARC p=reject, o destinatário pode rejeitar a mensagem se também não houver uma assinatura DKIM válida e alinhada. Uma rejeição SMTP é informada ao servidor de encaminhamento e pode gerar uma mensagem de falha na entrega. Ainda assim, o destinatário pode perceber apenas a ausência da mensagem, sem aviso visível.
O e-mail não percorre um canal contínuo. Ele passa por uma cadeia de conexões SMTP, com um novo handshake TCP em cada etapa. Veja um exemplo de como a falha pode ocorrer:
alice@client.comenvia paracontact@your-agency.com- Seu servidor aceita a mensagem: o IP do servidor de envio de Alice é autorizado pelo registro SPF de
client.com - Seu servidor abre uma nova conexão SMTP com o Gmail para encaminhar a mensagem
- O Gmail identifica que a conexão vem do seu IP
- O remetente do envelope continua sendo
alice@client.com - O Gmail verifica o SPF de
client.com: seu IP não está autorizado - O SPF falha. Se
client.comusarp=rejecte não houver uma assinatura DKIM válida e alinhada, o Gmail pode rejeitar a mensagem
A RFC 7208, especificação do SPF, reconhece expressamente esse problema no encaminhamento. O SPF sozinho não preserva a autorização original ao longo de uma nova conexão. Uma das formas de tratar o problema é modificar o remetente do envelope.
As duas identidades do remetente: envelope e cabeçalho
O e-mail tem duas camadas de identidade do remetente. O remetente do envelope (RFC 5321, MAIL FROM, P1) é usado na verificação SPF e no direcionamento de mensagens de falha na entrega. Ele serve principalmente aos servidores, mas também pode ser consultado no Return-Path dos cabeçalhos brutos. O From do cabeçalho (RFC 5322, P2) é o remetente exibido no Gmail ou no Outlook. O encaminhamento pode separar essas identidades. O Sender Rewriting Scheme atua no envelope sem alterar o remetente visível.
| Camada | Nome técnico | RFC | Finalidade | Visível para |
|---|---|---|---|---|
| Remetente do envelope | MAIL FROM / Return-Path | RFC 5321 (P1) | Verificação SPF e direcionamento de falhas na entrega | Principalmente servidores; consultável nos cabeçalhos brutos |
| From do cabeçalho | Cabeçalho From: | RFC 5322 (P2) | Remetente exibido nos clientes de e-mail | Usuários finais |
Quando você encaminha um e-mail, o From do cabeçalho continua sendo alice@client.com. Seu servidor cria uma nova transação SMTP, e o SPF é avaliado com base no remetente do envelope nessa etapa. Se o novo servidor de envio não estiver autorizado pelo domínio, ocorre o problema descrito.
O que o Sender Rewriting Scheme realmente faz
O Sender Rewriting Scheme reescreve o endereço do remetente do envelope (P1) antes de o servidor de encaminhamento abrir a nova conexão SMTP. O From do cabeçalho, visto pelo usuário, permanece inalterado. O novo domínio do envelope pode autorizar o servidor intermediário por SPF. Assim, o SPF pode passar no destino quando a configuração está correta, mas isso não garante a entrega nem o alinhamento DMARC com o domínio From original.
A analogia com o correio: Sem Sender Rewriting Scheme, você recebe a carta de Alice, coloca em uma nova mala postal e mantém o endereço de retorno dela. O destino vê uma entrega feita por você, mas com um endereço que sugere que veio de Alice. Isso pode levar à rejeição. Com Sender Rewriting Scheme, você substitui o endereço de retorno de Alice pelo seu. O caminho de retorno passa a corresponder ao intermediário. Se a mala precisar voltar, chega até você, que a redireciona para Alice.
| Componente | Antes do encaminhamento | Após a reescrita SRS |
|---|---|---|
| From do cabeçalho (P2) | alice@client.com | alice@client.com (inalterado) |
| Remetente do envelope (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| IP de envio | Seu servidor | Seu servidor |
| Resultado SPF no exemplo | FAIL | PASS |
Como interpretar o formato de um endereço SRS
Quando o Sender Rewriting Scheme está ativo, ele transforma o remetente do envelope em um endereço codificado antes do encaminhamento. O domínio desse endereço precisa estar configurado corretamente para a rota de envio. A estrutura contém um valor criptográfico para validação, um marcador de tempo para limitar a validade e o endereço original do remetente para redirecionar mensagens de falha na entrega. Não são caracteres aleatórios: são dados estruturados. A proteção efetiva depende da implementação.
Um exemplo de endereço reescrito por SRS:
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: primeiro encaminhamento.
SRS1pode aparecer quando a mensagem é encaminhada novamente, limitando o crescimento do endereço nas implementações que oferecem esse comportamento - 4fac: exemplo de valor de verificação HMAC-SHA1 dessa implementação. Valida mensagens de falha na entrega recebidas; valores inválidos podem ser rejeitados para dificultar o uso do servidor em ataques de backscatter
- PM: marca temporal. A janela configurável pode ser, por exemplo, de 7 a 21 dias. Endereços expirados podem ser rejeitados, mas isso não é uma garantia universal contra ataques de repetição
- client.com=alice: remetente original codificado, usado para redirecionar mensagens de falha na entrega ao endereço correto
Quando você precisa de Sender Rewriting Scheme
O Sender Rewriting Scheme é relevante quando você encaminha e-mails automaticamente entre domínios e o IP do intermediário não está autorizado pelo SPF do remetente original. Políticas DMARC rigorosas tornam arriscada uma infraestrutura de encaminhamento sem medidas adequadas de autenticação. O SRS trata o SPF do domínio reescrito no envelope, não todos os problemas de entrega.
Domínio próprio encaminhado para um Gmail pessoal. Você tem cool-startup.com e encaminha todas as mensagens para founder@gmail.com. O SRS pode ajudar na verificação SPF. Sem reescrita, mensagens de bancos, órgãos públicos e outros remetentes com DMARC rigoroso podem falhar no SPF. A aprovação no DMARC ainda pode depender de uma assinatura DKIM válida e alinhada.
MSP ou agência com um cluster de e-mail compartilhado. Você hospeda 200 domínios de clientes. Eles configuram encaminhamentos para provedores como Comcast, AT&T e Outlook. O spam encaminhado pode ser atribuído ao seu IP de envio, mesmo que não tenha sido criado por você. Falhas de autorização SPF e envio indesejado podem prejudicar a reputação e contribuir para uma listagem na Spamhaus, em um cenário desfavorável até dentro de algumas semanas. Isso não é inevitável nem um risco eliminado apenas pelo SRS.
Microsoft 365 com um conector de saída. O M365 pode aplicar SRS internamente nas rotas de envio compatíveis. Ao encaminhar tráfego por um conector de saída, verifique se a reescrita ocorre antes da transferência. Configure SenderRewritingEnabled somente quando a versão e o conector oferecerem suporte e a alteração estiver autorizada. Confira também a política de filtro de spam de saída para o bloqueio de encaminhamento externo com 5.7.520: trata-se de uma política, não de prova de falha no SRS.
Por que o Sender Rewriting Scheme não basta
O Sender Rewriting Scheme pode viabilizar o SPF do novo domínio do envelope, mas não estabelece automaticamente o alinhamento DMARC com o From original. O DMARC exige autenticação válida e alinhada por SPF ou DKIM. O SRS troca o domínio do envelope pelo domínio de encaminhamento, mantendo o From do cabeçalho como o domínio original. Se os domínios não estiverem alinhados, uma assinatura DKIM válida e alinhada precisa sobreviver ao trânsito para que o DMARC passe.
Servidores de encaminhamento podem invalidar assinaturas DKIM quando alteram partes assinadas de uma forma que a canonicalização utilizada não preserva:
- Adicionar
[EXTERNAL]ao assunto pode invalidar o DKIM se esse cabeçalho estiver assinado - Acrescentar um rodapé, como um aviso de verificação de vírus ou um link de descadastramento, pode alterar o hash do corpo assinado e invalidar o DKIM
- Reescrever o MIME, por exemplo convertendo a codificação de 8 bits para 7 bits, pode alterar conteúdo assinado e invalidar o DKIM
No cenário de falha, o SPF não fica alinhado com o From original e as alterações invalidam o DKIM. O DMARC então falha. O destinatário pode rejeitar a mensagem conforme sua política; pode haver uma rejeição SMTP ou uma mensagem de falha na entrega.
Uma medida complementar é o ARC (Authenticated Received Chain, RFC 8617). Ele permite que o intermediário registre os resultados de autenticação realmente observados em uma cadeia assinada. São adicionados três cabeçalhos:
ARC-Authentication-Results: registra os resultados de SPF, DKIM e DMARC realmente observados na chegada, e não necessariamente verificações bem-sucedidasARC-Message-Signature: assina o estado da mensagem no momento da assinatura ARCARC-Seal: assinatura criptográfica que vincula o conjunto ARC à cadeia
Um destinatário como o Gmail pode avaliar o ARC quando a autenticação atual de uma mensagem encaminhada falha. Cabe ao destinatário decidir se aceita a cadeia e confia nela para orientar a entrega. O ARC não corrige o alinhamento DMARC. Essa confiança não pode ser imposta nem garantida apenas pela reputação do domínio construída ao longo do tempo.
Como verificar se o Sender Rewriting Scheme está funcionando
Envie uma mensagem de teste de uma conta externa para o endereço encaminhado e examine os cabeçalhos brutos no destino. O cabeçalho Return-Path mostra se a reescrita SRS está visível nessa mensagem ou se o endereço original do remetente foi mantido. Verifique também os resultados de autenticação.
Etapa 1: verificar o Return-Path no destino
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>Etapa 2: verificar o DNS do domínio SRS
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comO domínio SRS precisa de autorização SPF adequada e de uma rota acessível para receber mensagens de falha na entrega. Verifique a configuração MX para isso. A ausência de um registro MX não significa automaticamente que a rota seja inacessível: em determinadas condições, a entrega pode ocorrer implicitamente por registros A ou AAAA. O importante é que o caminho de retorno funcione; problemas nele podem contribuir para rejeições.
Etapa 3: consultar o log de e-mail no Linux
grep "srs_forward" /var/log/mail.logMensagens como hash mismatch ou timestamp expired podem indicar chaves do PostSRSd fora de sincronia, rotação de chaves, atrasos, endereços corrompidos ou uma tentativa de repetição. Elas não comprovam um ataque. O Postfix não inclui SRS nativamente; o PostSRSd é uma integração possível, cuja versão e configuração precisam ser verificadas. Confira se sua versão usa SRS_EXCLUDE_DOMAINS e defina as exceções locais conforme seus domínios e regras de roteamento para evitar reescritas desnecessárias do tráfego interno. Uma exceção ausente não causa obrigatoriamente um loop, mas pode dificultar o diagnóstico.
A alternativa mais simples: parar de encaminhar
O Sender Rewriting Scheme trata um problema criado pela nova conexão SMTP do encaminhamento. Uma caixa de e-mail IMAP real no seu domínio pode eliminar essa etapa adicional. A mensagem chega diretamente à caixa, e o cliente a acessa por IMAP. Isso evita os problemas de autenticação causados por esse encaminhamento, mas não elimina todos os riscos de SPF, DKIM ou DMARC. O IMAP não garante autenticação de ponta a ponta.
O encaminhamento é popular porque ninguém quer pagar por usuário por uma caixa que recebe cinco e-mails por mês. Por isso, o SRS às vezes faz parte de uma solução para um problema de preço, não apenas para uma questão técnica.
O modelo TrekMail descrito propõe outra abordagem: planos a partir de $3.50 por mês, com vários domínios e armazenamento compartilhado a preço fixo, sem cobrança por usuário. Verifique os preços, limites e recursos atuais do plano escolhido. Você pode operar sales@yourdomain.com como uma caixa IMAP real e acessar as mensagens por clientes ou integrações compatíveis. A conexão com Gmail ou Outlook depende do suporte disponível. Sem encaminhamento externo, deixa de ser necessária a configuração SRS e ARC dessa etapa, mas os demais cuidados com autenticação continuam relevantes.
Para ambientes com vários clientes, o guia de hospedagem de e-mail para múltiplos domínios explica como centralizar a gestão de dezenas de domínios. Se você mantém uma configuração híbrida, com algumas caixas reais e alguns encaminhamentos legados, o guia de encaminhamento de aliases de e-mail aborda a configuração de uma rota com SRS.
Quer você mantenha o encaminhamento ou migre para caixas reais, entenda o que o Sender Rewriting Scheme faz, confirme sua aplicação e complemente com ARC quando houver suporte e fizer sentido. Uma infraestrutura de encaminhamento incompleta pode perder mensagens legítimas. Isso é um risco para o negócio, não apenas uma curiosidade técnica.
Comece com uma conta gratuita TrekMail e confira as condições atuais da oferta descrita, sem cartão e sem expiração do período de teste. Assim, você pode experimentar o e-mail para múltiplos domínios sem a complexidade adicional do encaminhamento.
