Why SPF Alone Is Not Enough to Stop Spoofing

Introduction

SPF is the original email authentication mechanism — and on paper, it sounds like enough. List the IPs allowed to send for your domain, receivers check against the list, done. In practice, three structural limits mean SPF alone can't stop spoofing. This article walks each limit and explains why modern email security stacks pair SPF with DKIM under DMARC.

Why this topic matters

A surprising number of domains still rely on SPF as their only authentication, then wonder why phishing emails using their brand keep getting through. Understanding what SPF can't do — not just what it can — is the precondition for building a stack that actually works.

Limit 1: SPF doesn't bind to the visible From

SPF authenticates the envelope-from (the SMTP MAIL FROM), not the header From the recipient sees. An attacker can:

• Send a message with envelope-from of [email protected]
• Have their domain's SPF pass (their record allows their IP)
• Put [email protected] in the visible From header

The receiver sees dkim=none, spf=pass (pass against the attacker's domain) and "From: you". Without DMARC alignment checks, nothing flags this. The SPF pass is meaningless because it's not for your domain.

DMARC is what closes this. SPF must pass AND align with the From header — at which point an attacker's SPF pass is irrelevant.

Limit 2: SPF breaks on forwarding

When a user forwards a message to another address, the forwarding server's IP is now the sending IP. That IP isn't in your SPF — so SPF fails at the second hop.

For mail that's frequently forwarded (mailing lists, group aliases, personal forwarding), SPF reliability drops fast. DKIM is what survives — the signature travels with the message and verifies regardless of routing.

Limit 3: SPF can be exhausted

The 10-DNS-lookup limit silently breaks SPF for high-include records. Stacking SaaS senders eventually exceeds the budget, and SPF returns permerror — which DMARC treats as fail.

A domain with many senders has to either move senders to DKIM-only or use SPF flattening to stay under the limit. SPF can't scale linearly with sender count.

What DKIM adds that SPF doesn't

DKIM solves all three limits:

• DKIM signs the message itself. The signature binds to the message body and headers, not just the sending IP. Alignment with the From header is the default state.
• DKIM survives forwarding. No IP dependency.
• DKIM doesn't have a lookup-limit problem. Each DKIM verification is one DNS query for one public key.

Why DKIM alone is not enough covers DKIM's complementary limits.

Step-by-step approach: a properly layered stack

1. Publish SPF for the IPs that send your transactional and primary mail. Keep it under 8 lookups.
2. Enable DKIM for every legitimate sender that supports custom signing. SaaS, internal mail server, transactional platforms.
3. Publish DMARC at p=none initially, tightening as reports stabilize.
4. Monitor aggregate reports per sender. Every sender should be at ≥99% pass via either SPF-with-alignment or DKIM-with-alignment.
5. Move to p=quarantine, then p=reject.

The result: SPF and DKIM each cover the cases the other can't, DMARC ties them together with policy enforcement.

Best practices

• Treat SPF as the IP allowlist, not the security control. It's necessary but not sufficient.
• Use DKIM as the load-bearing layer for sender authentication. It's the more durable mechanism.
• Don't try to fix spoofing with SPF alone. It can't.
• Watch DMARC reports to see how each is performing. Per-sender visibility is what makes the gap obvious.
• Migrate SaaS senders to DKIM-only when possible. Reduces SPF lookup pressure.

Recommended next step

Audit your current authentication state. If your DMARC reports show high SPF-only pass rates but low DKIM pass rates, you're vulnerable to forwarding failures and structural limits. Enable DKIM for every sender that supports it.

FAQ

Can I just configure SPF really strictly?

Even -all (hard fail) doesn't address the structural limits. Strictness affects what receivers do with SPF failures; it doesn't add per-message proof.

Why does SPF still get recommended if it's not enough?

Because it's still necessary. SPF as a layer of the stack works; SPF as the whole stack doesn't.

Will adding DKIM let me remove SPF?

No. DMARC needs at least one to pass with alignment. Keep both — they complement each other.

What if a sender doesn't support DKIM?

Use a subdomain isolation strategy or migrate to a sender that does. In 2026 the list of non-DKIM-capable senders is short.

Does SPF still help against spam?

Yes — receivers use SPF results as one input among many. It's the email-authentication-as-input layer.

Final thoughts

SPF is necessary, partial, and structurally limited. Recognizing those limits is what motivates the modern stack — SPF as one layer, DKIM as the load-bearing layer, DMARC as the policy that ties them.

No serious authentication architecture relies on SPF alone. If yours does, that's the first thing to fix.