You set up forwarding from an old address to your real inbox, and mail that used to arrive fine starts landing in spam or bouncing with an SPF failure. Nothing is wrong with the original sender. The act of forwarding itself broke authentication. This is one of the oldest and most stubborn problems in email, and it has two complementary fixes: the Sender Rewriting Scheme (SRS) at the forwarder, and the Authenticated Received Chain (ARC) that preserves the original verdict across hops. This guide explains exactly what forwarding breaks and how each fix works.
Why forwarding fails SPF
SPF authorizes which IP addresses may send mail on behalf of a domain. The receiving server looks at the envelope sender, the RFC5321.MailFrom address, extracts its domain, fetches that domain's SPF record, and checks whether the connecting IP is listed. When mail is sent directly, the sender's own servers are in the record and SPF passes.
Forwarding breaks this chain. The forwarding server receives the message, then relays it onward to the final destination from its own IP address, while leaving the original envelope sender unchanged. The final server now sees a message claiming to come from the original domain, but arriving from the forwarder's IP, which is not in the original domain's SPF record. SPF fails, because from the receiver's point of view an unauthorized host is sending as that domain.
$ dig TXT original-sender.com +short
"v=spf1 ip4:198.51.100.0/24 -all"
# Mail arrives at the final server from the forwarder:
# connecting IP 203.0.113.50 (the forwarder, NOT in the record above)
# envelope MailFrom: alice@original-sender.com
# SPF result: failWhat forwarding does and does not break
| Mechanism | Survives plain forwarding? | Why |
|---|---|---|
| SPF | No | Forwarder's IP is not in the sender's SPF record |
| DKIM | Usually, if unmodified | Signature covers the message; it stays valid if headers and body are untouched |
| DKIM when body is altered | No | Footers, subject tags, or re-encoding invalidate the signature |
| DMARC | Often | Fails if neither SPF nor DKIM stays aligned and valid |
DKIM is the resilient one. Because the signature travels inside the message and covers its content, a forwarder that changes nothing preserves a valid DKIM signature, and that aligned DKIM pass can carry DMARC on its own. The trouble starts when the forwarder modifies the message, for example a mailing list appending an unsubscribe footer or rewriting the subject. That edits the signed content, the DKIM signature no longer verifies, and now both SPF and DKIM are gone.
This is why a simple forward-to-my-real-inbox rule often behaves differently from a mailing list. A plain forwarder that relays the bytes unchanged usually keeps DKIM intact, so DMARC survives on DKIM alone even though SPF broke. A list that rewrites headers or adds a footer destroys DKIM as well, which is the scenario SRS and ARC were designed for. Knowing which kind of intermediary is in the path tells you whether you have one problem or two.
SRS: fixing SPF at the forwarder
The Sender Rewriting Scheme solves the SPF half. The insight is simple: since SPF checks the envelope sender's domain against the connecting IP, the forwarder should rewrite the envelope sender to a domain it controls. Then SPF is evaluated against the forwarder's domain, whose record does include the forwarder's IP, and it passes.
A rewritten return path encodes the original sender inside a local part on the forwarder's domain, so bounces can still be routed back correctly.
# Original envelope sender:
alice@original-sender.com
# After SRS rewriting at forwarder.net:
SRS0=hash=tt=original-sender.com=alice@forwarder.netNow the final receiver checks SPF for forwarder.net, finds the forwarder's IP authorized, and SPF passes. The encoded tokens let the forwarder reverse the rewrite if the message bounces, delivering the non-delivery report back to the true originator.
The catch with SRS and DMARC
SRS fixes SPF authentication, but it does not fix DMARC alignment by itself. DMARC compares the authenticated domain to the From header domain. After SRS, SPF authenticates forwarder.net, while the From header still reads alice@original-sender.com. Those do not align, so SPF contributes nothing to DMARC even though it now passes. If the forwarder also left DKIM intact, aligned DKIM still carries DMARC. If the forwarder broke DKIM too, DMARC fails despite SRS. SRS is necessary but not always sufficient.
ARC: preserving the original verdict
The Authenticated Received Chain fills the remaining gap. The idea is that a trusted intermediary records the authentication results it saw before forwarding, and cryptographically seals that record so the next hop can trust it. If a downstream receiver would otherwise fail a message because SPF and DKIM broke in transit, it can inspect the ARC chain, see that the message authenticated correctly when the forwarder first received it, and choose to honor that.
ARC adds three header fields at each participating hop.
| Header | Role |
|---|---|
| ARC-Authentication-Results (AAR) | Snapshot of the SPF/DKIM/DMARC results this hop saw |
| ARC-Message-Signature (AMS) | A DKIM-like signature over the message as this hop received it |
| ARC-Seal (AS) | A signature over the ARC headers, chaining this hop to the previous ones |
Each hop that handles the message adds a numbered instance of these headers, building a chain. A final receiver validates the chain and, critically, trusts it only if it trusts the forwarders that signed it. ARC does not force acceptance; it gives the receiver a reliable way to see the pre-forwarding verdict and apply local policy.
Putting it together
- SRS repairs SPF by rewriting the envelope sender to the forwarder's domain, so the forwarded hop passes SPF and bounces still route home.
- ARC preserves the authentication results the forwarder originally saw, so a receiver can honor a message whose SPF or DKIM broke in transit.
- For reliable delivery through forwarders and mailing lists you generally want both, because each solves a different half of the problem.
- Keeping DKIM intact matters most of all, since an untouched aligned DKIM signature is the cleanest way for forwarded mail to satisfy DMARC without special handling.
Verify your authentication records are live
Whether you run a forwarder or you depend on one, the fixes only work when your SPF, DKIM, and DMARC records are published correctly and resolving everywhere. Run your domain through the Valla DNS propagation checker to confirm the records are live across resolvers, then use our SPF and DMARC alignment guides to make sure the underlying authentication is sound before you lean on SRS and ARC to carry it through the extra hop.