What Is an SPF Record and How to Set It Up Correctly

SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorized to send email for your domain. Without SPF, any mail server in the world can claim to be sending email from your domain — and many receiving servers will accept it.

SPF is the foundation of email authentication, but it's only effective when correctly configured and combined with DKIM and DMARC.

How SPF Works

1. Your domain publishes a TXT record at yourdomain.com (not _spf.yourdomain.com)
2. When a mail server receives an email claiming to be from you@yourdomain.com, it checks the sending IP against your SPF record
3. If the sending IP is listed: SPF passes
4. If it's not listed: SPF fails (or softfails, depending on your all qualifier)

SPF checks the Return-Path (envelope MAIL FROM), not the From: header users see. DMARC alignment bridges this gap.

SPF Record Syntax

A basic SPF record:

v=spf1 include:_spf.google.com ip4:203.0.113.1 ~all

Part	Meaning
v=spf1	SPF version (always this)
include:_spf.google.com	Include Google's list of sending IPs
ip4:203.0.113.1	Authorize a specific IPv4 address
~all	Anything not listed: softfail

SPF Mechanisms

ip4 and ip6 — Specific IP addresses

ip4:203.0.113.1          # Single IPv4 address
ip4:203.0.113.0/24       # IPv4 CIDR range
ip6:2001:db8::1          # IPv6 address
ip6:2001:db8::/32        # IPv6 CIDR range

Use this for your own mail servers with static IPs.

include — Include another domain's SPF record

include:_spf.google.com     # Google Workspace
include:sendgrid.net        # SendGrid
include:amazonses.com       # Amazon SES
include:servers.mcsv.net    # Mailchimp

This fetches the referenced domain's SPF record and merges it. Each include counts as one DNS lookup.

a — The domain's A record

a            # The A record of the domain in the From: address
a:mail.yourdomain.com   # Specific hostname's A record

Authorizes the IP address of a hostname.

mx — The domain's MX records

mx           # IPs of the domain's MX records
mx:yourdomain.com

Authorizes your domain's mail exchange servers to send as well as receive.

ptr — Reverse DNS (deprecated)

Do not use. ptr is deprecated due to performance impact on receiving servers.

exists — Dynamic SPF

exists:%{i}.spf.yourdomain.com

Advanced: checks whether a synthesized domain name has an A record. Used for dynamic SPF records.

SPF Qualifiers

The qualifier before each mechanism controls what happens on a match:

Qualifier	Result	Example
+ (default)	Pass	+ip4:1.2.3.4 (same as ip4:1.2.3.4)
-	Fail (hard)	-all
~	Softfail	~all
?	Neutral	?all

The all mechanism

all matches everything not matched by earlier mechanisms. Always at the end of the record.

• -all (hardfail): Unauthorized mail explicitly fails. Use with DMARC p=reject.
• ~all (softfail): Unauthorized mail fails but isn't necessarily rejected. Traditional safe default.
• ?all (neutral): No policy on unauthorized mail. Provides almost no protection.
• +all: Never use this. It authorizes all senders.

Complete SPF Examples

Google Workspace only

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

Google Workspace + SendGrid + a transactional server

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.100 -all

Domain that sends no email (lockdown)

v=spf1 -all

No sending sources authorized. All mail from this domain fails SPF. Use this for parked domains.

The 10 DNS Lookup Limit

This is the most common SPF misconfiguration. The SPF specification limits the total number of DNS lookups during evaluation to 10. Each include:, a, mx, ptr, and exists mechanism counts as one lookup (plus lookups inside included records recursively).

If your SPF record exceeds 10 lookups, receiving servers return permerror — meaning SPF permanently fails, and your legitimate mail may be rejected.

Check your lookup count:

dig TXT yourdomain.com +short | tr ' ' '\n' | grep "include\|a\|mx"
# Count includes, then recurse into each include's record

Or use a free SPF flattening tool that shows your current lookup count.

Fixing the 10-lookup limit:

Option 1: Remove services you no longer use.

Option 2: "Flatten" your SPF record by replacing include: entries with the actual IP addresses they resolve to. This requires updating when service providers change their IPs.

Option 3: Use SPF flattening tools (SpfWizard, Dmarcly) that maintain a flattened record for you.

SPF Alone Isn't Enough

SPF passes or fails based on the Return-Path domain, not the From: header. This means:

• A legitimate forwarded email (mailing list, email forwarder) changes the Return-Path, breaking SPF alignment
• An attacker can pass SPF for attacker.com while spoofing From: ceo@yourcompany.com

This is why you need DMARC. DMARC requires alignment between the SPF/DKIM authenticated domain and the visible From: domain, closing these gaps.

The complete email authentication chain:

SPF   → Authorizes sending servers
DKIM  → Authenticates the message content
DMARC → Enforces alignment and policy

All three are needed for full email security.