Mail Sorcery

SPF Breaking During Forwarding: Why Legitimate Mail Still Fails

Before You Continue

If SPF itself still feels a bit fuzzy, start here:

./demystifying-spf.md

Then continue with this guide.

Forwarding is where SPF discovers that the email internet is held together with duct tape, legacy decisions, and optimism.

This is one of the most common support tickets in the “but the SPF record is correct!” category. The record is fine. The sender is legitimate. And the mail still gets flagged or rejected. Here’s why.

SPF Checks The Sending Server, Not The Original Sender

Remember, SPF works like a bouncer checking a guest list at the door. It checks one specific thing: which server actually connected and delivered the message. This is called the envelope sender, and it reflects whoever last handled the message, not necessarily who wrote it.

Under normal circumstances, this is fine. Your mail server sends the message, the receiving server checks SPF against your mail server’s IP, everyone’s happy.

Forwarding breaks this chain.

What Actually Happens During Forwarding

Say someone at companyA.com receives an email and has it auto-forwarded to their personal address, or a shared mailbox forwards mail to an external ticketing platform. Here’s the sequence:

The original sender’s mail server sends the message and passes SPF, because it’s authorized for its own domain.
The forwarding system receives the message and re-sends it onward, unchanged, to the final destination.
The final receiving server sees a message that claims to be from the original sender’s domain, but it arrived from the forwarding system’s IP address, not the original sender’s.
Since the forwarding system is not listed in the original sender’s SPF record, the SPF check fails.

The email was completely legitimate. Nothing was spoofed. SPF still fails, because SPF was never designed to account for a message changing hands along the way.

Why This Isn’t A Bug, It’s The Design

SPF was built to validate the direct connection between a sending server and a receiving server. Forwarding introduces a third party into that relationship, and SPF has no mechanism to say “this forwarding system is trustworthy, please pass this one through.” Some forwarding systems help by rewriting the envelope sender (a mechanism called SRS, Sender Rewriting Scheme), but plenty of systems don’t bother.

Why DKIM Usually Survives Forwarding Better

DKIM works differently. Instead of checking which server sent the message, DKIM adds a cryptographic signature to the message headers and body when it’s originally sent. That signature travels with the message, even when it’s forwarded, as long as the forwarding system doesn’t modify the signed content.

Because DKIM validates the content itself rather than the sending IP, it tends to survive forwarding intact far more often than SPF does.

Why DMARC May Still Pass Even If SPF Fails

This is the important part. DMARC requires that either SPF or DKIM passes, and that the passing mechanism is aligned with the visible “From” domain. This is called alignment.

So if SPF fails during forwarding but DKIM still passes and aligns, DMARC can still consider the message authenticated. This is exactly why relying on SPF alone is risky. A domain that only implements SPF, without DKIM, has no safety net once forwarding enters the picture.

Why SPF Should Never Be Your Only Layer

If there’s one takeaway from this article, it’s this: SPF is necessary, but never sufficient on its own. A complete email authentication setup includes:

SPF – authorizes which servers can send for your domain
DKIM – cryptographically signs messages so tampering is detectable
DMARC – ties SPF and DKIM together and tells receivers what to do when checks fail

Relying on SPF by itself means every forwarded email is a coin flip.

Janitor Tip 🧹

If a client complains that “emails forwarded from an old address keep landing in spam,” check DKIM alignment before touching the SPF record. Nine times out of ten, the fix isn’t in SPF at all.

Suggested Image

A simple flow diagram: Original Sender → Forwarding System → Final Receiver, with an SPF check icon showing a red “fail” mark at the final receiver step, while a DKIM signature icon travels unbroken through all three stages with a green checkmark.