When email forwarding breaks SPF (and what SRS repairs)

SRS: rewriting the envelope to save SPF

Naive forwarding actually creates two problems. The first is the SPF failure described above. The second is bounce routing: if the forwarded message is refused at the end of the chain, the failure notice heads back to the original Return-Path — to a sender who knows nothing about the forward and receives baffling bounces. SRS, formalized in the early 2000s in response to SPF's deployment, addresses both in a single move.

The principle: at resend time, the forwarder rewrites the Return-Path under its own name, encapsulating the original address in the local part. A message from smith@example.com forwarded by forward-example.net leaves again with an envelope of this shape:

MAIL FROM: SRS0=k3v7=T9=example.com=smith@forward-example.net

Two effects. First, the final server now evaluates SPF against forward-example.net, whose record does authorize the forwarder's IP: the check passes. Second, any bounce comes back to the forwarder, which unwraps the address and routes the notice to the original sender. Implementations are mature — SRS modules in the major mail suites, dedicated daemons on the Postfix side — and most serious hosting providers rewrite the forwards they operate today.

What SRS does not repair: DMARC alignment

So much for the plumbing. Identity remains — and this is where the enthusiasm cools. DMARC demands more than a passing SPF: it demands that the domain SPF validated align with the domain of the visible From, the one the recipient reads. After the SRS rewrite, however, the Return-Path belongs to the forwarder (forward-example.net) while the From still shows example.com. Two organizationally unrelated domains: alignment fails, in strict mode and relaxed mode alike — and the DNS Tree Walk of DMARCbis, which determines the organizational domain, will never bridge two zones foreign to each other.

The outcome is a pattern frequent enough in the reports to deserve a file of its own: SPF passing while DMARC fails. SPF shows green — for the forwarder's domain. DMARC, meanwhile, judges the original domain, and has only DKIM left to reach its verdict.

Put differently: SRS repairs the forwarder's deliverability and the routing of bounces; it does not repair the authentication of the original domain. After an SRS forward, a message's DMARC fate rests 100 % on the survival of its DKIM signature. Even seasoned teams discover this late: SRS is indispensable to modern forwarding, and perfectly neutral for the sender's DMARC alignment.

Three very concrete situations

The university alias. Universities hand out lifetime addresses (jane.smith@alumni-example.net) that store nothing: everything is forwarded to a personal mailbox, often Gmail. Every message sent to an alum therefore crosses the university's infrastructure before reaching Google. In the sending domain's reports, this draws characteristic lines: academic IPs, SPF failing (or passing on a third-party domain via SRS), and DKIM saving the day whenever the signature arrived intact.

The forwarded contact mailbox. A small business forwards contact@example.com to the owner's personal Gmail account. Here the domain plays the forwarder's role: it is the customers' messages that get resent, and their authentication that degrades. Without SRS, Gmail sees third-party mail arriving from an IP their SPF never authorized — with spam-foldering as the likely price, paid by the customers' mail, not the domain's. Operating a forward creates obligations toward other people's domains.

Internal redistribution. A service address (orders@example.com) that resends to three employees, or an old domain redirected to the new one after a merger: the same mechanics, except that the traffic is predictable and the infrastructure under control. It is the easiest case to clean up — and often the first one visible in the reports.

ARC, the complementary safety net

For forwarding chains that neither SRS nor DKIM manages to save, a third standard steps in: ARC (Authenticated Received Chain, RFC 8617). The idea: each intermediary seals, in dedicated headers, the outcome of the checks it performed itself upon receipt. The final receiver can thus observe that the message passed SPF and DKIM before the forward, and choose to override a DMARC failure observed on arrival.

The operative word is "choose": ARC forces nothing, it documents. The receiver only takes the chain into account when the intermediaries that signed it are trusted — Gmail and Microsoft 365 both evaluate it, each by its own criteria. The detailed workings, seal by seal, are laid out in the guide dedicated to ARC. A precious net, then, but a net only: nothing replaces a DKIM signature that survives the trip.

What the RUA reports show

The good news: forwarding leaves a highly recognizable fingerprint in aggregate reports. The relevant rows combine modest volumes, scattered and shifting IPs — universities, hosting providers, consumer mailbox operators —, an SPF failing against the original domain (or passing unaligned on a relay domain, SRS's telltale mark), and an aligned DKIM which alone keeps the DMARC verdict green.

The rows worth watching closely are the other ones: those where DKIM fails too. A relay that alters content — banner, re-encoding — produces legitimate mail failing across the board, the very mail that will be lost once the policy hardens. Estimating that residual share, relay by relay, is precisely the preparatory work of a move to enforcement: an analysis platform that names the IPs (this mailbox provider, that academic infrastructure) turns anonymous rows into an actionable diagnosis.

Which policy when forwarding is a fact of life

Does recipient-side forwarding rule out p=reject? No — but the step deserves to be taken with open eyes. Three principles apply. First, DKIM-sign absolutely every flow, transactional and application mail included: it is the only authentication that crosses forwards, and every unsigned flow is doomed at the first transfer. Second, quantify before hardening: the reports state precisely which share of legitimate traffic transits through signature-breaking relays — often a marginal fraction, sometimes a significant blind spot. Third, accept a residue: a domain at p=reject will lose the rare forwarded messages whose signature broke in transit. That is a real cost, usually tiny, to weigh against everything enforcement closes off to impersonators.

DMARCbis has not changed this trade-off — forwarding remains the model's acknowledged limit —, but its test mode (t=y), which replaces the old pct tag, provides a clean intermediate step to observe a policy's effect before making it fully binding.

In summary

A forward resends the message from the relay's IP, absent — legitimately so — from the original sender's SPF record: the SPF failure is structural, not accidental. DKIM survives as long as the content is untouched, which makes it the only reliable authentication across a transfer. SRS rewrites the Return-Path under the forwarder's name: it saves forwarding deliverability and bounce routing, but restores nothing of the original domain's DMARC alignment — after SRS, everything rests on DKIM, with ARC as a documentary net the large receivers are free to honor. In the reports the pattern reads clearly, and it can be managed: generalized DKIM signing, quantification of the residue, then enforcement.

The starting point sits within easy reach: one pass of the domain through the free DMARC analysis reveals the state of SPF, DKIM and the published policy, forwarding included. To then track those relayed flows week after week and steer the domain toward p=reject without sacrificing legitimate mail, creating an account opens the decoded reports, sources identified — including the ones that merely pass mail along.