SPF

From Learn, the They Sent It email marketing encyclopedia · First edition · Updated October 31, 2026

SPF (Sender Policy Framework) is an email authentication protocol. A domain owner publishes a TXT record in DNS listing the mail servers authorized to send email as that domain. When a message arrives, the receiving server checks the sending server's IP address against that list. If it is not on the list, the result depends on the qualifier on the all mechanism: Fail for -all, Softfail for ~all, or Neutral for ?all.^[1]

SPF is defined by RFC 7208, a Proposed Standard on the IETF Standards Track published in April 2014. The most important thing to understand about SPF is what it checks: the envelope sender (the technical address servers use for routing and bounce delivery), not the From address the reader sees. A message can pass SPF while showing any domain in From. DMARC closes that gap by requiring the SPF-verified domain to align with the From domain.^[4]

How SPF works

Email has two separate sender identities. The envelope sender (also called MAIL FROM or Return-Path) is exchanged between servers during the SMTP conversation and is where bounce messages go. The From header is what the reader sees. SPF checks the envelope sender (MAIL FROM); it also evaluates the HELO domain presented at the start of the SMTP session (see below).

The receiving server takes the domain from the envelope MAIL FROM address and looks up its TXT record. It then works through the record's mechanisms from left to right, comparing the connecting IP address to each one, until something matches or the record ends. The result is one of:

Pass - the IP matched an authorized mechanism.
Fail - the IP matched a -all (or similar) mechanism: not authorized.
Softfail - the IP matched a ~all: probably not authorized.
Neutral - the IP matched ?all or the record made no claim.
None - no SPF record exists for the domain.
Temperror / Permerror - a DNS problem or a malformed record. Permerror also fires when there are two SPF records on the same domain, or when the 10-lookup limit is exceeded.

SPF also checks the HELO domain, the domain the sending server announces at the start of the SMTP session. Most implementations check MAIL FROM first and use HELO as a fallback when MAIL FROM is empty (as it is for bounce messages).^[1]

In practice: for marketing email the envelope sender is almost always a domain controlled by the email platform, not your brand domain. Klaviyo, Mailchimp and HubSpot each use their own infrastructure for bounces. SPF passes for the platform's domain, but that domain is not yours, so SPF does not align for DMARC. Setting up a custom DKIM signing domain is the most reliable path for marketing mail to pass DMARC alignment, because SPF alignment requires the platform to use the brand's domain as the envelope sender. Either aligned SPF or aligned DKIM satisfies DMARC.

The SPF record

An SPF record is a TXT record published at the exact sending domain that appears in the MAIL FROM address. That domain can itself be a subdomain. It must start with v=spf1:

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

This record authorizes Google Workspace's sending servers, the servers listed in mail.example.com, and one direct IP address. Any other server gets a Fail.

Two absolute rules from RFC 7208:^[1]

One record per domain. Publishing two TXT records that both start with v=spf1 at the same name causes a Permerror, and receivers discard both. We see this on 2.8% of brands.
The record is a single string. Some DNS editors split it into multiple quoted strings; that is allowed by DNS but must be joined by the SPF evaluator into one. If your editor needs multiple strings, keep them within one TXT record.

Mechanisms and qualifiers

SPF records consist of mechanisms and modifiers. Each mechanism tests a condition; the first match determines the result. The qualifier prepended to a mechanism sets what happens on a match:

SPF qualifiers
Qualifier	Name	Meaning
`+`	Pass	The IP is authorized. The default; writing +all is identical to all.
`-`	Fail	The IP is not authorized (hard fail). Receivers may reject the message.
`~`	Softfail	The IP is probably not authorized. Receivers should not reject the message solely on this result but may accept and mark it as suspicious.
`?`	Neutral	No assertion about authorization. Treated like a missing SPF record.

The qualifier + is the default and is usually omitted. Writing a is the same as writing +a.

SPF mechanisms
Mechanism	DNS lookup?	What it does
`all`	No	Matches every IP. Used at the end with a qualifier to set the default for mail not matched by anything above it.
`a`	Yes	Matches if the connecting IP is an A or AAAA record of the given domain (or the envelope domain if none given).
`mx`	Yes	Matches if the connecting IP is an MX host of the domain. Counts as one term toward the 10-lookup limit; the address lookups for MX hosts have their own per-mechanism cap and do not each consume a separate term.
`ip4`	No	Matches a specific IPv4 address or CIDR range, e.g. ip4:203.0.113.0/24.
`ip6`	No	Matches a specific IPv6 address or CIDR range.
`include`	Yes	Includes another domain's SPF policy. Every mechanism in the included record that causes a lookup counts toward the limit.
`exists`	Yes	Matches if the given domain has at least one A record. Rare in practice; used for IP-in-domain macro policies.
`ptr`	Yes	Matches if the PTR lookup for the connecting IP returns a hostname that resolves forward to the connecting IP and matches the given domain or a subdomain. RFC 7208 says do not use this mechanism. It is slow, unreliable and still costs a lookup.
`redirect`	Yes	Modifier (not a mechanism): evaluated after all mechanisms in the current record fail to match; continues the check using the named domain's SPF policy instead. Counts as one lookup. Ignored when all is present in the same record.

The 10-lookup limit

RFC 7208 allows at most 10 DNS-querying terms per check, counted across every include. This is usually called the 10-lookup limit.^[1] This includes every a, mx, include, exists, ptr and redirect in the record and in every record those include. ip4, ip6 and all do not cause lookups.

The mx mechanism counts as one term toward the 10-lookup budget, regardless of how many MX hosts a domain has. Each mx evaluation may look up up to 10 A or AAAA records for those hosts, but those address lookups have their own per-mechanism cap and do not each consume an additional term. The include mechanism adds 1 for the include itself, then the mechanisms inside the included record count too. A chain of three nested includes can use most of the budget before it reaches the sending IP.

When the limit is exceeded, the result is a Permerror, which most receivers treat as a failure. RFC 7208 also recommends limiting void lookups (lookups that return NXDOMAIN or an empty response) to 2.^[1]

SPF flattening is the practice of resolving all include chains to direct IP ranges and rewriting the record with ip4 and ip6 entries. It eliminates lookup-limit failures but creates a maintenance problem: when the ESP adds or changes servers, the flattened record is wrong until someone updates it manually. An automated flattening service updates the record each time the ESP changes. Whether to flatten depends on how often the record approaches the limit.

In practice: the fastest way to count your lookups is to use a public SPF validator (many are free). Add up every mechanism that causes a lookup, including inside each include chain. If you are near 10, check whether mx is worth replacing with direct ip4 entries and whether any old platforms can be removed.

~all vs -all

The final mechanism in most SPF records is all, which matches any IP not caught above. The qualifier on all sets the policy for unauthorized senders:

-all (Fail) declares unlisted hosts not authorized. Receivers decide what to do with failing mail under their own policy.
~all (Softfail) tells receivers the domain probably never sends from unlisted servers, but stops short of a firm statement. Receivers should not reject on this result alone.
?all (Neutral) makes no claim at all, treating unlisted servers the same as if there were no SPF record.
+all (Pass) is a signal the record is broken: it authorizes every server on the internet.

For a domain with a well-maintained SPF record and DMARC at p=reject or p=quarantine, the difference between -all and ~all is smaller: DMARC's policy is what controls enforcement. However, some receivers act on an SPF Fail result (-all) before DMARC is evaluated, so -all carries more weight in the absence of DMARC. For a domain without DMARC, -all gives receivers a signal to reject unauthenticated mail and ~all does not.

Among the brands we follow, softfail (~all) is the dominant choice even for brands at DMARC enforcement. HubSpot customers are more likely to use -all (42.9% of HubSpot brands with an SPF record, against 30.6% across all platforms), consistent with HubSpot's higher DMARC enforcement rate in the same scan.

Forwarding

SPF usually fails on forwarding. When a message is forwarded, the forwarding server becomes the new sender. That server's IP is almost certainly not in the original domain's SPF record. When the forwarder uses Sender Rewriting Scheme (SRS), it rewrites the MAIL FROM to its own domain, so SPF passes for the rewriting domain - but DMARC alignment for the original From domain is not preserved. Most forwarders do not use SRS. Without SRS, the connecting IP no longer matches the SPF record for the original sending domain, and SPF fails.

This is a fundamental limitation of SPF: it checks a property of the server, not the message, and servers change during forwarding. DKIM survives plain forwarding because it is a signature on the message itself. For a message to reach its final destination through a forwarder, a valid DKIM signature whose d= aligns with the From domain is what keeps DMARC passing.^[5]

DMARC alignment

For DMARC alignment via SPF, the domain verified by SPF must align with the domain in the From header; DMARC also passes when DKIM alignment succeeds instead. Alignment can be relaxed (the default) or strict:^[4]

Relaxed alignment: the SPF-verified domain and the From domain must share the same organizational domain. bounce.brand.com aligns with brand.com.
Strict alignment: the SPF-verified domain and the From domain must be identical. bounce.brand.com does not align with brand.com.

For most brands using an email platform, the envelope sender (MAIL FROM) is a platform-owned domain such as bounce.klaviyomail.com, not their brand domain. SPF passes for that domain but does not align with the brand's From domain under either mode. A custom sending subdomain (e.g. mail.brand.com configured in the platform) can make SPF align under relaxed mode, but DKIM alignment is the more reliable path: it requires setting up a custom DKIM signing domain with the platform, which most platforms support.

Gmail, Yahoo and Microsoft requirements

Gmail, from February 1, 2024: senders approaching 5,000 messages per day to personal Gmail accounts must set up SPF and DKIM, publish DMARC (p=none is enough), and align the From domain with SPF or DKIM. All senders must have either SPF or DKIM and keep the spam rate below 0.3%.^[6]
Yahoo introduced the same requirements for bulk senders at the same time. Yahoo publishes no volume threshold.^[7]
Outlook.com (Hotmail, Live): from May 5, 2025, domains sending more than 5,000 emails a day must have SPF and DKIM passing and publish DMARC at p=none or above, aligned. Failing mail is rejected with error 550 5.7.515.^[8]

None of the three specifies a minimum SPF record structure beyond "a valid SPF record." For non-bulk senders, either SPF or DKIM passing is sufficient. Gmail and Yahoo require bulk senders to have both SPF and DKIM passing, with at least one aligning with the From domain under DMARC.

What brands publish

We looked up the SPF record of every brand with a page on They Sent It on October 29, 2026: 41,210 domains, almost all online shops that send marketing email.^[9]

SPF record published, 41,210 brand domains, October 29, 2026
Has an SPF record	83.5%
No SPF record	16.5%
More than one record (invalid, Permerror)	2.8%

Among brands that publish a record, the distribution of the all mechanism qualifier:

all qualifier among brands with SPF, October 29, 2026
~all (Softfail)	66.2%
-all (Fail)	30.6%
?all (Neutral)	2.2%
No all mechanism	0.8%
+all (lets any sender pass)	0.2%

By the brand's email platform
Platform	Brands	Has SPF	-all	~all
Klaviyo	33,720	83.5%	29.3%	67.7%
Mailchimp	4,205	82.5%	34.0%	61.3%
HubSpot	2,460	84.6%	42.9%	53.7%
ActiveCampaign	388	84.0%	32.2%	64.7%

2.8% of brands publish more than one SPF record on the same domain. RFC 7208 treats that as a permanent error, so SPF cannot pass for those domains.
Softfail (66.2%) dominates across all platforms. HubSpot customers are the most likely to use -all, consistent with HubSpot's higher DMARC enforcement rate in the same scan.
SPF adoption is high but does not guarantee alignment. A passing SPF record on an ESP's own domain does not satisfy DMARC alignment for the brand's From domain.

Method: one DNS TXT lookup per domain through public resolvers; 16 of 41,226 lookups failed and are left out. Percentages in the platform table are of all brands on that platform, not only those with SPF. These are the records brands publish; SPF alignment under DMARC depends on the envelope sender the platform uses.

Common mistakes

Two records on the same domain. The second record is usually from an old provider or from the DNS host adding its own SPF entry. The result is Permerror at most receivers.
Exceeding the 10-lookup limit. Each new tool added to the stack is an include; eventually the count tips over 10. Only terms that are evaluated count toward the limit - a server matched by an earlier ip4 or ip6 entry never triggers the remaining includes - but any check that requires more than 10 lookups to reach a result returns Permerror.
Thinking SPF alignment replaces DKIM. If the platform uses its own bounce domain, SPF aligns for the platform's domain, not yours. DKIM on your domain is what you need.
Publishing +all. This authorizes every server on the internet to send as your domain and defeats the purpose of SPF entirely.
Treating Softfail as enforcement. ~all asks receivers to accept but mark suspicious; it does not block or reject. At DMARC p=none, unlisted senders are not rejected by DMARC policy, but independent spam filtering still applies.
Publishing only SPF with no DMARC. Passing SPF does not protect the From address. Without DMARC, a spammer can pass SPF for their own domain while showing yours in From.

History

2003: Meng Weng Wong publishes an early version of the Sender Permitted From specification. Paul Vixie and others contribute to the design.
2006: RFC 4408 publishes SPF as an Experimental RFC.
2014: RFC 7208 replaces RFC 4408, promoting SPF to Proposed Standard on the IETF Standards Track.^[1]
2024: Gmail and Yahoo require SPF from bulk senders.^[6]
2025: Outlook.com does the same for senders over 5,000 a day.^[8]

References

First edition, October 31, 2026, by Conner Baker. Corrections are made in place and noted here. October 31, 2026, after an independent review: corrected the share of brands with multiple SPF records from 3.1% to 2.8%, and the HubSpot comparison, which had printed the wrong figures. Found an error? Tell us.

SPF