A .forward file is about the most boring thing in Unix. One line: put an address in it, and mail sent to you gets re-sent there. It shipped with sendmail in the early 1980s. For thirty years it just worked.
Then email grew three authentication layers on top of a protocol that never expected them, and forwarding — that one boring line — became one of the most reliably broken things on the internet.
Here’s the part that still annoys me: forwarding doesn’t break because anyone did something wrong. You can configure everything by the book and still watch mail disappear. The breakage is structural. It’s baked into how SPF, DKIM, and DMARC interact the moment a message takes one extra hop.
SPF was doomed the moment mail moved
SPF checks exactly one thing: did this message arrive from an IP address the domain authorized to send for it? You publish a TXT record listing your mail servers, and the receiver compares the connecting IP against that list.
Now forward a message. Alice at example.com sends to bob@oldcompany.com, which forwards to bob@gmail.com. Gmail sees a connection from oldcompany.com’s forwarder. It checks example.com’s SPF record. The forwarder’s IP isn’t in it — of course it isn’t, example.com has never heard of oldcompany.com’s mail server. SPF fails. Every time. By design.
There’s no misconfiguration here to fix. SPF authenticates the wrong thing for a world where mail moves. It validates the last hop, but the domain you care about is at the first hop, and the two stop matching the instant anyone relays the message.
The patch for this is SRS, the Sender Rewriting Scheme, dreamed up around 2003 by Meng Weng Wong, one of SPF’s own authors. The forwarder rewrites the envelope sender to point back at its own domain — something like SRS0=...@oldcompany.com — so the SPF check now runs against oldcompany.com, which does authorize that server. SPF passes.
SRS works. It’s also an admission of defeat: you’ve made SPF pass by overwriting who the message claims to be from. Fine for SPF in isolation. Quietly fatal for the thing that came next.
DKIM survives — until it doesn’t
DKIM was the smarter design. Instead of checking the connecting IP, it signs the message itself: the sending domain hashes the headers and body, signs them with a private key, and publishes the public key in DNS. The receiver re-computes the hash and verifies the signature. Crucially, the signature travels with the message. Relay it through ten hops and it still verifies — as long as nobody touches the signed bytes.
That last clause is where it falls apart.
Plain forwarding usually leaves DKIM intact, and this is the only reason a lot of forwarding still works at all. SPF is dead on arrival, but DKIM survives, and DMARC needs only one of them to pass. So the message limps through on DKIM alone.
Mailing lists are a different animal. A list appends [listname] to the subject. It bolts an unsubscribe footer onto the body. Maybe it strips an attachment. Every one of those edits changes bytes that DKIM signed, the body hash no longer matches, and the signature breaks. Now SPF is broken (the list relayed it) and DKIM is broken (the list edited it). Both legs down at once.
Then DMARC turned a nuisance into an outage
For years, broken SPF on forwarded mail was a survivable annoyance, because most receivers treated SPF as advisory. DMARC raised the stakes. DMARC says: if neither SPF nor DKIM aligns with the From: domain and passes, apply my policy — and the policy can be reject. Bounce it.
On April 8, 2014, Yahoo published p=reject. AOL followed within days.
Overnight, every mailing list on earth broke. A Yahoo user posts to a list, the list edits the message and resends it, the message now fails both SPF and DKIM, and every receiver that honors DMARC bounces it — because Yahoo told them to. John Levine, who knows email infrastructure as well as anyone alive, put it flatly on the IETF list: “Yahoo breaks every mailing list in the world including the IETF’s.” Mailman shipped emergency workarounds inside two weeks. None were clean. The common one rewrites the From: header to be the list’s own address, so every message from a list now looks like it came from the list rather than the person who wrote it. Reply-to-author quietly stopped working for millions of people, and mostly still doesn’t.
That’s the tell. DMARC gets sold as authentication finally working. What actually happened is that one company flipped one DNS record and broke a decade of how the internet relayed mail, and the “fix” was to mangle the From: header so nobody has to confront the underlying authentication at all.
ARC is the patch on the patch on the patch
The current answer is ARC, the Authenticated Received Chain, RFC 8617, published in 2019 — five years after Yahoo lit the fire. ARC lets each intermediary record the authentication results it saw before it touched the message, and seal that record with its own signature. The final receiver reads the chain and reasons: SPF and DKIM fail now, but a forwarder I trust attests they passed before the list got its hands on it, so I’ll deliver anyway.
Read that again. “A forwarder I trust.” ARC doesn’t restore authentication; it asks you to trust an intermediary’s word that authentication used to hold. The entire premise of DMARC was to stop trusting hops you can’t verify. ARC’s answer is to reintroduce trusted hops, carefully, with signatures. We’ve come all the way around.
And it only works if the receiver honors your seal, which means the receiver has to decide your intermediary is trustworthy — a reputation judgment, not a cryptographic one. Gmail and Outlook honor ARC from forwarders they already trust. A small forwarder nobody’s heard of gets no such benefit of the doubt.
The actual lesson
Count the layers. SPF to authorize senders. SRS to un-break SPF for forwarding. DKIM to authorize the message instead of the IP. DMARC to enforce the first two. ARC to un-break DMARC for forwarding. Every layer exists to paper over a gap the previous layer opened.
The root cause never moved. SMTP was designed in 1982 for a network where any host relayed mail for any other host, on trust, with no notion of identity. Forwarding wasn’t an edge case in that design — it was the entire point. Every authentication scheme since has been an attempt to bolt identity onto a protocol built on its absence, and forwarding is where the bolt always shears off, because forwarding is the one operation that does exactly what SMTP was built to do.
If you run a forwarder, deploy SRS and ARC and move on; the alternative is worse. But don’t mistake any of it for a solution. It’s scaffolding around a building we can’t condemn, because half the planet still lives in it.