Why SPF fails on forwarded mail
Somewhere in your reports there is a cluster of rows that refuses to make sense: mail that is unquestionably yours, sent through a provider that is unquestionably configured correctly — failing SPF. Often the source IP belongs to a university, a small hosting company, or another mailbox provider entirely.
You are looking at forwarding, and it is not a fault. It is a structural property of how SPF works, it affects every domain on the internet, and understanding it explains one of the most important design decisions in email authentication: why DKIM, not SPF, is the foundation.
Why forwarding breaks SPF — every time
When someone forwards mail automatically — an alumni address relaying to Gmail, an old work mailbox redirecting to a new one, a sales@ alias fanning out to three people — the forwarding server accepts the message and then resends it from its own IP address.
SPF checks exactly one thing: is the IP that delivered this message authorised by the envelope-from domain's SPF record? The forwarder's server is not in your SPF record — of course it isn't; it's a university relay you've never heard of. So the check fails, deterministically, for mail that is completely legitimate.
There's no record change that fixes this. You cannot enumerate every forwarder on earth in your SPF record, and you wouldn't want to. (Some forwarders rewrite the envelope-from to their own domain — a scheme called SRS — which makes SPF pass, but for the forwarder's domain, not yours. Unaligned, so for DMARC purposes the outcome is identical.)
Why DKIM survives — and carries the message
DKIM was built for exactly this. The signature travels inside the message, and it verifies against your public key in DNS no matter which servers the message passed through. One hop or five, forwarded twice or not at all — as long as the signed content arrives unmodified, the seal holds.
Now recall the DMARC rule: a message passes if aligned SPF passes or aligned DKIM passes — one is enough. So the fate of a forwarded message is:
| Check | Result | Why |
|---|---|---|
| SPF | fail | Delivered from the forwarder's IP |
| DKIM | pass, aligned | Signature travelled intact |
| DMARC | pass | One aligned pass carries it |
This is the reason DKIM is the foundation of a durable DMARC deployment. A domain relying on SPF alone loses every forwarded message the day it moves to p=reject; a domain with aligned DKIM on every sender barely notices forwarding at all. The full pass/fail logic is in DMARC alignment explained.
Mailing lists: the harder case
Traditional discussion lists — Mailman, Google Groups and their relatives — are forwarders with a twist: they modify the message. A [list-name] tag prepended to the subject, an unsubscribe footer appended to the body. Both are signed content, so the modification breaks the DKIM seal — exactly as a tamper-evident seal should break.
Now both checks fail: SPF because the list server delivered it, DKIM because the content changed. The message fails DMARC outright, at every subscriber's mailbox, even though you sent it in good faith.
The ecosystem's workaround is From-rewriting: the list replaces your address in the visible From with its own (Jane Doe via list <[email protected]>), so DMARC is evaluated against the list's domain — which authenticates fine. Most major list software does this automatically when it sees an enforcing policy on your domain. It's cosmetically ugly, but it works, and it happens on the list's side: as a sender there is nothing for you to configure.
ARC: real, useful, and not yours to rely on
ARC (Authenticated Received Chain) is the standards-track answer to the same problem. Each intermediary records the authentication results it saw when the message arrived, signs that record, and passes the growing chain along. The final receiver can then look back through the chain and see: "this message passed SPF and DKIM before the list touched it" — and choose to accept it despite the DMARC failure.
The operative word is choose. ARC gives receivers evidence, not obligations: whether to trust a given chain is a local decision, adoption is uneven, and a malicious intermediary could sign a chain too — which is precisely why receivers only honour chains from intermediaries they already trust. Gmail and Microsoft both evaluate ARC and do rescue legitimate list traffic with it.
As a sender, the practical takeaway is blunt: ARC will quietly save some of your forwarded mail, and you can neither depend on it nor influence it. Build your deployment as if it didn't exist; treat it as a bonus when it helps.
What to actually do
- Recognise the pattern, then leave it alone. Rows with
✕ failSPF but✓ alignedDKIM from IPs you don't recognise are forwarding. DMARC passed; nothing is wrong; nobody needs fixing. - Get aligned DKIM on every legitimate sender. This is the real action item. Any sender that relies on SPF alone is one forward away from failing.
- Accept a small residue. Mail that transits a content-modifying list without From-rewriting or an honoured ARC chain will fail, and at
p=rejectsome of it will bounce. For a typical domain this is a sliver of a percent — the accepted, industry-wide cost of blocking spoofing.
Your reports make the pattern easy to spot once you know its shape — and if you want to see it on live data first, the demo dashboard has a forwarded row waiting to be found.