SPF Record Explained: Setup, Syntax, and the 10-Lookup Limit

What Is an SPF Record?

An SPF (Sender Policy Framework) record is a DNS TXT record published at your domain that lists every mail server, IP address, and third-party service authorised to send email using your domain in the envelope sender address. It is defined in RFC 7208 and is one of the three email authentication standards — alongside DKIM and DMARC — that form the foundation of modern email deliverability.

When a receiving server accepts an inbound message claiming to be from you@example.com, it performs a DNS lookup for the TXT record at example.com, retrieves the SPF policy, and checks whether the IP address of the sending server appears in that policy. If it does, the check passes. If it doesn't, the result depends on your qualifier — either a soft fail that most servers accept with reduced trust, or a hard fail that may cause rejection.

SPF alone does not prevent spoofing in the visible From header (that's DMARC's job), but it does authenticate the envelope sender — the technical address used during SMTP delivery, which must align with your domain for SPF to contribute to DMARC pass.

How SPF Authentication Works

Understanding the SPF check process is essential before writing a record, because the mechanism is more nuanced than a simple IP whitelist.

1. Sender transmits the message. The sending mail server connects to the recipient's server and presents the envelope sender address (the MAIL FROM: command in SMTP — separate from the visible From header).

2. Recipient queries SPF. The receiving server extracts the domain from the MAIL FROM: address and performs a DNS TXT lookup for that domain's SPF record.

3. SPF mechanisms are evaluated left to right. Each mechanism in the record is tested against the sending IP in order. The first mechanism that matches determines the result. If no mechanism matches, the all mechanism at the end applies.

4. Result is returned. The check produces one of: pass, fail, softfail, neutral, none (no SPF record found), permerror (SPF record is invalid), or temperror (DNS lookup failed temporarily).

5. Receiving server applies policy. What the server does with the result depends on its own configuration. Most servers reject or quarantine on fail, accept with a spam score penalty on softfail, and the result feeds into DMARC evaluation.

ℹ️ Note: SPF checks the envelope sender (MAIL FROM:), not the visible From: header. These are often the same, but not always — particularly with forwarding and mailing lists. DMARC alignment requires the envelope sender domain to match the From header domain for SPF to count toward a DMARC pass.

SPF Record Syntax: Mechanisms, Qualifiers, and Modifiers

An SPF record is a single DNS TXT value starting with v=spf1 and ending with an all mechanism. Between them are mechanisms that define authorised senders.

Mechanisms

Qualifiers

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

The + qualifier is implied when no prefix is written, so include:google.com and +include:google.com are identical.

A Complete SPF Record Dissected

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all

Reading left to right:

• v=spf1 — SPF version declaration; always required, always first
• ip4:203.0.113.10 — Authorise a specific IP (costs 0 lookups)
• include:_spf.google.com — Import Google Workspace's SPF (costs 1+ lookups)
• include:sendgrid.net — Import SendGrid's SPF (costs 1+ lookups)
• ~all — Softfail anything not matched by the above

Modifiers

Two modifiers exist but are rarely used in practice:

• redirect=domain — Replaces the entire SPF record with the referenced domain's policy. Useful for centralising SPF across multiple domains. Cannot be combined with all.
• exp=domain — Specifies a domain where an explanation string is published for failed checks. Rarely implemented.

Setting Up SPF for Common Email Providers

Most organisations send email through a combination of their own servers and third-party platforms. Each platform requires its own include: directive. Below are the standard records for the most common providers:

# Google Workspace (Gmail for Business)
v=spf1 include:_spf.google.com ~all

# Microsoft 365 (Exchange Online)
v=spf1 include:spf.protection.outlook.com ~all

# SendGrid
v=spf1 include:sendgrid.net ~all

# Mailchimp / Mandrill
v=spf1 include:servers.mcsv.net ~all

# Mailgun
v=spf1 include:mailgun.org ~all

# Multi-sender combined record (Google + Microsoft + SendGrid)
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all

💡 Tip: Your domain should have exactly one SPF TXT record. Multiple TXT records starting with v=spf1 on the same domain cause a permerror — the receiving server cannot determine which record applies. If you need to add a new sender, edit the existing record rather than creating a second one.

Publish your SPF record as a TXT record at the root of your domain (i.e., @ or example.com, not a subdomain, unless you're specifically protecting a subdomain).

The 10-DNS-Lookup Limit — Why It Matters and How to Stay Under It

This is where most SPF setups silently break at scale. RFC 7208 mandates that an SPF evaluation must not require more than 10 DNS lookups — including recursive lookups triggered by include: directives. If the limit is exceeded, the check returns permerror, which most receiving servers treat as a hard authentication failure.

What counts as a lookup?

Each of these mechanisms triggers one or more DNS lookups when evaluated:

• include: — 1 lookup, plus whatever the included record itself requires
• a — 1 lookup
• mx — 1 lookup, plus 1 per MX target (if those targets are evaluated)
• ptr — multiple lookups (another reason to avoid it)
• exists — 1 lookup

ip4: and ip6: mechanisms cost zero lookups.

Counting your lookups in practice

A single include:_spf.google.com typically costs 1 lookup but expands to include additional lookups within Google's record. By the time you add Google Workspace, Microsoft 365, SendGrid, a transactional email service, and your own mail server mechanisms, it's trivial to hit 10.

# Retrieve your raw SPF record
dig TXT example.com +short

# Retrieve an included domain's SPF to count its sub-lookups
dig TXT _spf.google.com +short
dig TXT _spf.protection.outlook.com +short

Trace each include: manually and count every mechanism that requires a DNS lookup within the included record and any nested includes.

⚠️ Warning: Each include: directive costs at least 1 lookup — and include: chains multiply fast. A record that looks like it has 5 include: directives may easily trigger 12–15 lookups when the included records are fully resolved. The failure is silent until a receiving server flags it.

Use our SPF Checker to automatically count your lookup depth — it recursively traces every include: directive and flags records that are at or approaching the limit.

Staying under the limit

If you're close to or over 10 lookups, your options are:

1. Remove unused providers. Audit every include: against your actual sending infrastructure. Deprecated services, former ESPs, and test configurations frequently remain.

2. Replace include: with ip4: where possible. If a provider has a stable, documented IP range, replacing include:provider.com with explicit ip4: ranges eliminates the lookup cost. The trade-off is maintenance — you must update the record if the provider changes their IPs.

3. SPF flattening. Replace all include: directives with the resolved IP ranges they contain. This eliminates lookups entirely but requires ongoing maintenance as providers change their IP ranges. For a full guide, see our SPF Permerror fix guide.

SPF Qualifiers: pass, softfail, fail, neutral

The qualifier on your all mechanism determines what happens to email that doesn't match any authorised sender. This is one of the most consequential decisions in SPF setup.

-all (hard fail)

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

Any sending IP not covered by the record results in a fail. Receiving servers should reject the message. This is the correct choice for domains that send email from a known, complete set of servers — and where you're confident the record is accurate. It provides the strongest anti-spoofing protection.

Use -all when: Your SPF record is comprehensive and complete. You know every server that sends email for this domain. You've tested thoroughly and are confident nothing legitimate will fail.

~all (soft fail)

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

Any sending IP not covered results in a softfail. Most receiving servers accept the message but may apply a spam score penalty or flag it. This is the practical default for most organisations during initial SPF deployment or where the sending infrastructure is complex.

Use ~all when: You're still mapping your sending infrastructure and may not have all authorised servers in the record yet. You're in the early stages of email authentication deployment. DMARC at p=reject handles the actual rejection — SPF's ~all feeds into DMARC evaluation without aggressively dropping mail.

?all (neutral)

Treats non-matching senders as neutral — equivalent to no policy. Provides no anti-spoofing value. Avoid.

+all (pass all)

Authorises every IP address on the internet to send mail as your domain. This completely defeats the purpose of SPF. Never use +all.

Common SPF Mistakes and How to Fix Them

Multiple SPF records on the same domain

Publishing two TXT records starting with v=spf1 at the same domain is an instant permerror. Receiving servers cannot determine which record to use. Merge all your mechanisms into a single record.

# Check for duplicate SPF records
dig TXT example.com +short | grep "v=spf1"
# If this returns more than one line — you have a problem

Using ~all forever

Softfail provides weaker protection than fail. Many organisations deploy ~all temporarily and never revisit it. Once your SPF record is complete and tested, switch to -all for maximum protection. Pair this with DMARC at p=quarantine or p=reject for complete coverage.

Forgetting transactional email platforms

Marketing emails, password resets, invoice notifications, and support ticketing systems frequently send from your domain. Every platform sending email as your domain needs its include: in your SPF record. Common omissions include Zendesk, Salesforce, HubSpot, Intercom, and Postmark.

Protecting subdomains

SPF records only apply to the domain where they are published. If you send email from support@support.example.com, you need a separate SPF record at support.example.com. The root domain's record does not cover subdomains.

Relying on SPF alone

SPF authenticates the envelope sender but not the visible From header. A spammer can pass SPF by spoofing a different domain in the MAIL FROM: while forging your domain in the visible From. DMARC closes this gap by requiring alignment between SPF and the From header. See our DMARC Policy Enforcement guide for how to implement full protection.

How to Test and Verify Your SPF Record

Before and after any changes, validate your SPF record through multiple methods.

Retrieve the raw record

# Retrieve your SPF record directly
dig TXT example.com +short

# Using nslookup
nslookup -type=TXT example.com

# Target a specific resolver to see what it returns
dig TXT example.com @8.8.8.8 +short

A correct SPF record looks like:

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

Send a test email to a diagnostic address

Gmail's test address publishes full authentication headers. Send an email from your domain to a Gmail address and inspect the headers — look for Authentication-Results: containing spf=pass.

Use the SPF Checker

Verify your SPF record using our SPF Checker, which validates syntax, counts DNS lookups recursively, checks for duplicate records, and flags common misconfigurations including missing mechanisms for your domain's own MX servers.

Check the full email authentication picture

After confirming SPF, run an Email Deliverability Report to see how your full authentication stack — SPF, DKIM, and DMARC — performs together. All three must be correctly configured to meet Google and Yahoo's bulk sender requirements and achieve reliable inbox placement.

Also verify your DMARC record is published: check your DMARC record to confirm SPF and DMARC alignment is configured correctly.

Frequently Asked Questions

Next Steps

With your SPF record published and validated, the next priority is DKIM — which adds a cryptographic signature to your outgoing messages that survives forwarding and provides a second authentication signal. From there, DMARC ties SPF and DKIM together and gives you visibility and control over what happens to mail that fails authentication.

If you're seeing permerror in your SPF results or your lookup count is approaching 10, read our SPF Permerror fix guide for step-by-step instructions on diagnosing and resolving the lookup limit problem.

To understand what Google and Yahoo now require from senders — including the SPF, DKIM, and DMARC thresholds — see our Google & Yahoo Bulk Sender Requirements guide.

Browse all email authentication guides on DNSnexus for the full picture.

Related Guides

• SPF Permerror: What Causes It, How to Diagnose It, and How to Fix It
• DMARC Policy Enforcement: Moving from none to quarantine to reject Safely
• Google & Yahoo 2025 Bulk Sender Requirements: The Complete Compliance Checklist