Sender Rewriting Scheme addresses an envelope problem in forwarding. The intermediary changes the SMTP return identity into one it can support, rather than asking the next receiver to authorize the intermediary under the original sender's domain. That can improve SPF behavior and provide a route for returned delivery notifications. It does not, by itself, authenticate the visible author or approve the contents of a message.
Identify what is rewritten
References: RFC 7208 §2.4.
Compare MAIL FROM before and after the forwarding service. Keep the visible From header in a separate column. The rewritten local part can encode information needed by the forwarding implementation, but operational diagnosis should begin with the resulting domain and the reverse-routing behavior. Do not attempt to reconstruct an undocumented provider encoding from one sample and call it a universal format.
Microsoft documents its own use of SRS in Sender Rewriting Scheme in Microsoft 365. Its implementation rewrites applicable outbound forwarding envelopes and leaves the displayed From address unchanged. Microsoft also documents that relay-pool messages skip SRS and that on-premises routing has special cases. Provider-specific coverage and exceptions matter; that description is not evidence that every forwarding product behaves identically.
Recalculate SPF and alignment separately
References: RFC 7208 §4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5.
At the final receiver, evaluate the forwarding server's IP against the rewritten envelope domain's policy. If authorized, SPF can pass for that domain. Next compare that authenticated domain with the visible From domain under the applicable DMARC alignment mode. The two steps must not be merged into a single green indicator. RFC 7208 and RFC 9989 define those different questions.
For a visible From at author.example and rewritten envelope at forwarder.example, an SPF pass for forwarder.example does not provide strict alignment with author.example; these unrelated example domains also do not satisfy relaxed alignment. A surviving aligned DKIM signature can still make DMARC pass. If a footer breaks that signature, SRS has not repaired the remaining author-authentication failure.
Execute the paired cases
References: RFC 9989 §4.4.
Inspect the retained strict-alignment model cases srs-preserved and srs-footer. Both supply SPF pass for forwarder.example and the same visible author.example identity. Only the preserved case supplies aligned DKIM pass; the model consequently returns true only there. The trace records original and rewritten domain identities rather than presenting the encoded local part as proof of trust.
These are local model outcomes with supplied authentication booleans. The fixture neither implements the SRS encoding algorithm nor validates a bounce address, live SPF record or DKIM signature. No real provider forwarding samples were obtained. Use the example to design a real trace, not to claim deployment acceptance.
Verify operational behavior safely
References: RFC 7208 §2.4.
Within an authorized test setup, confirm that delivery failures return through the intended path and do not create an open forwarding or bounce-abuse channel. Retain only the sample data needed for diagnosis and avoid exposing encoded recipient information in public tickets. Check provider documentation for supported routing combinations and hybrid exceptions before making changes.
Treat the SRS service as one component in a forwarding design. Preserve signed content, monitor the forwarding reputation and record the final receiver's decision. If a business route still requires a local exception, review it separately; do not describe envelope rewriting as permission to skip sender authentication or content filtering. A successful return path is an operational result, not a certificate of the message's legitimacy.
Retained laboratory evidence
References: RFC 7208 §4, RFC 6376 §6.
The retained 7 November 2026 capture records two actual SMTP deliveries using an explicit SRS-shaped rewritten envelope at forwarder.example. pyspf evaluates the observed 127.0.0.3 peer against that domain's fixture policy and returns pass. dkimpy passes the preserved author signature and fails the footer-modified copy. The strict-alignment calculation consequently passes only the preserved case. The envelope strings and receiver observations are retained. This is an executed envelope rewrite, not an implementation of SRS encoding, timestamp validation, secret authentication or bounce reversal.
The retained runner and 7 November 2026 capture were inspected; no network experiment was rerun for this review. The original experiment used loopback only and sent no Internet mail. Its receiver creates Authentication-Results from its own checks, giving those fields known laboratory provenance. Authentication outcome and disposition remain separate: all six SMTP samples receive 250 under an explicit capture policy, including failing samples. The trust boundary is this controlled laboratory, not a production mailbox provider. The DNS adapter supplies retained fixture answers rather than querying public DNS, and the DMARC evaluator uses strict domain equality only. Full organizational-domain discovery, production policy parsing and live deployment outcomes remain untested.