Esquema de reescrita do remetente resolve um problema de envelope no encaminhamento. O intermediário altera a identidade de retorno SMTP para uma que possa suportar, em vez de solicitar ao próximo destinatário que autorize o intermediário no domínio do remetente original. Isso pode melhorar SPF comportamento e fornecer uma rota para notificações de entrega devolvida. Por si só, não autentica o autor visível nem aprova o conteúdo de uma mensagem.
Identifique o que está reescrito
Referências: RFC 7208 §2.4.
Comparar CORREIO DE antes e depois do serviço de encaminhamento. Mantenha o visível Do cabeçalho em uma coluna separada. A parte local reescrita pode codificar as informações necessárias para a implementação do encaminhamento, mas o diagnóstico operacional deve começar com o domínio resultante e o comportamento do roteamento reverso. Não tente reconstruir uma codificação de provedor não documentada a partir de uma amostra e chamá-la de formato universal.
A Microsoft documenta seu próprio uso do SRS em Esquema de reescrita de remetente no Microsoft 365. Sua implementação reescreve os envelopes de encaminhamento de saída aplicáveis e deixa o endereço De exibido inalterado. A Microsoft também documenta que as mensagens do pool de retransmissão ignoram o SRS e que o roteamento local tem casos especiais. A cobertura e exceções específicas do provedor são importantes; essa descrição não é evidência de que todos os produtos de expedição se comportem de forma idêntica.
Recalcular SPF e alinhamento separadamente
Referências: RFC 7208 §4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5.
No destinatário final, avalie o IP do servidor de encaminhamento em relação à política do domínio de envelope reescrito. Se autorizado, SPF pode passar para esse domínio. Em seguida, compare esse domínio autenticado com o domínio De visível no campo aplicável DMARC alinhamento modo. As duas etapas não devem ser fundidas num único indicador verde. RFC 7208 e RFC 9989 definir essas diferentes questões.
Para um From visível em author.example e um envelope reescrito em forwarder.example , uma passagem SPF para forwarder.example não fornece alinhamento estrito com author.example ; esses domínios de exemplo não relacionados também não satisfazem o alinhamento relaxado. Um alinhado sobrevivente Assinatura DKIM ainda pode fazer DMARC passar. Se um rodapé quebrar essa assinatura, o SRS não corrigiu a falha restante de autenticação do autor.
Execute os casos emparelhados
Referências: RFC 9989 §4.4.
Inspecione os casos do modelo de alinhamento estrito retido srs-preserved e srs-footer. Ambos fornecem passagem SPF para forwarder.example e a mesma identidade visível author.example . Apenas os suprimentos de caixa preservados alinhados DKIM passar; o modelo, conseqüentemente, retorna verdadeiro somente aí. O rastreamento registra identidades de domínio originais e reescritas, em vez de apresentar a parte local codificada como prova de confiança.
Estes são resultados do modelo local com booleanos de autenticação fornecidos. O aparelho não implementa o algoritmo de codificação SRS nem valida um endereço de rejeição, ao vivo Registro SPF ou assinatura DKIM . Nenhuma amostra real de encaminhamento de provedor foi obtida. Use o exemplo para projetar um rastreamento real, não para reivindicar a aceitação da implantação.
Verifique o comportamento operacional com segurança
Referências: RFC 7208 §2.4.
Em uma configuração de teste autorizada, confirme se as falhas de entrega retornam pelo caminho pretendido e não criam um canal de encaminhamento aberto ou de abuso de rejeição. Retenha apenas os dados de amostra necessários para o diagnóstico e evite expor informações codificadas do destinatário em tickets públicos. Verifique a documentação do provedor para obter combinações de roteamento compatíveis e exceções híbridas antes de fazer alterações.
Trate o serviço SRS como um componente em um design de encaminhamento. Preserve o conteúdo assinado, monitore a reputação de encaminhamento e registre a decisão final do destinatário. Se uma rota comercial ainda exigir uma exceção local, revise-a separadamente; não descreva a reescrita de envelope como permissão para ignorar a autenticação do remetente ou a filtragem de conteúdo. Um caminho de retorno bem-sucedido é um resultado operacional, não um certificado da legitimidade da mensagem.
Evidência laboratorial retida
Referências: RFC 7208 §4, RFC 6376 §6.
A captura retida de 7 de novembro de 2026 registra duas entregas SMTP reais usando um envelope reescrito em formato SRS explícito em forwarder.example . pyspf avalia o par 127.0.0.3 observado em relação à política de fixação desse domínio e retorna a passagem. dkimpy passa a assinatura do autor preservada e falha na cópia modificada pelo rodapé. Conseqüentemente, o cálculo de alinhamento estrito passa apenas no caso preservado. As sequências de envelope e as observações do receptor são retidas. Esta é uma reescrita de envelope executada, não uma implementação de codificação SRS, validação de carimbo de data/hora, autenticação secreta ou reversão de rejeição.
O corredor retido e a captura em 7 de novembro de 2026 foram inspecionados; nenhum experimento de rede foi executado novamente para esta revisão. O experimento original usou apenas loopback e não enviou nenhum email pela Internet. Seu receptor cria Authentication-Results provenientes dos seus próprios controlos, dando a esses domínios uma proveniência laboratorial conhecida. O resultado e a disposição da autenticação permanecem separados: todas as seis amostras SMTP recebem 250 sob uma política de captura explícita, incluindo amostras com falha. O limite de confiança é este laboratório controlado, não um fornecedor de caixa de correio de produção. O adaptador DNS fornece respostas de fixação retidas em vez de consultar DNS público, e o avaliador DMARC usa apenas igualdade de domínio estrita. A descoberta completa do domínio organizacional, a análise da política de produção e os resultados da implantação em tempo real permanecem não testados.