Forwarding breaks SPF. A message from [email protected] arrives at your forwarder with SPF already passing on the inbound hop (the forwarder’s server is the destination the receiver verifies against). The forwarder then re-sends the message onward to your Gmail. At Gmail, SPF is evaluated against the forwarder’s IP, which is not in bank.com‘s SPF record, so SPF fails. If bank.com publishes p=reject and DKIM did not also survive the forward, Gmail drops the message with no bounce. SRS is the scheme that keeps that from happening.
For a WordPress operator picking a forwarder, SRS is the capability that separates a serious inbound-forwarding service from a bare registrar’s DNS feature. It is also the one most forwarders implement without saying much about it; the operator-facing question is whether a given service does, and what the DNS footprint looks like when it does.
What SRS looks like on the wire
The envelope sender is the SMTP MAIL FROM address, distinct from the From: header the recipient’s mail client shows. SPF evaluates against the envelope sender’s domain, not the From: domain. SRS rewrites the envelope sender during the forwarding hop; the receiver verifies SPF against the rewritten address.
A typical SRS rewrite looks like this. The original envelope sender from bank.com:
MAIL FROM:<[email protected]>The forwarder (say, Cloudflare Email Routing) rewrites it to:
MAIL FROM:<[email protected]>The rewritten address lives at the forwarder’s own domain (email.cloudflare.net), which the forwarder’s SPF record authorises. The SRS0= prefix, a short hash (HHH), and a short timestamp (TT) encode the original sender so that bounces back to the forwarder can be re-rewritten and relayed to the real originator. The From: header is unchanged; what the reader sees is still [email protected].
The result at Gmail: SPF now evaluates against the forwarder’s domain, which the forwarder’s SPF authorises, and SPF passes. The sender’s identity (bank.com) is preserved in the visible From: header. The authentication story at the receiver is: SPF passed on the forwarder’s domain, DKIM may or may not survive, and DMARC evaluates alignment against the From: domain (bank.com) using either or both.
No RFC, de facto status
SRS has no RFC. Meng Weng Wong (one of the original SPF authors) first described it in 2003, in a draft that never advanced through the standards process. The scheme is in production at every serious forwarder nanoPost tracks nonetheless; the design is simple enough that convergent implementations interoperate, and the alternative (silent SPF failure on every forwarded message) is unacceptable.
The practical consequence of the missing RFC is that the exact encoding varies. Some forwarders use SRS0= and SRS1= prefixes with hash and timestamp fields; some use shorter encodings; some substitute the whole local part. For an operator reading mail logs, the shape to recognise is a long bang-path-style envelope sender at the forwarder’s own domain, with the original sender encoded inside.
What this means operationally: SRS implementation is a yes-or-no capability per forwarder, not a feature flag with versions to compare. The capability matrix in how email forwarding works for WordPress names which forwarders implement it.
SRS fixes SPF; it does not fix DKIM
The scheme operates on one authentication record and leaves the other alone. SPF at the receiver evaluates against the SRS-rewritten envelope sender and passes. DKIM at the receiver evaluates against the unchanged signed portion of the message and either survives the forward or does not.
For DMARC to pass under forwarding, at least one of SPF or DKIM must authenticate AND align with the From: header domain. SRS makes SPF pass on the forwarder’s domain, which does not align with the original sender’s From: domain. The alignment-earning authentication for a forwarded message is DKIM, which must survive the hop intact.
The forwarders that get the full picture right do both things: SRS on the envelope and DKIM-preserving relay behaviour (no footer injection, no subject rewriting, no header normalisation that touches signed bytes). Cloudflare Email Routing additionally adds its own DKIM signatures to the forwarded message, one on email.cloudflare.net for the rewritten envelope and one on the configured recipient domain, which gives ARC-aware receivers more authentication state to work with.
Bounces and the two-way rewrite
The SRS encoding exists for bounces. When the recipient’s mail server rejects the message after the forwarder has already accepted and relayed it, the bounce lands at the forwarder’s domain, addressed to the SRS-rewritten local part. The forwarder decodes the original sender from the SRS tokens, re-rewrites the envelope back to the original sender’s address, and relays the bounce the rest of the way.
The hash and timestamp in the SRS address are what keep this safe. A forwarder that accepted bounces from any sender to any SRS-rewritten address would become an open backscatter relay; the hash validates that the SRS address was genuinely issued by the forwarder, and the timestamp lets the forwarder expire old addresses to reduce the backscatter window. Forwarders that implement SRS correctly also implement the reverse-rewrite step; implementations that do only the forward rewrite silently drop bounces, which is a problem for the original sender who then has no delivery feedback.
What SRS does not do
SRS does not fix DKIM. A forwarder that implements SRS perfectly but injects a [FORWARDED] prefix into the subject line still breaks DKIM, and DMARC with p=reject still drops the message on DKIM alignment failure.
SRS does not fix the alignment problem for DMARC. The scheme realigns SPF to the forwarder’s domain, which does not match the original sender’s From: domain; alignment-earning authentication under forwarding comes from DKIM alone.
SRS does not apply to outbound WordPress mail. The scheme is a forwarder’s problem; a WordPress site sending through a transactional relay has no SRS story to care about, because the site is the originator of the message, not a hop in the middle. The failure mode SRS exists to prevent only happens when a message is being forwarded onward with the original sender’s identity preserved.
ARC is the forwarder’s cryptographic follow-up to what SRS does for SPF; ARC for forwarded WordPress mail is the companion entry. The receiver-side policy that makes any of this matter in the first place sits at DMARC for WordPress email. When you are ready to see forwarder and outbound sender in the same picture, how email forwarding works for WordPress walks the whole architecture.