What is an SPF record?

An SPF (Sender Policy Framework) record is a DNS TXT record that lists every server and IP address authorized to send email on behalf of your domain. Receiving mail servers check this record to decide whether an incoming message is legitimate.

What happens if I don't have an SPF record?

Without an SPF record, any server in the world can send email claiming to be from your domain. This makes your domain vulnerable to spoofing and phishing, and many email providers will flag or reject your legitimate emails.

What is the SPF 10-lookup limit?

The SPF specification (RFC 7208) limits the number of DNS lookups during SPF evaluation to 10. Each 'include', 'a', 'mx', and 'redirect' mechanism counts as one lookup. Exceeding this limit causes SPF to return a PermError, effectively failing authentication.

What is the difference between -all and ~all in SPF?

The '-all' mechanism is a hard fail — it tells receivers to reject email from unauthorized servers. The '~all' mechanism is a soft fail — it marks unauthorized email as suspicious but doesn't outright reject it. For maximum protection, use '-all' once you've confirmed all legitimate senders are listed.

Can I have multiple SPF records on one domain?

No. The SPF standard requires exactly one SPF TXT record per domain. Having two or more SPF records causes a PermError and breaks SPF validation entirely. If you need to add senders, merge them into a single record.

What is SPF? How Sender Policy Framework Works

Updated February 6, 2026

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:

You publish a TXT record in your domain's DNS that lists your authorized mail servers.
When someone receives an email from your domain, their mail server looks up your SPF record.
The server checks whether the sending IP matches any mechanism in the record.
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:

Mechanism	Purpose	Example	Counts as DNS Lookup?
`ip4`	Authorize an IPv4 address or range	`ip4:203.0.113.25`	No
`ip6`	Authorize an IPv6 address or range	`ip6:2001:db8::/32`	No
`include`	Include another domain's SPF record	`include:_spf.google.com`	Yes
`a`	Authorize the domain's A record IPs	`a` or `a:mail.example.com`	Yes
`mx`	Authorize the domain's MX server IPs	`mx`	Yes
`redirect`	Use another domain's SPF record entirely	`redirect=_spf.example.com`	Yes
`exists`	Advanced: pass if a DNS A lookup succeeds	`exists:%{i}.spf.example.com`	Yes

Qualifiers

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

Qualifier	Meaning	Result
`+` (default)	Pass — the sender is authorized	Accept
`-`	Hard fail — the sender is explicitly not authorized	Reject
`~`	Soft fail — the sender is probably not authorized	Accept but mark
`?`	Neutral — no assertion about the sender	Accept

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 can send for us; reject everything else.

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

This means: Google's servers can send for us; soft-fail everything else (mark as suspicious but don't reject).

Start with ~all (soft fail) while you are verifying that all legitimate senders are listed. Once you are confident your record is complete, switch to -all (hard fail) for maximum protection.

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.

Exceeding the 10-lookup limit causes SPF to return a PermError. This is treated as a fail — your legitimate emails will fail SPF checks. Use DNS Kit's Email Health Checker to count your current lookups.

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:

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

dig TXT example.com +short

Look for the entry starting with v=spf1.

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

Check your SPF record and count DNS lookups instantly.

Free, instant, no login required.

Launch Email Health Checker →

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.