To see why forwarding breaks, you have to know which "from" address SPF actually checks. Every email has two of them. There is the header From, the friendly address your mail client shows you, and there is the envelope sender, also called the return-path or MAIL FROM, which lives in the SMTP conversation between servers and is where bounce messages go. Users only ever see the first one. SPF only cares about the second.
What SPF Promises, and to Whom
Sender Policy Framework lets a domain publish, in DNS, the list of IP addresses allowed to send mail using that domain in the envelope sender. When a receiving server gets a message claiming MAIL FROM: alice@example.com, it looks up example.com's SPF record and checks whether the connecting IP is on the approved list. If it is, SPF passes. If not, SPF fails, and the message looks like forgery.
This works beautifully for direct mail. Alice's mail server is in example.com's SPF record, so when Alice emails Bob, the check passes at Bob's server. The trouble begins when Bob is not really the final stop.
The Forwarding Trap
Suppose Bob has an address at his alumni association, bob@alum.edu, that simply forwards everything to his real mailbox at a large provider. Alice sends to bob@alum.edu. The alum.edu server accepts the message and then relays it onward, keeping the original envelope sender, alice@example.com, because that is who the bounce should go back to.
Now the message arrives at the large provider's server. It runs an SPF check on alice@example.com. But the connecting IP is alum.edu's forwarder, which is nowhere in example.com's SPF record. SPF fails. The message was never forged, yet it now carries an authentication failure, and that failure can be enough to push it into the spam folder or get it rejected.
SPF authenticates the path the mail took, by checking the sending IP against the envelope sender's domain. Forwarding changes the path while keeping the original envelope sender. The two are fundamentally incompatible, and no amount of careful configuration on the original sender's side can fix it, because the original sender does not control the forwarder's IP.
The Idea Behind SRS
The Sender Rewriting Scheme was proposed by Meng Weng Wong, one of the people behind SPF itself, around 2003, precisely because SPF's authors knew forwarding would break. The insight is simple. If the problem is that the envelope sender belongs to a domain the forwarder is not authorized to send for, then the forwarder should rewrite the envelope sender to belong to its own domain. SPF then passes, because the forwarder is sending mail with its own domain in the return-path, which it is obviously authorized to do.
But you cannot just throw away the original sender, because bounces still need to find their way back to Alice. So SRS encodes the original address inside the new one. The rewritten envelope sender looks something like this:
SRS0=HHH=TT=example.com=alice@alum.edu
Read it right to left. The mail now comes from alum.edu, which is in alum.edu's SPF record, so SPF passes at the destination. Encoded in the local part are example.com and alice, the original domain and user. If a bounce comes back to this address, alum.edu can decode it, reconstruct alice@example.com, and deliver the bounce to the real sender.
The HHH and TT Are Not Decoration
The two short fields at the front, the hash and the timestamp, are what stop SRS from turning every forwarder into an abuse engine. Without them, a spammer could craft SRS-looking addresses to make your forwarder relay bounces to arbitrary victims, a problem called backscatter.
- HHH is a cryptographic hash, in practice a truncated HMAC computed with a secret key the forwarder holds. When a bounce arrives, the forwarder recomputes the hash over the address. If it does not match, the address was not one the forwarder issued, and the bounce is refused. This means only addresses your server actually signed will be honored.
- TT is a timestamp, encoded compactly. SRS addresses are meant to be short-lived, valid for a handful of days, just long enough for a legitimate bounce. After that the timestamp is stale and the address is rejected, which limits how long a leaked SRS address can be abused.
There is also a chained form, SRS1, for when an already-rewritten message is forwarded a second time, so the rewriting can be unwound hop by hop without the address growing without bound.
What SRS Does Not Fix
This is the part worth being precise about, because SRS is often misunderstood as a general fix for forwarded mail. It is not. SRS repairs SPF, and only SPF. It does nothing for DKIM, and that distinction drives a lot of modern email design.
DKIM signs the message itself, headers and body, with the originating domain's key. A plain forward that does not alter the message leaves the DKIM signature intact and valid. But the moment a forwarder modifies anything, a mailing list appending a footer, a server rewrapping the body, the signature breaks, and SRS cannot help.
This matters under DMARC, which requires that at least one of SPF or DKIM both pass and align with the visible header From domain. After SRS, SPF passes but aligns to the forwarder's domain, not to example.com, so it does not satisfy DMARC alignment for the original sender. The only thing that can carry authentication across a forward under DMARC is a surviving DKIM signature. When even DKIM cannot survive, because the message was legitimately modified in transit, the answer is a newer mechanism entirely: ARC, the Authenticated Received Chain, which lets each intermediary vouch for the authentication results it saw before it touched the message.
| Mechanism | Survives plain forwarding? | Survives a list that edits the message? |
|---|---|---|
| SPF (no SRS) | No | No |
| SPF with SRS | Passes, but realigns to forwarder | Passes, but realigns to forwarder |
| DKIM | Yes, if message unchanged | No |
| ARC | Yes | Yes, by design |
Where You Run Into This
If you use email aliases, and you should, since they are one of the cleanest ways to compartmentalize your identity, SRS is the machinery that keeps forwarded mail deliverable behind the scenes. Most alias and forwarding services implement it for you. The practical lessons are worth keeping in mind anyway. If you run your own forwarder, enabling SRS is not optional for reliable delivery. And if you are evaluating a privacy-focused alias service, the quality of its forwarding, SRS for SPF plus correct DKIM and ARC handling, is a real signal of whether the people running it understand email at the level that keeps your mail out of the spam folder.
Email authentication is a stack of patches layered over a protocol designed in a more trusting era. SPF, DKIM, DMARC, ARC, and SRS each fix a specific crack, and they only work when configured together with an understanding of what each one actually protects. We take that plumbing seriously at Haven because deliverability and anti-forgery are not features you can bolt on later. They are the difference between a message that arrives and one that silently disappears. If you want the bigger picture of why the open email system needs so much scaffolding, our piece on why email needs encryption covers the trust gaps these mechanisms are trying to paper over.