SPF (Sender Policy Framework)

In January 2024, a mid-size SaaS company noticed that 30% of their transactional emails — password resets, invoices, onboarding sequences — were landing in Gmail spam folders. Their deliverability had been fine for years. What changed? Google had begun enforcing its new bulk sender requirements, and the company’s SPF record was broken: too many include statements had pushed them past the 10-lookup limit. The SPF evaluation was returning permerror, and Gmail was treating every message as unauthenticated.

They fixed the record in an afternoon. Deliverability recovered within 48 hours. A single line of DNS had been silently undermining their entire email operation.

This is the world SPF operates in. It is a deceptively simple system — one DNS record — that underpins the authenticity of billions of emails every day.

The Problem: Anyone Can Claim to Be You

SMTP, the protocol that carries email across the internet, was designed in 1982. It has no built-in mechanism for verifying that the sender is who they claim to be. When a mail server connects to deliver a message, it announces a MAIL FROM address — and the receiving server has no reason to doubt it.

This means that anyone with a mail server can send an email that appears to come from ceo@yourcompany.com. There is nothing in the protocol itself to stop them. Before SPF existed, the only defenses were IP reputation lists and content-based spam filters — reactive measures that could never fully solve the impersonation problem.

Email spoofing is not a theoretical concern. Phishing attacks that start with a spoofed email account for 91% of cyberattacks, according to PhishMe. In 2024, the FBI’s IC3 received over 298,000 phishing complaints, representing 34% of all cybercrime reports. Business Email Compromise (BEC) attacks — many of which rely on domain spoofing — cost organizations roughly $2.8 billion in 2024 alone.

SPF was the first widely deployed countermeasure: a way for domain owners to declare, in DNS, exactly which servers are authorized to send mail on their behalf.

How SPF Works

The concept is straightforward. You publish a DNS TXT record for your domain that lists every IP address and server permitted to send email as you. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record against the IP address of the server that actually sent it.

The verification flow, step by step:

1. A sending MTA connects to the recipient’s mail server
2. The sender transmits the MAIL FROM (envelope sender) address — for example, bounces@yourcompany.com
3. The recipient’s server extracts the domain (yourcompany.com) from that address
4. The recipient’s server performs a DNS TXT lookup for yourcompany.com
5. It parses the SPF record and evaluates the sending server’s IP against the authorized list
6. The result is one of: pass, fail, softfail, neutral, none, temperror, or permerror

An important detail: SPF checks the envelope sender (MAIL FROM / Return-Path), not the From: header that the recipient sees in their email client. This distinction matters and is one of the reasons DMARC was later created — to tie SPF results back to the visible sender address through alignment.

Anatomy of an SPF Record

SPF records are published as DNS TXT records beginning with v=spf1. Here is a simple one:

example.com.  IN TXT  "v=spf1 mx -all"

This says: “Mail from example.com is authorized if it comes from any IP listed in our MX records. Reject everything else.”

Mechanisms

Mechanisms are the building blocks that define who is allowed to send. They are evaluated left to right, and the first match wins.

Mechanism	What It Does	Example
ip4:	Authorize a specific IPv4 address or CIDR range	ip4:192.168.1.0/24
ip6:	Authorize a specific IPv6 address or range	ip6:2001:db8::/32
a	Authorize the IPs in the domain’s own A record	a or a:mail.example.com
mx	Authorize the IPs of the domain’s MX servers	mx
include:	Incorporate another domain’s SPF record	include:_spf.google.com
redirect=	Redirect the entire SPF evaluation to another domain	redirect=_spf.example.com
exists:	Pass if a specified domain resolves to an A record	exists:%{i}.spf.example.com
all	Catch-all, always matches (used at the end with a qualifier)	-all

Qualifiers

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

Qualifier	Meaning	Result
+ (default)	Pass	Server is authorized
-	Hard fail	Server is not authorized; reject the message
~	Soft fail	Server is probably not authorized; accept but mark
?	Neutral	No assertion either way

If you write mx with no prefix, it implicitly means +mx (pass). The all mechanism at the end of a record is where the qualifier matters most: -all means “reject everything not explicitly listed,” while ~all means “soft-fail everything else” (which most receivers treat as a strong negative signal but not an outright rejection).

Real-World SPF Records

Here are the SPF records you will encounter most often in the wild:

Google Workspace:

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

Microsoft 365:

example.com.  IN TXT  "v=spf1 include:spf.protection.outlook.com -all"

Multiple services (Google Workspace + Mailchimp + SendGrid):

example.com.  IN TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all"

Enterprise with direct IP ranges and multiple providers:

bigcorp.com.  IN TXT  "v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com -all"

Notice the pattern: each third-party email service you use adds an include: directive. This is clean and readable, but it creates a real operational problem.

The 10-Lookup Limit

RFC 7208 (Section 4.6.4) imposes a hard constraint:

SPF implementations MUST limit the total number of mechanisms and modifiers that cause DNS lookups to at most 10 per SPF evaluation.

This is the single most common source of SPF failures in production.

Mechanisms that count toward the limit:

• include: — 1 lookup each, plus any nested lookups inside the included record
• a — 1 lookup
• mx — 1 lookup, plus up to 10 additional A/AAAA lookups per MX hostname
• exists: — 1 lookup
• redirect= — 1 lookup

Mechanisms that do NOT count:

• ip4: — no DNS query needed
• ip6: — no DNS query needed
• all — no DNS query needed

The trap is include nesting. Google’s _spf.google.com alone expands into 3-4 additional include statements, each of which counts. A record like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net include:spf.brevo.com include:amazonses.com include:_spf.salesforce.com ~all

…will almost certainly exceed 10 lookups once the nested includes are resolved. The result is a permerror, and many receiving servers treat that as an SPF failure.

Solutions to the lookup limit:

• SPF flattening: Resolve all include chains to their final IP addresses and list them directly with ip4: and ip6: mechanisms. This eliminates DNS lookups but requires regular updates as providers change their IP ranges.
• Subdomain delegation: Send marketing email from mail.example.com, transactional email from notify.example.com, and support email from help.example.com — each with its own SPF record and its own lookup budget.
• Reducing providers: Audit which services actually send email and remove stale include directives.

SPF Alignment

SPF on its own authenticates the envelope sender domain (the MAIL FROM address), but recipients see the header From address. These can be completely different. A phisher could set the envelope sender to a domain they control (passing SPF) while putting your domain in the visible From: header.

This is where alignment comes in. DMARC requires that the domain authenticated by SPF matches (aligns with) the domain in the From: header. Alignment can be relaxed (organizational domains match — bounces.example.com aligns with example.com) or strict (exact domain match required).

Without DMARC enforcing alignment, SPF alone cannot fully prevent spoofing of the visible sender address.

Common Mistakes

Mistake	Why It Happens	Impact
Using +all	Misunderstanding the syntax	Authorizes the entire internet to send as your domain — completely defeats SPF
Multiple SPF records	Adding a new TXT record instead of editing the existing one	SPF evaluation returns permerror; only one v=spf1 record is allowed per domain
Exceeding 10 lookups	Adding include: for every SaaS tool	Returns permerror, effectively disabling SPF
Forgetting to update after provider changes	Switching email providers without updating DNS	Legitimate mail fails SPF; old provider remains authorized
Using ptr mechanism	Legacy practice	Deprecated by RFC 7208 due to performance and reliability issues
Overly permissive ranges	ip4:0.0.0.0/0 or huge CIDR blocks	Authorizes far more IPs than intended

How to Test SPF with dig

You can inspect any domain’s SPF record from the command line:

dig +short TXT example.com

This returns all TXT records for the domain. Look for the one starting with v=spf1. To trace the include chain, follow each included domain:

dig +short TXT _spf.google.com

Which returns something like:

"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Follow each nested include to see the actual IP ranges:

dig +short TXT _netblocks.google.com

"v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

Count every include, a, mx, exists, and redirect across the entire chain. If the total exceeds 10, you have a problem.

Adoption

SPF is the most widely deployed email authentication mechanism, having been the first to be developed (Meng Weng Wong posted the original “Sender Permitted From” specification in June 2003). It was formalized as RFC 4408 in 2006 and updated to RFC 7208 in 2014.

Current adoption numbers paint a mixed picture:

Metric	Value	Source
Top 1,000 domains with valid SPF	~77%	dmarcchecker.app (2024)
Top 1 million domains with valid SPF	~61%	dmarcchecker.app (2024)
Top 1 million domains lacking SPF	~39%	dmarcchecker.app (2024)
Bulk sender SPF adoption	>85%	Mailgun (2024)
French .fr domains with SPF	67.3%	AFNIC (2025)

That roughly 39% of the top million domains still lack SPF — a free, decades-old DNS record — illustrates the persistent gap between what is technically simple and what is operationally deployed.

SPF is necessary but not sufficient. It does not protect message integrity (a message can be altered in transit and still pass SPF), and it does not cover the From: header that users actually see. For complete protection, SPF works alongside DKIM (which verifies message integrity) and DMARC (which ties everything together with a policy). Together, the three form the authentication foundation that Google, Yahoo, and now Microsoft require of all bulk senders.