SPF Records: How to Configure Sender Policy Framework

What Is SPF?

Sender Policy Framework (SPF) is a DNS-based email authentication protocol that lets domain owners declare which mail servers are allowed to send email on their behalf. Receiving mail servers check the sending server's IP address against the SPF record published in the domain's DNS. If the IP does not match any authorized source, the message fails the SPF check, helping prevent email spoofing and phishing. For a broader look at how SPF, DKIM, and DMARC work together, see our email authentication deep dive.

SPF Record Syntax Breakdown

An SPF record is a DNS TXT record published at your domain's root. Every SPF record starts with the version tag v=spf1 and ends with an all mechanism that defines the default policy for unmatched senders.

Here is an annotated example:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com a mx -all

Mechanisms

• ip4: / ip6: -- Authorizes a specific IP address or CIDR range. Use this for mail servers with static IPs that you control directly. Example: ip4:198.51.100.25 or ip4:203.0.113.0/24.
• include: -- Delegates authorization to another domain's SPF record. This is how you authorize SaaS providers like Google Workspace or Mailchimp. Example: include:_spf.google.com.
• a -- Authorizes the IP addresses returned by your domain's A (or AAAA) record. Useful if your web server also sends email.
• mx -- Authorizes the IP addresses of your domain's MX (mail exchange) servers.
• all -- The catch-all mechanism that applies to any sender not matched by earlier mechanisms. Always place it last.

Qualifiers

Each mechanism can be prefixed with a qualifier that determines what happens when it matches:

• + (Pass) -- Authorize the sender. This is the default if no qualifier is specified.
• - (Fail) -- Reject the sender. Used with all to create a hard fail policy: -all.
• ~ (SoftFail) -- Accept but mark as suspicious. Used with all as ~all.
• ? (Neutral) -- No opinion. Rarely useful.

Step-by-Step: Creating an SPF Record

Google Workspace

If Google Workspace is your only email sender:

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

Microsoft 365

If Microsoft 365 is your only email sender:

v=spf1 include:spf.protection.outlook.com -all

Multiple Providers

Most organizations use several services that send email. Combine them in a single record. For example, if you use Google Workspace for corporate email, Mailchimp for marketing, and a custom server at 198.51.100.25 for transactional email:

v=spf1 ip4:198.51.100.25 include:_spf.google.com include:servers.mcsv.net -all

How to Publish the Record

1. Log in to your DNS provider (Cloudflare, Route 53, GoDaddy, etc.).
2. Navigate to the DNS management page for your domain.
3. Create a new TXT record with the Host set to @ (the root domain).
4. Paste your SPF string as the Value.
5. Save and allow time for DNS propagation (usually under 5 minutes, but can take up to 48 hours depending on TTL settings).

The 10 DNS Lookup Limit

The SPF specification (RFC 7208) imposes a hard limit of 10 DNS lookups during SPF evaluation. Exceed this and the entire check returns permerror, which is treated the same as having no SPF record at all. This failure is silent -- email continues to deliver, but SPF protection is gone.

What Counts as a Lookup

Each of these mechanisms triggers one or more DNS lookups:

• include: -- 1 lookup, plus any lookups nested inside the included record.
• a -- 1 lookup.
• mx -- 1 lookup (plus an additional lookup per MX hostname to resolve its IP).
• redirect= -- 1 lookup.
• exists: -- 1 lookup.

These mechanisms do not count toward the limit:

• ip4: and ip6: -- No DNS lookup required (they are literal values).
• all -- No DNS lookup required.

How to Audit Your Lookup Count

Use an online SPF checker (such as MXToolbox, dmarcian, or EasyDMARC) to recursively expand your record and count lookups. You can also do it manually by following each include: and counting the chain.

For a quick manual check, query each included domain:

dig TXT _spf.google.com +short

Then follow any nested include: entries and tally the total.

SPF Flattening

If you are at or near the limit, SPF flattening replaces include: and a/mx mechanisms with their resolved ip4:/ip6: addresses. This eliminates DNS lookups but introduces a maintenance burden: if any provider changes their sending IPs, your flattened record becomes stale. Automated flattening services (such as AutoSPF or dmarcian's tools) can handle this by re-resolving and republishing on a schedule.

Common Mistakes

Using +all or ~all

The +all qualifier authorizes every IP address on the internet to send as your domain. It completely defeats the purpose of SPF. The ~all (softfail) qualifier signals suspicion but does not instruct receiving servers to reject the message, leaving a wide opening for attackers. Always use -all once you have a complete inventory of your legitimate senders.

Publishing Multiple SPF Records

A domain must have exactly one SPF TXT record. If you publish two (for example, adding a new one without removing the old), both become invalid per the RFC. Receiving servers will return a permerror result. Before adding a new SPF record, always check for and remove any existing one.

Forgetting Third-Party Senders

Every service that sends email on your behalf must be included in your SPF record. Commonly overlooked senders include:

• Helpdesk and ticketing systems (Zendesk, Freshdesk)
• Marketing automation (HubSpot, Mailchimp, SendGrid)
• Invoicing and billing platforms (Stripe, QuickBooks)
• Monitoring and alerting tools that send notifications from your domain
• CRM platforms (Salesforce)

An incomplete SPF record causes legitimate email to fail authentication, leading to deliverability problems or rejection when DMARC enforcement is active.

Exceeding the 10-Lookup Limit

As covered above, each third-party include: adds to your lookup count, and nested includes compound quickly. A single include:_spf.google.com already expands into multiple nested lookups. Add a few more SaaS providers and you can silently exceed the limit without any warning from your DNS provider.

How to Test Your SPF Record

Using dig (Linux/macOS)

dig TXT example.com +short

Look for the entry starting with v=spf1. Example output:

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

Using nslookup (Windows)

nslookup -type=TXT example.com

Verify the Result with a Test Email

Send an email from your domain to an external address (a Gmail account works well). Open the received message, view the original message headers, and look for the Received-SPF: header. It should show pass:

Received-SPF: pass (google.com: domain of user@example.com designates 203.0.113.25 as permitted sender)

If you see softfail, fail, neutral, or permerror, your SPF configuration needs attention.

Quick Checklist

• One record: Confirm only a single TXT record starting with v=spf1 exists.
• Hard fail: Confirm the record ends with -all, not ~all or +all.
• Lookup count: Confirm the total DNS lookups (including nested) is 10 or fewer.
• Complete coverage: Confirm every service that sends email as your domain is included.
• No syntax errors: Confirm there are no typos, extra spaces, or malformed mechanisms.

If your domain fails any of these checks, update your DNS TXT record, wait for propagation, and re-test. Once SPF is solid, the next step is configuring DKIM signing -- see our DKIM, MTA-STS, and TLS-RPT setup guide for the complete process.