Sender Rewriting Scheme SRS: função e limites

Você configura um encaminhamento: contact@your-agency.com → you@gmail.com. Faz o teste e funciona. Duas semanas depois, o contrato de um cliente empresarial não chega, nem aparece no spam. Nos logs, você encontra: 550 5.7.1 Unauthenticated email. Ou 550 5.7.520 Access denied, que no Microsoft 365 pode indicar uma restrição ao encaminhamento externo de saída. Cada erro exige seu próprio diagnóstico. A ausência da mensagem não significa que não houve rejeição SMTP ou aviso de falha na entrega.

Uma medida possível contra falhas de SPF causadas pelo encaminhamento é o Sender Rewriting Scheme, SRS. Sem reescrita, o SPF pode falhar quando o domínio original do remetente do envelope não autoriza o intermediário. Em 2026, os requisitos do Google e do Yahoo não equivalem a uma obrigação universal de DMARC p=reject para todos os remetentes (requisitos do Google para remetentes de e-mail). Sem autenticação alinhada, políticas rigorosas podem contribuir para a rejeição. Este guia explica a atuação do SRS no protocolo, seus limites e as medidas complementares.

Para entender o conjunto, comece pelo nosso guia de configuração do encaminhamento de e-mail e correção de problemas comuns.

O que é Sender Rewriting Scheme (SRS)?

O Sender Rewriting Scheme, SRS, reescreve o remetente do envelope e pode evitar falhas de SPF causadas pelo encaminhamento. Antes de enviar a mensagem adiante, seu servidor troca o endereço do envelope SMTP (MAIL FROM) por um endereço do seu domínio de encaminhamento. Esse endereço normalmente não aparece como remetente na interface, mas pode ser consultado nos cabeçalhos brutos. O destinatário passa a verificar o SPF do seu domínio. A verificação pode passar se o registro DNS autorizar a rota real de envio e estiver correto nos demais aspectos. Sem reescrita, o domínio original pode não autorizar seu servidor. Uma falha de SPF, porém, não prova falsificação nem significa automaticamente falha no DMARC.

As duas camadas de identidade do e-mail

Separar duas identidades distintas do remetente facilita o diagnóstico de SRS. O SPF verifica a camada do envelope. O DMARC verifica se pelo menos uma autenticação válida, por SPF ou DKIM, está alinhada com o domínio From visível. O encaminhamento pode alterar essas relações.

Camada	RFC	Campo	Verificado por	Visível para o destinatário?
Envelope (P1)	RFC 5321	MAIL FROM / Return-Path	SPF	Não na exibição usual; consultável nos cabeçalhos brutos
Cabeçalho (P2)	RFC 5322	From:	Alinhamento DMARC	Sim

O envelope participa da transmissão SMTP e define o caminho de retorno de mensagens de falha na entrega; o SPF verifica seu domínio de remetente. O cabeçalho From aparece no cliente de e-mail e fornece o domínio de referência para o DMARC. Quando o encaminhamento cria uma nova conexão SMTP, a autorização SPF original pode deixar de corresponder ao servidor. O SRS pode ajudar nessa verificação, sem resolver todos os problemas de autenticação.

Uma nova etapa: por que o SPF pode falhar no encaminhamento

Ao encaminhar uma mensagem, seu servidor abre uma nova conexão SMTP com o destino, acrescentando uma etapa à rota. O remetente do envelope continua sendo alice@bank.com, mas o IP da conexão agora é o seu. O SPF verifica seu IP no registro de bank.com. Se ele não estiver autorizado, o SPF falha. Se bank.com publicar DMARC p=reject, o destinatário pode rejeitar a mensagem quando também não houver uma assinatura DKIM válida e alinhada. Pode haver um erro SMTP ou uma mensagem de falha na entrega; a rejeição não é sempre silenciosa.

Etapa	Ação	Remetente do envelope	IP da conexão	Resultado SPF
1	Alice → seu servidor	alice@bank.com	IP do banco	PASS
2	Seu servidor → Gmail	alice@bank.com	IP do seu servidor	FAIL - não autorizado para bank.com

Isso não precisa ser um erro de configuração: a nova conexão faz parte do funcionamento do encaminhamento. O problema ocorre quando o domínio original não autoriza o intermediário. O SRS é uma forma de lidar com isso, mas nem todas as rotas se comportam da mesma maneira.

Como o Sender Rewriting Scheme (SRS) reescreve o envelope

O SRS substitui o endereço do envelope MAIL FROM por um endereço do seu domínio de encaminhamento antes de abrir a nova conexão SMTP. Isso pode permitir que o SPF desse domínio passe. O cabeçalho From: visto pelo destinatário permanece como o remetente original o definiu.

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

No exemplo, o servidor de destino verifica o SPF de your-domain.com, que autoriza seu servidor. O SPF passa sob essa condição. O destinatário continua vendo From: alice@bank.com. O SRS viabilizou a verificação SPF imediata, mas o alinhamento com o From original precisa ser avaliado separadamente.

Como interpretar o formato do endereço SRS

O endereço SRS no Return-Path parece confuso à primeira vista, mas cada trecho tem uma função. Entender sua estrutura ajuda a identificar a reescrita visível e investigar possíveis falhas com mais precisão.

Exemplo: SRS0=4fac=PM=bank.com=alice@your-domain.com

Componente	Valor	Finalidade
Prefixo	SRS0	Marca a primeira reescrita. Em outro encaminhamento, pode ser usado SRS1 para limitar o crescimento do endereço; isso não permite uma cadeia de tamanho ilimitado.
Valor de verificação	4fac	Exemplo de código de autenticação HMAC com a chave secreta do seu servidor. A verificação dificulta a falsificação de endereços SRS de retorno, mas não garante proteção completa.
Marca temporal	PM	Exemplo de marca temporal cíclica em base32 de uma implementação. Pode limitar a validade dos endereços e reduzir riscos de repetição e backscatter, mas não os elimina.
Origem	bank.com=alice	Preserva os dados do remetente original para que seu servidor redirecione mensagens de falha na entrega para alice@bank.com.

A segunda dificuldade: o SRS não estabelece o alinhamento SPF

Há uma diferença importante: o SRS pode viabilizar a verificação SPF, mas não estabelece automaticamente o alinhamento SPF com o From visível. Para o DMARC, SPF ou DKIM precisa ser válido e alinhado. Por isso, mensagens encaminhadas podem continuar falhando mesmo com o SRS configurado corretamente.

O DMARC exige que um domínio autenticado com sucesso esteja alinhado com o domínio do cabeçalho visível From:. No exemplo com SRS ativo:

Verificação SPF: PASS - seu IP está autorizado pelo domínio do envelope your-domain.com
Alinhamento SPF: FAIL - envelope your-domain.com ≠ cabeçalho bank.com

Sem alinhamento SPF, a aprovação no DMARC depende de uma assinatura DKIM válida e alinhada. Se o remetente original assinou dessa forma e as partes assinadas permanecem intactas sob a canonicalização utilizada, o DMARC pode passar pelo DKIM. Avisos como “External Email”, rodapés de antivírus ou conversões MIME de 8 bits para 7 bits podem invalidar o DKIM quando alteram conteúdo assinado.

No cenário de falha, não há alinhamento SPF e as mudanças invalidam o DKIM. O DMARC falha, e o destinatário pode rejeitar a mensagem, mesmo que o SRS tenha cumprido sua função para o domínio do envelope. A existência e a forma de um aviso de falha dependem da rota de envio.

ARC como complemento ao Sender Rewriting Scheme SRS

O ARC (Authenticated Received Chain, RFC 8617) complementa o SRS. Enquanto o SRS reescreve o envelope para a verificação SPF, o intermediário pode usar o ARC para registrar, com assinaturas, os resultados de autenticação realmente observados. O próximo destinatário recebe informações sobre verificações anteriores. Isso não significa que todas passaram nem que a mensagem esteja livre de spam.

O ARC adiciona três cabeçalhos: ARC-Authentication-Results, ARC-Message-Signature e ARC-Seal. Os resultados podem documentar a autenticação anterior. A assinatura da mensagem, porém, é sensível a alterações no conteúdo assinado; ela não resiste a toda mudança no corpo. O ARC não corrige uma assinatura DKIM inválida nem restaura o alinhamento DMARC.

A ressalva: o destinatário decide se confia no signatário ARC e na cadeia. No Microsoft 365, um administrador autorizado pode configurar signatários ARC confiáveis pelo PowerShell com Set-ArcConfig, quando a configuração atual do tenant oferecer suporte e exigir esse ajuste. Não é uma etapa manual obrigatória para todo ambiente. A confiança do Gmail também não pode ser imposta manualmente.

Em produção, SRS e ARC podem se complementar: o SRS ajuda o SPF do novo envelope, enquanto o ARC oferece contexto para a decisão do destinatário. Eles não são obrigatórios em toda configuração nem, juntos, garantem entrega confiável a todos os grandes provedores.

Diagnóstico de problemas de SRS: uma lista de verificação

Se mensagens encaminhadas não chegam, use esta lista para verificar se o SRS está envolvido ou se a causa está em outro ponto da rota.

1. Verifique o cabeçalho Return-Path

Envie uma mensagem de teste de uma conta externa pelo encaminhamento e examine os cabeçalhos brutos no destino final. Os resultados abaixo são um exemplo, não um diagnóstico baseado apenas no endereço.

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. Verifique os bloqueios de saída do Microsoft 365

Se você encaminha mensagens para fora do Microsoft 365 e a restrição abaixo se aplica, elas são bloqueadas antes de sair do tenant. O SRS em um servidor posterior não corrige esse bloqueio.

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

Revise a política de filtro de spam de saída no portal Defender. Altere-a somente com autorização da organização e medidas de proteção adequadas. O SRS no servidor de recebimento não resolve essa restrição e não deve ser usado para contorná-la.

3. Verifique loops de roteamento

Se A encaminha para B e B volta a encaminhar para A, pode haver envio repetido, dependendo das regras e da proteção contra loops. Procure nos logs indícios como estes:

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

Em vez de encaminhar, hospede caixas de e-mail reais

Configurar postsrsd, gerenciar chaves HMAC e investigar falhas de alinhamento DMARC pode fazer parte do custo operacional de encaminhar e-mails profissionais para caixas pessoais para evitar cobrança por caixa. O SRS trata um problema dessa arquitetura. Uma caixa com entrega direta pode eliminar a etapa adicional de encaminhamento.

Abordagem anterior	Abordagem com TrekMail
Encaminhar sales@ para o Gmail e investigar falhas recorrentes de SRS	Hospedar sales@ como caixa IMAP real, com entrega direta
Configurar SRS, ARC e chaves secretas HMAC por servidor	Sem essa etapa de encaminhamento, não é necessária a configuração SRS correspondente
DKIM inválido pode contribuir para rejeitar mensagens encaminhadas quando não há outro alinhamento válido	Sem etapa adicional de encaminhamento; outros riscos de autenticação continuam existindo
Mensagens ausentes sem visibilidade suficiente da entrega	Logs de entrega e rastreamento de mensagens no painel, conforme os recursos e o plano atuais

Em vez de encaminhar contact@client-domain.com para o Gmail e manter a configuração SRS, você pode hospedar contact@client-domain.com como caixa IMAP real no TrekMail. O acesso por um cliente compatível, como uma integração suportada no aplicativo Gmail, depende do suporte a IMAP. A entrega ocorre diretamente na caixa. Deixam de existir a etapa adicional de encaminhamento SMTP e sua reescrita do envelope, não todos os problemas de autenticação. Compare as abordagens no guia de encaminhamento de e-mail do domínio para o Gmail ou na comparação entre alias e caixa de e-mail.

Você gerencia vários domínios de clientes? Em vez de investigar o SRS em cada servidor, pode centralizar os domínios no TrekMail com caixas separadas. O isolamento, a disponibilidade e o tempo de configuração dependem dos ajustes e recursos atuais; não há garantia de configuração em poucos minutos nem de isolamento absoluto de segurança. Nosso guia de hospedagem de e-mail para múltiplos domínios explica a gestão centralizada e o trabalho envolvido.

Os planos TrekMail descritos começam em $3.50 por mês, com uma avaliação gratuita de 14 dias. Verifique os preços, limites e condições atuais da avaliação. Configure caixas de e-mail reais para evitar o trabalho adicional do encaminhamento.