SPF Explained — Stopping Email Spoofing by Sender IP

⏱ approx. 7 min views 30 likes 0 LOG_DATE:2026-06-10
TOC

SPF (Sender Policy Framework) lets a domain owner declare, in a DNS TXT record, which server IPs are allowed to send mail that claims to be from the domain, so the receiving server can compare the actual sending IP and detect spoofing. SMTP has no built-in way to verify that a sender is genuine — anyone can claim MAIL FROM: ceo@example.com. SPF plugs that hole with DNS and is the first, most basic layer of email authentication. It only becomes truly effective when combined with DKIM and DMARC.

01

The problem SPF solves — SMTP lets anyone spoof #

SMTP (RFC 5321) was designed in the 1980s on a trust-everyone basis and never verifies the address a sender claims. An attacker can send mail straight from their own server with the sender forged to look like a bank or a business partner. This is the foundation of phishing and BEC (business email compromise).

▸ Distinguish the two "From" addresses

Email has two From addresses. The Envelope From (MAIL FROM / Return-Path) is the "sender on the envelope" used for delivery control, and this is what SPF checks. The Header From (From:) is the "sender on the letter" shown to the recipient. The two can be made to differ, so SPF alone cannot fully stop display-name spoofing (DMARC ties them together — see §04).

  • What SPF protects — the legitimacy of the sending IP for the Envelope From domain
  • What SPF does not protect — tampering with the message body (→ DKIM), forging the Header From (→ DMARC)
02

SPF record syntax #

SPF has no dedicated record type; you publish exactly one TXT record at the domain apex. It starts with v=spf1, and the receiver evaluates the mechanisms left to right, adopting the result of the first one that matches.

Example TXT record for example.com
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"
MechanismMeaning
ip4:192.0.2.0/24Allow sending from this IPv4 range
ip6:2001:db8::/32Allow an IPv6 range
a / mxAllow the IPs of the domain's A / MX records
include:_spf.google.comPull in another domain's SPF (standard for SaaS)
all"Everything else." The final rule, always placed last

Each mechanism can take a qualifier (default is +) that decides what happens when it matches.

  • + Pass — the default
  • - Fail — -all means "reject any IP not on the list"
  • ~ SoftFail — ~all means "suspicious, but accept". Used during rollout
  • ? Neutral — no judgment
▸ The 10 DNS-lookup limit

The DNS queries triggered during SPF evaluation (include / a / mx and so on) must not exceed 10 in total, or you get a PermError and SPF stops working. Including many SaaS providers easily blows past this, so trimming unnecessary includes is the key operational task.

03

The evaluation flow — try it yourself #

The receiving server (1) looks up the SPF record for the Envelope From domain via DNS, (2) matches the connecting IP against the mechanisms left to right, and (3) takes the qualifier of the first match as the result. In the simulator below, set the SPF record and the sending IP freely and see how the result changes with the ip4 range, include, and -all / ~all.

For example, change ~all to -all and enter an out-of-range IP, and the result flips from SoftFail to Fail. include:_spf.example.net pulls in another record (v=spf1 ip4:198.51.100.0/24 -all), so 198.51.100.x also passes.

04

The limits of SPF, and DKIM / DMARC #

SPF alone leaves gaps. Forwarding changes the sending IP to the forwarder, which breaks SPF. And because SPF never looks at the Header From, it lets through a trick where the Envelope From is your legitimate domain while the Header From is forged.

SPF — authenticate the sending IP
"Is this IP authorized to send for the claimed domain?" Weak against forwarding.
DKIM — digitally sign the message
The sender signs headers/body with a private key; the receiver verifies with a public key in DNS. The signature survives forwarding and detects tampering.
DMARC — alignment + policy
Requires the SPF/DKIM result to align with the Header From, and lets the domain owner declare what to do on failure (none / quarantine / reject) and where to send reports.
▸ The three work as a set

Only once SPF + DKIM + DMARC are all configured, with DMARC raised to p=reject, do receivers actually reject mail that impersonates your domain. For a domain that sends no mail, Null MX + v=spf1 -all + p=reject completely removes the basis for spoofing.

05

Operational best practice #

  • Exactly one TXT per domain — publishing multiple SPF records causes PermError. Consolidate them
  • Start rollout with ~all — watch with SoftFail first, identify legitimate senders from DMARC reports, then move to -all
  • Keep includes minimal — drop includes for SaaS you no longer use so you stay under the 10-lookup limit
  • Always pair with DKIM and DMARC — SPF alone is weak to forwarding and Header From spoofing
  • dig TXT example.com shows the published record
𝕏 Post B! Hatena