The email was fine. Forwarding broke it.An email arrives, passes every check, looks perfect. Then it gets forwarded, and suddenly SPF fails. Nothing about the message changed. So what happened? A forwarder quietly swapped in a new server, and SPF only ever looks at the last one.
⬡ journey-flow, envelope travels captain@deepcurrent.io → your inbox → forwarder → final inbox, SPF stamp flips red at the last hopSPF checks one thing. Is the server that just handed off this message on the approved list for the sending domain? That list lives in DNS. Any server not on it fails the check. That's the whole job.
⬡ auth-flow, single SPF gate, connecting IP checked against a DNS list, green passNow say captain@deepcurrent.io emails you, and you've got auto-forwarding set up to another inbox. Your mail server passes the message along. At the next destination, that receiving server runs its own SPF check. The IP it sees isn't deepcurrent.io's server anymore. It's your forwarder's server. And that IP was never in deepcurrent.io's SPF record. SPF fails.
⬡ journey-flow, node 2 (forwarder) lights up as the new sending IP, SPF gate rejects itHere's the thing. This isn't broken. SPF is doing exactly what it was designed to do. It validates the last server to hand off the message, not the one that originally sent it. Forwarding swaps in a fresh server at that last hop, so the check breaks. Working as intended.
⬡ myth-fact, myth "forwarding is a bug in SPF" vs fact "SPF only ever checks the final hop"If that clicked, subscribe. We're working through every authentication question, one at a time.
⬡ title-card, subscribe line on screenYou might think, fine, I'll list every forwarder in my SPF record. You can't. You can't predict which forwarders your recipients use, and cramming them all in would blow past SPF's 10-lookup limit fast. There's no clean fix on the sender side.
⬡ record-cards, an SPF record ballooning with includes, a "10 lookups" counter tripping redThis is exactly why DKIM exists alongside SPF. DKIM signs the message content itself, so it survives simple forwarding as long as nothing modifies the message. And for the cases where forwarding breaks both, ARC lets legitimate forwarders carry the original results down the chain. Both are their own videos, linked below.
⬡ split-compare, LEFT "SPF: dies at the forward" vs RIGHT "DKIM: travels with the message"So the one idea: SPF checks the last server, and forwarding always makes that a different server. It's not a mistake to fix, it's a limit to plan around.
⬡ title-cardNext up: SPF can even pass and still fail alignment under DMARC. That's a sneaky one, and it's the next video.
⬡ end-card, Subscribe + Next: "Why forwarding breaks SPF alignment" (003.010.002)Why does email forwarding break SPF? SPF checks whether the server that just handed off your message is on the sending domain's approved list in DNS. When mail gets forwarded, the forwarder's server becomes the new sender at the final hop, and that IP isn't in the original domain's SPF record, so the check fails. This isn't a bug. SPF is designed to validate the last hop, and forwarding always swaps in a new one. You can't fix it by listing every forwarder (you'd blow past the 10-lookup limit). DKIM survives simple forwarding because it signs the content, and ARC carries original results through trusted forwarders.
Check what's currently authorized in your SPF record → reviewmyemails.com/tools/spf-checker
Next: Why forwarding breaks SPF alignment → [link 003.010.002]
Full written guide → reviewmyemails.com/emailalmanac/authentication/forwarding/how-forwarding-breaks-spf
#email #SPF #deliverability