SPF — Sender Policy Framework

Internet Standard Email Authentication Obsoletes RFC 4408 Authentication

ELI5: Imagine your company has official letterhead. SPF is like publishing a list of printers that are allowed to print on your letterhead. When someone receives a letter claiming to be from you, they can check whether it came from one of your approved printers. If it didn’t, they know it’s probably a forgery.

Why This RFC Exists

SMTP was designed in the early 1980s with no built-in sender verification. Any server can claim to send mail from any domain — there is nothing in the base protocol to prevent it. This made email spoofing trivial: spammers and phishers could forge the envelope sender address to impersonate banks, colleagues, or any trusted brand.

SPF (Sender Policy Framework), standardized in RFC 7208, solves this by letting domain owners publish a DNS TXT record that explicitly lists which IP addresses and servers are authorized to send email for their domain. Receiving mail servers query this record during the SMTP transaction and can reject or flag messages from unauthorized sources.

RFC 7208 obsoleted the earlier experimental RFC 4408, promoting SPF to a full Internet Standard with clarified processing rules and stricter requirements for DNS lookup limits.

How It Works

SPF operates at the envelope level, not the message header level. The domain checked is the one in the MAIL FROM command (also called the Return-Path or envelope sender), not the From: header that users see.

The SPF Check Flow

A sending server connects to the receiver and issues MAIL FROM:<user@example.com>.
The receiver extracts the domain example.com from the envelope sender.
The receiver queries DNS for a TXT record at example.com starting with v=spf1.
The receiver evaluates the SPF record's mechanisms against the connecting IP address.
The result is one of: pass, fail, softfail, neutral, none, temperror, or permerror.

SMTP Transaction Example

# Sending server 198.51.100.25 connects
S: 220 mx.receiver.com ESMTP ready
C: EHLO mail.example.com
S: 250-mx.receiver.com Hello
S: 250 OK
C: MAIL FROM:<alice@example.com>
# Receiver now checks: does example.com's SPF record authorize 198.51.100.25?
# DNS lookup: example.com TXT "v=spf1 ip4:198.51.100.0/24 -all"
# 198.51.100.25 matches ip4:198.51.100.0/24 => result: pass
S: 250 OK
C: RCPT TO:<bob@receiver.com>
S: 250 OK

Key Technical Details

SPF Record Syntax

An SPF record is a DNS TXT record that begins with the version tag v=spf1 followed by a series of mechanisms and an optional qualifier for each. The record is evaluated left to right; the first mechanism that matches determines the result.

example.com. IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/32 include:_spf.mailertogo.com include:_spf.google.com -all"

Mechanisms

Mechanism	Description
`ip4:<range>`	Matches if the sender's IP is within the given IPv4 CIDR range.
`ip6:<range>`	Matches if the sender's IP is within the given IPv6 CIDR range.
`a`	Matches if the sender's IP equals an A/AAAA record of the domain.
`mx`	Matches if the sender's IP equals an A/AAAA record of one of the domain's MX hosts.
`include:<domain>`	Recursively evaluates the SPF record of another domain. A `pass` from the included domain counts as a match.
`exists:<domain>`	Matches if a DNS A record exists for the given domain (used for advanced macros).
`redirect=<domain>`	Modifier: replaces the current SPF check entirely with another domain's record.
`all`	Matches everything. Typically used at the end of the record as `-all` or `~all`.

Qualifiers

Qualifier	Result	Meaning
`+` (default)	pass	Authorized sender
`-`	fail	Unauthorized — reject the message
`~`	softfail	Probably unauthorized — accept but mark
`?`	neutral	No assertion made

The 10-Lookup Limit

To prevent DNS abuse, RFC 7208 mandates that SPF evaluation must not require more than 10 DNS lookups that result in mechanism resolution. The mechanisms that trigger lookups are: include, a, mx, exists, redirect, and ptr (deprecated). Raw ip4 and ip6 mechanisms do not count. Exceeding 10 lookups produces a permerror result, which typically means no SPF protection at all.

The MX Lookup Limit

Additionally, the mx mechanism must not result in more than 10 MX names to query, and each of those must not resolve to more than 10 A/AAAA addresses. The ptr mechanism is explicitly discouraged.

Macro Expansion

SPF supports macros that expand to context-specific values during evaluation. Common macros include %{s} (sender), %{l} (local-part), %{d} (domain), and %{i} (IP address). These are used primarily in exists: mechanisms for complex per-user or per-IP policies.

DNS Record Examples

Basic: Single IP Range

example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

Typical: Third-Party ESP + Google Workspace

example.com. IN TXT "v=spf1 include:_spf.mailertogo.com include:_spf.google.com -all"

Domain That Sends No Email

parked-domain.com. IN TXT "v=spf1 -all"

Using redirect

subdomain.example.com. IN TXT "v=spf1 redirect=example.com"

Common Mistakes

Multiple SPF records: A domain must have exactly one SPF TXT record. Publishing two causes a permerror. If you need to combine sources, merge them into a single record.
Exceeding the 10-lookup limit: Each include: counts as one lookup, and the included record's own mechanisms count toward the total. Chains of includes from multiple ESPs quickly exhaust the limit. Flatten your record or use subdomains.
Using ~all instead of -all: Softfail (~all) tells receivers the message is suspicious but not to reject it. For strong protection (and to enable DMARC enforcement), use -all.
Forgetting the Return-Path domain: SPF checks the envelope sender, not the From: header. If your ESP uses its own Return-Path domain, your domain's SPF record is irrelevant to SPF checks. You need either custom Return-Path alignment or DKIM + DMARC.
Using the deprecated ptr mechanism: RFC 7208 explicitly discourages ptr because it is slow, unreliable, and places load on reverse DNS infrastructure.
Using type SPF (99) records: The dedicated SPF DNS record type was defined in RFC 4408 but deprecated in RFC 7208. Always use TXT records.

Deliverability Impact

SPF is one of the three pillars of email authentication (alongside DKIM and DMARC). Its impact on deliverability is significant:

Required by major providers: Gmail, Yahoo, Microsoft, and Apple all evaluate SPF. Since February 2024, Gmail and Yahoo require SPF or DKIM to pass for all senders, and both to pass for bulk senders.
DMARC alignment: SPF becomes much more powerful when combined with DMARC, which checks that the SPF-authenticated domain aligns with the From: header domain. Without DMARC, SPF alone cannot prevent header-from spoofing.
Forwarding breaks SPF: When a message is forwarded through a mailing list or .forward rule, the sending IP changes but the envelope sender often stays the same. This causes SPF to fail for legitimate mail. This is one reason DKIM and ARC exist.
Reputation signal: A properly configured SPF record (with -all) signals to receivers that you take email security seriously and makes it harder for bad actors to abuse your domain.