Forwarded Email Fails SPF — Why You Can't Fix It, and What Actually Works (2026)

Diterbitkan 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

You cannot make SPF pass for forwarded email — forwarding breaks SPF by design, and the honest fix is aligned DKIM, which survives forwarding. The scale is census-wide: 7,355,985 of 138,927,207 SPF-publishing domains authorise Namecheap’s forwarding include alone, with a strict-SPF share of <0.1%, according to the Defaults.Exposed census of 261 million domains.

Below: why no SPF record you could write survives forwarding, why SRS and ARC are not tools you control, and the fix that holds — DKIM signing with your own domain as your DMARC pass — plus the one case that breaks DKIM too (mailing lists that rewrite messages) and what to do about that residue.

Why does forwarding break SPF?

Receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, not the From header. When you send directly, your server’s IP is in your SPF record and the check passes. When your recipient auto-forwards the message on — to a personal Gmail, through a university alias, via a registrar’s forwarding product — the forwarder’s server retransmits it, usually keeping your domain on the Return-Path. The final receiver now asks: is this forwarding server authorised in your SPF record?

It isn’t, and it never will be: you didn’t choose the forwarder, you don’t know it exists, and the same message forwarded through a different service tomorrow would fail from a different IP. SPF answers one question — “did this IP come from a server the Return-Path domain authorised?” — and for forwarded mail the true answer is no. The fail is SPF working as specified, not your record being wrong.

The census shows how mainstream this path is: 7,355,985 domains authorise Namecheap’s email-forwarding include (spf.efwd.registrar-servers.com) — a single provider’s forwarding product, drawn from the 139 million SPF publishers — with a strict-SPF share of <0.1% and only 0.2% enforcing DMARC. That soft template is not carelessness: forwarding is precisely where a strict -all misfires, and the provider whose product is forwarding ships accordingly. The full qualifier story is in our ~all vs -all report, and the provider-by-provider picture in which email provider gives the strongest SPF.

Can’t I just add the forwarder’s server to my SPF record?

No — and the why is the whole article:

You can’t enumerate forwarders. Any recipient, anywhere, can forward your mail through any service. Your SPF record would need to list servers you cannot know about in advance.
Listing them would defeat the purpose. Big forwarding services relay mail for millions of customers. Put their ranges in your record and every message any of their users relays — including a spoofer’s — passes SPF as you.

The same logic rules out loosening your qualifier to “make forwarding work”: the qualifier isn’t why forwarded mail fails, and once DMARC is in play it changes less than most guides claim — see the qualifier data. The record isn’t the lever here. Stop pulling it.

What about SRS and ARC — don’t they fix forwarding?

They address it — but neither is yours to deploy:

Mechanism	What it does when mail is forwarded	Who controls it	Fixes your DMARC?
SPF	Fails: the forwarder’s IP isn’t in your record	You publish it; forwarding defeats it	No
SRS (Sender Rewriting Scheme)	Forwarder rewrites the Return-Path to its own domain so its retransmission passes SPF	The forwarder	No — the SPF pass now belongs to the forwarder’s domain, which doesn’t align with your From
ARC (RFC 8617)	Forwarder seals the original authentication results; the final receiver may trust the sealed chain	The forwarder and the receiver	Sometimes — at the receiver’s discretion, not yours
Aligned DKIM	Signature travels inside the message and still verifies after forwarding, with your domain on it	You	Yes

Data and mechanism status as of 2026-06-29.

SRS makes the forwarder’s SPF problem go away, not yours: rewriting the Return-Path changes whose SPF gets checked, while your From header — the domain DMARC defends — is untouched. ARC is a trust decision between infrastructure operators. If a guide tells you to “implement SRS” as a domain owner, it has confused you with the forwarding provider.

How do I make my email survive forwarding?

Make DKIM, aligned to your domain, your DMARC pass. A DKIM signature is cryptography carried in the message headers: it verifies wherever the message ends up, however many servers relayed it, as long as the signed content wasn’t modified. DMARC needs only one aligned pass — SPF or DKIM — so when forwarding kills the SPF leg, aligned DKIM keeps the message authenticated.

Run the free scan at defaults.exposed before touching DNS. It shows whether you have DKIM at all, whether it signs with your domain, and where your DMARC stands — so you fix the real gap rather than fighting your SPF record.
Confirm forwarding is actually your problem. In the Authentication-Results header of an affected message, direct mail passes SPF while the forwarded copy fails from the forwarding service’s IP. If SPF and DKIM pass but DMARC still fails, you have an alignment problem instead — see DMARC fails but SPF and DKIM pass.
Turn on DKIM signing with your own domain at every sending service — mailbox provider first, then ESPs and transactional senders. Provider defaults often sign with the provider’s domain, which doesn’t align; you want d=yourdomain. Start at how to fix DKIM, with click-paths for Google Workspace and Microsoft 365.
Verify alignment, not just a pass. The d= domain in the signature must match your From domain; dkim=pass on someone else’s domain does nothing for your DMARC.
Leave your SPF record alone. Keep it accurate for your direct mail — it still authenticates most of your traffic and remains your second DMARC leg. Just stop trying to make it cover forwarders.
Re-scan, then stage DMARC enforcement deliberately — next section, and the p=none to p=reject rollout guide.

This combination — SPF plus enforcing DMARC riding on aligned DKIM — is the forwarding-proof pattern, and it is rare: of the 77.5 million domains publishing ~all, only 9.2% (7,116,774) back it with an enforcing DMARC policy, and just 3.87% of the 261 million graded domains (10,092,481) complete the full SPF + DKIM + enforced-DMARC triad, per the census (2026-06-29).

What about mailing lists that rewrite messages?

The one forwarding path aligned DKIM doesn’t survive: mailing lists that modify the message — a [list-name] subject tag, an unsubscribe footer, a stripped attachment. Change the signed content and the body hash no longer matches, so DKIM fails too (dkim=fail: body hash did not verify is that failure’s own guide). Now both DMARC legs are dead, and only the list can mitigate it (From rewriting, ARC sealing).

This residue is exactly what staged DMARC enforcement is for. Moving through p=quarantine with a pct ramp while you watch aggregate reports shows how much of your real mail flows through rewriting lists before a p=reject policy starts bouncing it. Don’t jump to reject on a domain whose users live on mailing lists; don’t stall at p=none forever either. The staged rollout guide walks the ramp.

Frequently asked questions

Does forwarding break DKIM too? Plain forwarding, no: the signature travels with the message and verifies at the final receiver. DKIM breaks only when the signed content is modified in transit — mailing-list subject tags and footers being the classic case — which is why the list residue is handled by DMARC policy staging, not by anything in DNS.

Should I switch from -all to ~all so forwarding stops failing? Changing the qualifier won’t make forwarders pass — it isn’t why they fail. It is telling that Namecheap’s forwarding include, 7,355,985 domains and the census’s largest dedicated-forwarding population (2026-06-29), ships with a strict-SPF share of <0.1%: soft SPF is arguably the correct template for a forwarding product. See the ~all vs -all report for what the qualifier actually changes.

Why does my mail pass SPF when sent directly but fail when someone forwards it? The receiver checks whether the last transmitting server’s IP is authorised by your Return-Path domain’s SPF record. Direct: your server, in your record, pass. Forwarded: the forwarder’s server, not in your record, fail. Your record didn’t change — the transmitting IP did.

Can I set up SRS to fix this? Only if you are the forwarder. SRS runs on the server doing the forwarding, and even where it runs, the resulting SPF pass belongs to the forwarder’s domain and doesn’t align with your From — your DMARC still needs the DKIM leg.

Is SPF pointless if forwarding breaks it anyway? No. Most mail is delivered directly, where SPF works exactly as intended, and it remains one of your two DMARC legs. Of the 261,086,232 domains in the census (2026-06-29), 138,927,207 publish SPF — keep yours accurate via the SPF fix page, and let DKIM carry the forwarded remainder.

Send the owner the report

If you’re fixing this for a client or your employer, close the loop with evidence. Once custom-domain DKIM is live and DMARC is staged, re-run the free scan and forward the graded report to the business owner: dated, plain-language, showing the domain stays authenticated even when its mail is forwarded. That’s the artefact for the cyber-insurance renewal and the next supplier questionnaire — a documented before-and-after, not “I turned something on”.

Check your domain → · DMARC fails but SPF and DKIM pass → · Fix DKIM → · How we grade → · Aggregate data only. Data stored and processed in the EU.