What is SPF? How Sender Policy Framework Works

Sender Policy Framework (SPF) is one of the three pillars of email authentication. It answers a simple question: is the server that just sent this email actually allowed to send on behalf of this domain?

Without SPF, anyone can forge the From address on an email. With SPF, receiving mail servers can verify that the sending server is on your approved list before they deliver the message.

How SPF Works

The process is straightforward:

1. You publish a TXT record in your domain's DNS that lists your authorized mail servers.
2. When someone receives an email from your domain, their mail server looks up your SPF record.
3. The server checks whether the sending IP matches any mechanism in the record.
4. Based on the result (pass, fail, soft fail, neutral), the receiver decides what to do with the message.

SPF checks the envelope sender (the MAIL FROM address used in the SMTP transaction), not the From header that users see. This distinction matters for DMARC alignment.

SPF Record Syntax

An SPF record is a DNS TXT record that starts with v=spf1 and contains one or more mechanisms. Here is a detailed example:

v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 include:_spf.google.com include:sendgrid.net a mx -all

Let's break down every part:

Version Tag

Every SPF record must begin with v=spf1. This identifies the TXT record as an SPF record. There is no v=spf2 — if you see one, it is not a valid SPF record.

Mechanisms

Mechanisms define which servers are authorized. The most common ones are:

Qualifiers

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

The All Mechanism

The all mechanism at the end of the record is a catch-all. It determines what happens to any server that didn't match an earlier mechanism.

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

This means: Google's servers are authorized; everything else returns SPF Fail. The receiver still decides whether to reject, quarantine, or accept the message under its local policy.

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

This means: Google's servers are authorized; everything else returns SPF Softfail. The receiver decides how that result affects delivery.

The 10-Lookup Limit

This is the single most common cause of SPF failures.

The SPF specification (RFC 7208) limits DNS lookups during evaluation to 10. Every include, a, mx, redirect, and exists mechanism counts as one lookup. The ip4 and ip6 mechanisms do not count because they don't require a DNS query.

The problem compounds because include mechanisms are recursive. If your record includes _spf.google.com, and that record itself includes two more domains, that counts as three lookups total.

How to Stay Under the Limit

• Replace include with ip4/ip6 when possible. If a service sends from a fixed set of IPs, use those directly.
• Remove unused services. If you no longer use a mail provider, remove its include.
• Use SPF flattening tools that resolve include chains into IP addresses. Be cautious — if the provider changes IPs, your record goes stale.
• Move subdomains. Send marketing email from marketing.yourdomain.com with its own SPF record instead of adding senders to the root domain.

Common SPF Records by Provider

Here are SPF records for popular email providers:

# Google Workspace
v=spf1 include:_spf.google.com -all

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

# Google Workspace + SendGrid
v=spf1 include:_spf.google.com include:sendgrid.net -all

# Google Workspace + Mailchimp + SendGrid
v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net -all

Common Mistakes

Multiple SPF Records

A domain must have exactly one SPF TXT record. If you add a second one, both are invalid. Merge all your mechanisms into a single record.

# WRONG - two separate SPF records
v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -all

# CORRECT - one merged record
v=spf1 include:_spf.google.com include:sendgrid.net -all

Using +all

Never use +all. It tells the world that literally every server is authorized to send email as your domain, completely defeating the purpose of SPF.

Forgetting Third-Party Senders

If you use services like Mailchimp, SendGrid, HubSpot, or Zendesk to send email from your domain, their servers must be included in your SPF record. Missing any sender means those emails fail SPF checks.

PTR Mechanism

The ptr mechanism is deprecated and should not be used. It is slow, unreliable, and many receivers ignore it entirely.

Testing Your SPF Record

You can verify your SPF configuration in several ways:

1. DNS Kit Email Health Checker — instantly validates your SPF record and counts DNS lookups
2. Command line — use dig to inspect the raw record:

dig TXT example.com +short

Look for the entry starting with v=spf1.

3. Send a test email and inspect the Received-SPF or Authentication-Results headers in the received message.

SPF and DMARC Alignment

SPF alone is useful, but it becomes much more powerful with DMARC. DMARC adds a policy layer that tells receivers what to do when SPF fails, and it checks alignment — ensuring the domain in the From header matches the domain that passed SPF.

For a complete email authentication setup, you need SPF, DKIM, and DMARC working together. Check out our email authentication overview to understand how all three protocols fit together.