SPF record: the complete reference guide

The syntax of an SPF record

An SPF record is a sequence of mechanisms, each optionally preceded by a qualifier, possibly completed by modifiers. A representative example for a company sending through an office suite and its own application server:

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

The mechanisms

Mechanism	Role	DNS lookup cost
ip4:	Authorizes an IPv4 address or CIDR block (ip4:203.0.113.0/24)	0
ip6:	Authorizes an IPv6 address or CIDR block	0
a	Authorizes the IPs in the domain's A/AAAA records (or another domain's: a:mail.example.com)	1
mx	Authorizes the IPs of the domain's inbound mail servers (MX records)	1 (+ resolving each MX name)
include:	Imports another domain's SPF policy — the delegation mechanism for providers	1 + the lookups of the included domain
exists:	Matches if the constructed name (usually built with macros) resolves to an A record — advanced usage	1
all	Always matches; placed last, it decides the fate of everything not listed above	0

An eighth mechanism, ptr, exists in the standard but is explicitly discouraged there: expensive and unreliable, it should no longer appear in any current record.

The qualifiers

Each mechanism can be prefixed with a qualifier that determines the result when it matches:

Qualifier	Result if the mechanism matches	Typical usage
+ (default)	pass	Implicit: writing include: is the same as +include:
-	fail	-all: any unlisted sender is rejected
~	softfail	~all: suspect, accepted but flagged
?	neutral	No opinion — rarely justified

In practice, the qualifier is almost only ever seen on all, where its choice commits the whole policy — we come back to it in the best practices.

The modifiers

Modifier	Role
redirect=	Replaces the evaluation entirely with that of the designated domain (counts as 1 lookup). Useful for centralizing the policy of several domains in one place.
exp=	Points to a TXT record whose text serves as an explanation message on failure. Few receivers actually display it.

redirect= differs from include: on an essential point: include: imports a policy in addition to the rest of the record, whereas redirect= replaces it entirely (it only applies when no mechanism has matched, and makes a local all pointless).

One last syntax detail that is often overlooked: a TXT string is limited to 255 characters. A longer record must be split into several strings within the same TXT record — receivers concatenate them. What is forbidden is publishing two separate SPF records, as we will see.

The 10 DNS lookup limit and its workarounds

RFC 7208 imposes a strict bound: evaluating an SPF record must not trigger more than 10 DNS lookups. The mechanisms include:, a, mx, ptr and exists: count against this budget, as does the redirect= modifier — and the count is recursive: an include: containing three others consumes four lookups on its own. The ip4:, ip6: and all mechanisms cost nothing. The standard additionally caps void lookups (queries that return no result) at 2, a lesser-known second ceiling that produces the same symptoms.

Beyond the limit, the receiver returns a permerror: the record is considered invalid and SPF fails entirely, as if it did not exist. The danger is that the failure is silent and deferred: the record works for months under the bar, then adding one more provider crosses it, and legitimate mail starts failing without any error message reaching anyone. Our guide to the SPF lookup limit details the exact counting rules and the diagnosis step by step.

The workarounds, in order of preference:

1. Take inventory and prune. Most bloated records contain include: entries for providers abandoned years ago. Every mechanism should correspond to a real, current sender.
2. Prefer ip4:/ip6: for servers with stable IPs. An in-house application server does not need an include:: its address block, published directly, costs zero lookups.
3. Segment by subdomain. Sending marketing email from news.example.com and invoices from billing.example.com gives each subdomain its own record — hence its own budget of 10 lookups — while isolating reputations.
4. Flatten as a last resort. Flattening replaces include: entries with the IP blocks they resolve to. The gain is immediate, but the risk is real: providers change their IP ranges without notice, and an unmaintained flattened record eventually rejects legitimate mail. The technique, its automated variants and its pitfalls are covered in our guide to SPF flattening.

An even more advanced path — the exists: mechanism combined with macros — validates an IP in a single lookup; it is powerful but complex and mostly justified in very large-scale sending infrastructures.

SPF results: pass, fail, softfail and the others

SPF evaluation produces one of the following results, which the receiver records in the message's Received-SPF (or Authentication-Results) header:

Result	Meaning	Usual handling
pass	The sending IP is authorized by the record	The message continues on its way; SPF is usable by DMARC
fail	The IP is not authorized and the policy is strict (-)	Rejection or heavy filtering penalty
softfail	The IP is not authorized, lenient policy (~)	Accepted but flagged; weighs on the spam score
neutral	The domain expresses no opinion (?)	Treated more or less like an absence of SPF
temperror	Transient DNS error (timeout, unreachable server)	Retried later, usually without consequence
permerror	Invalid record: syntax, duplicate, lookup overrun	SPF unusable — often worse than having none

A seventh case, none, simply means no SPF record was found for the domain.

Two of these results deserve particular vigilance. softfail is often left in place indefinitely even though it was only meant as a transition stage — it weakens the posture with nothing to justify it. And permerror is the most insidious: it never comes from an attacker but always from a configuration error on the domain side — duplicate record, syntax mistake, lookup overrun. Our dedicated article on SPF permerror catalogs the real-world causes and their fixes, case by case.

SPF alone is not enough: DMARC alignment

Back to the distinction laid out at the beginning: SPF validates the envelope domain, never the visible From:. An attacker can therefore publish a flawless SPF record for their own domain, send from their duly authorized servers — SPF shows pass — and put your domain in the From: their victim will read. SPF sees nothing wrong: it never looked at that address.

It is DMARC that closes this gap by requiring alignment: for SPF to count in DMARC's eyes, the validated envelope domain must match the domain of the visible From:. In relaxed mode (the default), a match at the organizational domain level is enough — bounces.example.com aligns with example.com; in strict mode (aspf=s), the match must be exact. The full workings of policies and reporting are covered in our DMARC reference page.

This dependency exposes SPF's Achilles heel: forwarding. When an intermediate server forwards a message — mailbox forwarding, aliases, mailing lists — it re-emits it from its own IP, which obviously does not appear in the original domain's SPF record: SPF fails. Rewriting schemes like SRS (Sender Rewriting Scheme) "repair" SPF by substituting the forwarder's domain into the envelope — but that domain no longer aligns with the original From:, and the failure merely changes its nature.

The conclusion draws itself: SPF should never carry authentication alone. DKIM, whose cryptographic signature travels inside the message and survives most forwarding, takes over precisely where SPF breaks — our DKIM reference page details how it works. A properly protected domain combines both, and lets DMARC require that at least one of the two passes aligned.

SPF recipes: Microsoft 365 and Google Workspace

The two major sending suites cover the vast majority of business email; here are their canonical records.

Microsoft 365 publishes all of its sending IPs behind a single include:

v=spf1 include:spf.protection.outlook.com -all

Google Workspace does the same:

v=spf1 include:_spf.google.com -all

In both cases, the provider's include consumes several lookups on its own (it breaks down into sub-includes): the budget of 10 is not half spent, but it is no longer intact. A company in coexistence — an ongoing migration, separate entities — combines the two in a single record:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

This is legitimate and common, but the remaining lookup budget shrinks accordingly: every additional provider (marketing, invoicing, CRM, support) will have to find its place in it. The special cases — dedicated subdomains, connectors, hybrid routing, the precise lookup count of each suite — are covered in our guide to SPF for Microsoft 365 and Google Workspace.

Two rules that apply across all providers: add only the include officially documented by the provider (variants gleaned from forums are the leading source of duplicates and dead mechanisms), and add it inside the existing record — never as a second record.

Best practices for a durable SPF

One SPF record per domain, and only one. The rule is absolute: if two TXT records starting with v=spf1 exist, receivers return permerror and both are ignored. This duplicate almost always stems from a provider being added in a hurry: someone creates a new line instead of extending the existing one. Every new mechanism gets merged into the single record.

Aim for -all, tolerate ~all in transition. The final qualifier is your policy statement: -all asserts that the list is exhaustive and everything else should be rejected; ~all says "probably illegitimate, but let it through flagged". Softfail is a construction-site state, useful while the sender inventory is being made reliable — not a destination. As for +all, it authorizes the entire planet to send for your domain and must be fixed the moment it is spotted. The nuances between these variants are dissected in SPF -all or ~all: what's the difference.

Cover the domains that send nothing, too. A parked domain is protected with the empty policy v=spf1 -all: no server is authorized, and spoofing becomes immediately detectable.

Monitor, don't assume. An SPF record lives: providers change, teams add new ones, IPs move. DMARC aggregate reports are the only way to see who actually sends on the domain's behalf and where SPF fails; a periodic review of the record in their light prevents silent erosion. For an immediate doubt, checking your SPF record takes only a few minutes, and our free SPF checker counts the lookups, detects duplicates and grades the domain's full posture in seconds.

Think deliverability, not just security. The major mailbox providers now require proper authentication to accept mail at volume, and a shaky SPF weighs directly on inbox placement. If your legitimate messages land in spam despite a valid SPF, the causes are often elsewhere — reputation, volume, engagement — as explained in our diagnosis emails going to spam despite SPF and DKIM and our Gmail deliverability guide.

FAQ

How long does an SPF change take to apply?

The delay is that of DNS propagation: the TTL value of the TXT record, often between 5 minutes and 24 hours. Servers that have the old version cached keep using it until it expires. Before a sensitive change (moving to -all, removing an include), temporarily lower the TTL so you can roll back quickly.

Does SPF automatically apply to subdomains?

No. Unlike DMARC, SPF is not inherited: every subdomain that sends mail — or appears in a HELO identity — needs its own record. A subdomain without SPF returns none, which leaves the field open to spoofing. Hence the value of publishing v=spf1 -all on subdomains that never send anything.

What happens if my domain has no SPF record at all?

The result is none: the receiver has nothing to judge by, and most major mailbox providers now penalize or refuse unauthenticated bulk mail. Above all, without SPF or DKIM, DMARC has nothing to validate: the domain's protection is nonexistent. Publishing an SPF record is the first step, never the last.

Can I have two SPF records on the same domain?

No — that is the classic mistake. Two TXT records starting with v=spf1 produce a permerror and invalidate both. If a provider asks you to "add their SPF", their mechanism must be merged into the existing record, on one and the same logical line.

Does SPF encrypt or sign my emails?

No again. SPF is purely an IP address authorization list: it encrypts nothing, signs nothing and does not guarantee the integrity of the content. The cryptographic proof that a message has not been altered belongs to DKIM, and consistency with the visible address belongs to DMARC — the three are complementary, not interchangeable.

-all or ~all: which one in practice?

~all during the inventory phase, -all in steady state. If your record has been complete and verified through several weeks of DMARC reports without a false negative, nothing justifies staying on softfail: -all makes your policy enforceable and denies spoofers the gray zone.