SPF (Sender Policy Framework) answers one specific question: is this server actually allowed to send mail as this domain? It's published as a single TXT record at the domain's apex, listing every mail server authorized to send on its behalf.
How a Receiving Server Uses It
When mail arrives claiming to be from a domain, the receiving server looks up that domain's SPF record and checks whether the connecting server's IP address appears in it. An IP that isn't listed is unauthorized — what happens next depends on the record's final mechanism, not on SPF itself, which only performs the check.
Reading the Mechanisms
An SPF record is a space-separated list of mechanisms, most commonly:
ip4/ip6— a specific authorized IP address or range.include— delegates to another domain's SPF record, the mechanism most third-party email services (Google Workspace, Mailgun, SendGrid, and similar) require a customer to add.a/mx— authorizes the domain's own A record or MX hosts directly.
The Qualifier at the End Is What Actually Matters
The final mechanism in the record sets what happens to a server not on the list:
-all— hard fail. Unauthorized senders should be rejected outright. The setting a domain wants once its SPF record is confirmed complete.~all— soft fail. Unauthorized senders are flagged as suspicious (often routed to spam) but not rejected outright — common during initial rollout, before a domain owner is fully confident every legitimate source is listed.+all— passes everyone, authorized or not. This effectively disables SPF's protection and is almost never intended deliberately.
Why Two SPF Records Breaks Everything
A domain may publish exactly one SPF record. Publishing a second is an explicit error under RFC 7208 — not a case where the two get merged or the first one wins, but a PermError that can cause receiving servers to reject the mail specifically because of the duplication, independent of whether either record individually would have passed. This usually happens by accident: two teams or two email services each add their own record without checking whether one already exists.
What SPF Doesn't Cover
SPF verifies only the sending server's IP address — nothing about the message content, and nothing that survives a forward (a forwarded message arrives from the forwarding server's IP, not the original sender's, which SPF alone can't account for). Message-level integrity is DKIM's job, and what a receiving server actually does when either check fails is DMARC's — the three are typically deployed together for exactly this reason.
Frequently Asked Questions
Should I use -all or ~all?
-all once confident the record is complete — it's the setting that actually stops unauthorized senders. ~all is the safer starting point while still confirming every legitimate mail source is listed, since a soft fail doesn't reject mail outright if something was missed.
Why did adding a new email provider break SPF?
Most likely a second SPF record got created instead of adding the new provider's include mechanism to the existing one. Check for exactly one SPF TXT record on the domain — two is the single most common SPF misconfiguration.
Does SPF alone stop email spoofing?
Not by itself. SPF only checks the sending server's IP; a spoofed message forwarded through a legitimate but unrelated server can still pass SPF. DMARC, checking alignment across both SPF and DKIM, is what actually closes that gap.
Check any domain's SPF record with the SPF Checker.