What Is SPF and Why Does It Matter for DMARC?

Introduction

SPF — Sender Policy Framework — is the older of the two authentication mechanisms that DMARC ties together. It's the simplest of the email authentication standards: a single DNS record that lists the IPs allowed to send for your domain. Receivers check the connecting IP against that list. Match = SPF pass. No match = SPF fail.

This article walks through what SPF actually does, how it interacts with DMARC, and where it consistently falls short.

Why this topic matters

SPF is the foundation underneath DMARC. A domain without SPF can publish DMARC but will have a hard time passing the alignment check on a meaningful percentage of mail. Understanding SPF — including its limits — is what makes the rollout decisions intuitive.

How SPF actually works

A typical SPF record:

“text v=spf1 include:_spf.google.com include:mailgun.org ip4:198.51.100.0/24 ~all “

Reading it left to right:

• v=spf1 — version marker
• include:_spf.google.com — also allow whatever Google's SPF record lists
• include:mailgun.org — same for Mailgun
• ip4:198.51.100.0/24 — explicitly allow this IP range
• ~all — soft fail anything else (use -all for hard fail)

When a receiver gets mail, it looks up the SPF record for the envelope-from domain (the MAIL FROM in SMTP, not the visible From header), then checks whether the connecting IP is allowed.

How SPF feeds DMARC

DMARC adds two requirements on top of raw SPF: the SPF check must pass, and the domain that passed must align with the visible From header.

The alignment requirement is what stops SPF from being trivially gamed. An attacker can pass SPF for their own domain easily — but they can't make their SPF pass align with your From header. That's the entire reason DMARC works.

DMARC alignment explained covers the strict vs. relaxed nuances.

Why SPF alone falls short

Three structural limits:

1. SPF breaks on forwarding. If a recipient forwards your mail to another address, the forwarding server's IP isn't in your SPF — so SPF fails at the second hop. DKIM survives forwarding; SPF doesn't.
2. SPF is per-domain, not per-message. It can't prove a specific message originated from an authorized server, only that some mail from the envelope-from domain can come from this IP.
3. The 10-DNS-lookup limit. RFC 7208 caps SPF resolution at 10 DNS lookups. Stack too many include: references and SPF silently breaks for everyone. SPF too many DNS lookups covers the fix.

Why SPF alone is not enough to stop spoofing makes the deeper case.

Step-by-step approach to publishing SPF

1. Inventory senders. Every IP and platform that sends as your domain.
2. Compose the record. Start with v=spf1, add include: for each SaaS sender, ip4: or ip6: for direct IPs.
3. End with ~all (soft fail) or -all (hard fail). Soft fail is more forgiving during rollouts.
4. Publish as a TXT record at your apex domain. Not a subdomain — your root.
5. Validate with a checker. Confirm under 10 lookups.
6. Watch DMARC reports to confirm SPF is passing as expected.

SPF record best practices goes deeper.

Best practices

• Use one SPF record per domain. Multiple SPF records cause receivers to fail all of them.
• Keep under 10 DNS lookups. Use include: carefully — each one counts, and include: chains within can cascade.
• Prefer DKIM for SaaS senders. DKIM survives forwarding and doesn't count against the SPF lookup budget.
• Use ~all during rollouts, -all after stabilization. Hard fail is the strongest signal but punishes legitimate senders you missed.
• Re-audit when adding senders. A new marketing tool is a potential SPF break.

Recommended next step

Check your current SPF: dig +short TXT yourdomain.com | grep spf. Count the includes. If you're near 10 DNS lookups, flatten or restructure before you exceed the limit. If you don't have SPF, publish it before configuring DMARC.

FAQ

Can a domain have multiple SPF records?

No. Multiple v=spf1 records cause all of them to be ignored. Merge into a single record.

What's the difference between ~all and -all?

~all is soft fail (mark suspicious); -all is hard fail (reject). DMARC doesn't depend on the strictness — it uses SPF pass/fail at the alignment-check stage either way.

Does SPF apply to my visible From address?

No, it applies to the envelope-from (SMTP MAIL FROM). That's why alignment matters — DMARC checks that the envelope-from domain matches the visible From for SPF to count as DMARC-aligned.

Why does SPF fail on forwarded mail?

The forwarding server's IP isn't in your SPF, so the receiver sees a non-listed IP. DKIM is preferred for senders whose mail gets forwarded.

How often should I update SPF?

When you add or remove senders. SPF is otherwise stable.

Final thoughts

SPF is necessary, sufficient for nothing, and structurally limited. It's the IP-allowlist layer of email authentication — useful, fast to publish, and unable to carry the full security load. Modern domains pair SPF with DKIM (and tie them together with DMARC) precisely because each compensates for the other's weaknesses.

Get SPF right, then move on to DKIM and DMARC. The stack is what produces actual protection; SPF alone is just inventory.