SPF Records Explained: How to Set Up and Check SPF

Sender Policy Framework (SPF) is a single DNS TXT record that names the mail servers allowed to send email for your domain. Receiving servers read that list and check whether the server that delivered a message is on it. If you want the full picture of how this fits with DKIM and DMARC, start with Email authentication explained, then come back here for the SPF detail.

The problem SPF solves is forgery. Without it, anyone can stamp your domain into the envelope sender of an email, and the receiving server has no quick way to tell whether the claim is genuine. SPF gives that server an answer published in DNS. The mechanism is defined in RFC 7208, and because the policy lives in an ordinary TXT record, it relies on the DNS format set out in RFC 1035. For the rest of the authentication story, see Email authentication explained.

Reading the syntax

Every SPF record opens with the version tag v=spf1. After that comes a series of mechanisms, each of which can match the sending server, followed by a final catch-all. A typical record looks like this:

v=spf1 include:_spf.google.com ip4:198.51.100.10 mx -all

That record says: trust whatever Google's servers publish, trust the single IPv4 address, trust the hosts in your MX records, and reject everything else. The trailing qualifier is the most important character in the whole string, because it tells receivers what to do with mail that matched nothing.

Mechanisms and qualifiers

Each mechanism can carry a prefix qualifier. A bare mechanism defaults to + (pass).

Token	Type	Meaning	Example
v=spf1	version	Marks the record as SPF; required first	v=spf1
include	mechanism	Pulls in another domain's SPF policy	include:_spf.google.com
a	mechanism	Matches the domain's A/AAAA address	a
mx	mechanism	Matches the hosts in the MX records	mx
ip4	mechanism	Matches a literal IPv4 address or range	ip4:198.51.100.0/24
ip6	mechanism	Matches a literal IPv6 address or range	ip6:2001:db8::/32
+	qualifier	Pass (the default)	+mx
~all	qualifier	Softfail: accept but flag as suspicious	~all
-all	qualifier	Hardfail: reject unlisted senders	-all
?all	qualifier	Neutral: no assertion either way	?all

Most domains should aim for -all once they are confident every legitimate sender is covered. Start with ~all while you watch DMARC reports, then tighten to -all.

The one-record rule

A domain gets exactly one SPF TXT record. Publishing two is not additive; it is an error, and many receivers will treat the result as a permerror and stop evaluating. If you add a new sending service, you fold its include into the record you already have. So if marketing software needs adding alongside your mailbox provider, the answer is a single longer string, never a second record.

The 10-lookup limit

RFC 7208 caps the number of DNS-querying mechanisms at ten per evaluation. Every include, a, mx, and a few others count toward that ceiling, and nested includes count too. Cross it and receivers return a permerror, which can mean your mail stops authenticating without warning. Watch this carefully when you stack several third-party senders, since each one may quietly add two or three lookups of its own.

Why forwarding breaks SPF

SPF checks the server that connects to the receiver. When a message is forwarded, a new server now sits in front, and that server is almost never in your SPF record. The check fails through no fault of yours. This is the central reason SPF alone is not enough: a forwarded newsletter can look like a forgery. DKIM handles this case better because its signature rides along with the message, which is why the two are paired under DMARC. See DKIM explained for the other half.

How to check your record

You can query SPF from any terminal:

dig +short TXT example.com

Look for the line beginning with v=spf1. Confirm there is only one, count the lookup-triggering mechanisms, and check the final qualifier. A record ending in ?all is doing almost nothing useful. One ending in -all with complete coverage is doing its job.

A few quick checks worth running before you trust a record:

• Exactly one v=spf1 TXT entry, not two.
• Ten or fewer DNS lookups across all nested includes.
• A definite ending: ~all while testing, -all in production.
• Every real sender (mailbox host, marketing tool, ticketing system) covered.

Want to see what a domain is publishing right now? Check any domain's SPF, DKIM, and DMARC records free at domainintel.app, or read how to check SPF, DKIM, and DMARC for a step-by-step walkthrough.