What is an SPF Record? Syntax, Mechanisms, and Real Examples

An SPF record is a DNS TXT entry that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets mail claiming to be from you, it checks your SPF record to verify the sender's IP address is on the list. If the IP matches, the mail passes SPF authentication. If it does not, the receiving server can reject it, quarantine it, or let it through with a warning flag.

The Anatomy of an SPF Record

Every SPF record is a DNS TXT record at your root domain or subdomain. It starts with v=spf1 to declare the version, followed by one or more mechanisms that specify authorized senders, and ends with an all directive that tells the receiver what to do with mail from unlisted sources.

A minimal example:

v=spf1 ip4:203.0.113.5 -all

This says: version 1, allow mail from the single IPv4 address 203.0.113.5, and reject (-all) everything else.

A more typical record for a business using Google Workspace and a transactional email service:

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

The include: mechanism delegates part of the authorization to another domain's SPF record. When a receiver processes include:_spf.google.com, it performs a DNS lookup on that domain's SPF record and evaluates its rules. Each include: counts as a DNS lookup, and SPF has a hard limit of 10 lookups per evaluation. Go over that, and the entire SPF check fails with a PermError, which most receivers treat as a failure.

For a complete breakdown of every mechanism, qualifier, and modifier, see our SPF record syntax guide.

How the SPF Lookup Actually Happens

When mail arrives at a receiving server, the server extracts the envelope sender domain (the MAIL FROM address used in the SMTP transaction, not the From header the recipient sees). It then queries DNS for a TXT record at that domain, looking for one that starts with v=spf1.

The receiver walks through the mechanisms left to right. For each mechanism, it checks if the sending IP matches. The first match wins. If the mechanism is ip4:203.0.113.5 and the sender is 203.0.113.5, that is a match. If the mechanism is include:_spf.google.com, the receiver fetches Google's SPF record and evaluates it recursively. If any rule in the included record matches, the include matches.

Each mechanism has a qualifier: + (pass), - (fail), ~ (softfail), or ? (neutral). If you write ip4:203.0.113.5 with no prefix, it defaults to + (pass). If you write -all, that is an explicit fail for anything that did not match earlier rules.

The result of SPF evaluation is one of: Pass (IP is authorized), Fail (IP is explicitly not authorized), SoftFail (IP is probably not authorized, but do not reject outright), Neutral (no policy), None (no SPF record found), or PermError (record is malformed or exceeded the 10-lookup limit).

Why SPF Records Break: The 10-Lookup Limit

The single most common SPF failure is hitting the 10-lookup limit. Every include:, a:, mx:, exists:, and redirect= directive triggers a DNS lookup. If your record chains through more than 10 lookups total, the evaluation stops with a PermError and the mail fails SPF.

A real-world example that breaks:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.salesforce.com include:servers.mcsv.net include:sendgrid.net include:_spf.hubspot.com -all

Google's include expands to 3 lookups, Outlook to 2, Salesforce to 2, Mailchimp (mcsv.net) to 2, SendGrid to 1, HubSpot to 1. That is 11 lookups before you count the top-level record itself. This record will PermError on most receivers.

The fix is to flatten the record by replacing include: directives with the actual ip4: and ip6: ranges those services use, or to consolidate sending through fewer providers. We cover the exact flattening process and maintenance strategies in our guide to fixing the 10-lookup limit.

SPF Alignment and DMARC

Passing SPF alone does not guarantee your mail will be delivered or marked as legitimate. DMARC, the policy layer on top of SPF and DKIM, requires alignment. For SPF to satisfy DMARC, the domain in the envelope sender (MAIL FROM) must match the domain in the visible From header, either exactly (strict alignment) or at the organizational domain level (relaxed alignment).

If you send from [email protected] but the From header shows [email protected], SPF will pass for news.example.com, but DMARC will fail because the domains do not align. Most receivers use DMARC as the final verdict, so an SPF pass with a DMARC fail still results in delivery problems.

This is why transactional email services often configure a custom return-path domain that matches your From domain. If you send from [email protected], the service sets the envelope sender to [email protected] so SPF and DMARC both align. For a full explanation of how DMARC ties SPF and DKIM together, see our DMARC glossary entry.

Common SPF Mistakes That Break Delivery

Multiple SPF records. You can only have one SPF record per domain. If you publish two TXT records that both start with v=spf1, DNS returns them in random order and most receivers will treat it as a PermError. Combine all your authorization rules into a single record.

Missing the all directive. If your record does not end with -all, ~all, or ?all, receivers do not know what to do with mail from unlisted IPs. Always include an all directive. Use -all if you are confident your record lists every legitimate sender, or ~all if you want a softer policy during testing.

Using +all. A record ending in +all says every IP on the internet is authorized to send for your domain. This makes SPF meaningless and invites spoofing. Never use +all.

Forgetting to update after changing providers. If you switch from SendGrid to Postmark but leave include:sendgrid.net in your record, you are authorizing a service you no longer use. Remove stale includes to reduce lookup count and tighten your policy.

Publishing SPF on subdomains without considering the parent. If you send from news.example.com, you need an SPF record at news.example.com, not just at example.com. SPF does not inherit from the parent domain.

How to Test Your SPF Record

Check your current SPF record with a DNS lookup:

dig TXT example.com +short | grep spf

or

nslookup -type=TXT example.com

Look for a TXT record starting with v=spf1. If you see multiple, you have a problem. If you see none, you have no SPF policy and mail from your domain will fail SPF checks.

To count DNS lookups, use an SPF validator like MXToolbox SPF Record Checker or dmarcian's SPF Surveyor. These tools recursively resolve every include: and report the total lookup count. If the count is above 10, your record will PermError in production.

Send a test email to a mailbox you control and inspect the headers. Look for Received-SPF: or Authentication-Results: headers. A passing result looks like:

Received-SPF: pass (google.com: domain of [email protected] designates 203.0.113.5 as permitted sender)

A failure looks like:

Received-SPF: fail (google.com: domain of [email protected] does not designate 198.51.100.99 as permitted sender)

If you see permerror, you have exceeded the lookup limit or have a syntax error.

SPF for High-Volume Cold Email

When you send cold email at scale, SPF becomes both more important and more complex. You are rotating through multiple sending domains and many IP addresses to distribute volume and protect reputation. Each sending domain needs its own SPF record, and each record must authorize only the IPs that actually send for that domain.

The mistake most high-volume senders make is publishing one giant SPF record that authorizes every IP in the pool. This inflates the lookup count and makes it impossible to isolate a compromised IP. Instead, partition your IPs by sending domain. If mail1.example.com sends from IPs 203.0.113.1 through 203.0.113.10, its SPF record should list only those IPs, not the entire /24 block.

Use ip4: with CIDR notation to keep the record compact:

v=spf1 ip4:203.0.113.0/28 -all

This authorizes 203.0.113.0 through 203.0.113.15 in a single mechanism, no lookups required.

If you use a sending platform that rotates mailboxes automatically, make sure the platform updates SPF records as it provisions new IPs. A stale SPF record that does not list a newly added IP will cause immediate delivery failures.

How SpamCipher Handles SPF Across Rotating Mailboxes

SpamCipher is built for unlimited, automated cold email sending at high volume. When you connect multiple sending mailboxes or let SpamCipher provision them for you, the platform manages SPF records across all of them so you do not have to manually update DNS every time a new IP comes online.

Every mailbox in your rotation gets its own SPF record, scoped to the IPs that mailbox actually uses. SpamCipher monitors the lookup count in real time and warns you before you hit the 10-lookup limit. If you bring your own infrastructure, SpamCipher provides the exact ip4: and ip6: entries you need to add. If you use done-for-you mailbox provisioning, SpamCipher configures SPF, DKIM, and DMARC automatically as part of the warm-up process.

Because SpamCipher runs warm-up, verification, and sending on one owned deliverability pipeline, SPF alignment is guaranteed before the first cold email goes out. The platform checks that the envelope sender domain matches the From domain and that the sending IP is authorized in SPF. If alignment is broken, the send is paused and you get an alert with the exact DNS fix required.

This is why SpamCipher can promise 90%+ inbox placement at unlimited volume. SPF, DKIM, and DMARC are not optional hygiene tasks you handle separately. They are built into the send flow, verified on every message, and automatically maintained as your infrastructure scales.

Frequently asked questions