SPF Record: The Complete Guide

What is SPF?

SPF (Sender Policy Framework) is a DNS-based email authentication protocol that lets domain owners specify which mail servers are authorized to send email on behalf of their domain.

When you publish an SPF record, you're creating a public list of IP addresses and servers that are allowed to send email using your domain name. Receiving mail servers check this list to decide whether to trust the email.

SPF is one of three pillars of email authentication, alongside DKIM and DMARC. While SPF alone isn't sufficient for full protection, it's a critical foundation.

How SPF works

Here's what happens when a receiving server gets an email:

1. The server looks at the envelope sender (the "MAIL FROM" address in the SMTP conversation, not necessarily the "From" header you see)
2. It extracts the domain from this address
3. It queries DNS for a TXT record at that domain
4. It checks whether the sending server's IP address matches any of the authorized sources in the SPF record
5. Based on the result (pass, fail, softfail, neutral), the server decides what to do

A key detail: SPF checks the envelope sender, not the "From" header. This is why SPF alone doesn't prevent spoofing of the visible "From" address — you need DMARC for that (which enforces alignment between the envelope sender and the "From" header).

SPF syntax explained

An SPF record is a TXT DNS record published at your domain's root. Every SPF record starts with v=spf1 and contains a series of mechanisms and modifiers:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net ~all

Let's break this down:

• v=spf1 — Identifies this as an SPF record (required, must be first)
• ip4:203.0.113.0/24 — Authorizes this IP range
• include:_spf.google.com — Authorizes Google Workspace servers
• include:sendgrid.net — Authorizes SendGrid servers
• ~all — Everything else should softfail

Mechanisms

Mechanisms are the building blocks of SPF records. They define who is authorized to send:

ip4 and ip6

Authorize specific IP addresses or CIDR ranges:

ip4:203.0.113.5        ip4:203.0.113.0/24     ip6:2001:db8::/32      

These are the most straightforward mechanisms and don't count toward the DNS lookup limit.

include

References another domain's SPF record. Used when third-party services send email on your behalf:

include:_spf.google.com      include:sendgrid.net          include:spf.protection.outlook.com  

Each include counts as one DNS lookup. The included domain's SPF record is fetched and evaluated recursively.

a

Authorizes the IP addresses that your domain's A (or AAAA) records point to:

a                  a:mail.example.com 

mx

Authorizes the IP addresses of your domain's MX (mail exchange) servers:

mx                  mx:example.com      

all

Matches everything. Always placed last as a catch-all:

-all    ~all    ?all    +all    

Qualifiers

Each mechanism can be prefixed with a qualifier that determines the result when matched:

The + qualifier is the default and is usually omitted. So include:example.com and +include:example.com mean the same thing.

The 10 DNS lookup limit

This is the most common source of SPF problems. The SPF specification (RFC 7208) limits SPF evaluation to 10 DNS lookups. If your SPF record exceeds this limit, the entire check returns permerror — as if you had no SPF record at all.

What counts as a DNS lookup?

• include: — 1 lookup (plus any lookups in the included record)
• a — 1 lookup
• mx — 1 lookup (plus A lookups for each MX host)
• redirect= — 1 lookup
• exists: — 1 lookup

What does NOT count?

• ip4: and ip6: — no DNS lookup needed
• all — no DNS lookup needed
• The initial TXT record lookup — doesn't count

How to stay under the limit

1. Audit your includes — Remove services you no longer use. Old marketing platforms, retired CRMs, and migrated email providers add unnecessary lookups
2. Use ip4/ip6 for static IPs — If a service has a fixed IP, use ip4: instead of include:
3. Flatten your SPF record — Resolve include: domains to their final IPs. Be careful: you'll need to keep these updated if the service changes IPs
4. Use subdomains — Send marketing emails from marketing.yourdomain.com with its own SPF record, keeping the main domain's record lean

Common SPF mistakes

Multiple SPF records

A domain must have only one SPF record. If you have two TXT records starting with v=spf1, the result is undefined (most servers return permerror). This commonly happens when adding a new email service without updating the existing record.

Wrong:

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

Correct:

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

Using +all

The mechanism +all means "authorize everyone." This defeats the purpose of SPF entirely. Always use -all (hard fail) or ~all (soft fail).

Missing the all mechanism

Without a trailing all mechanism, there's no default action for IPs that don't match. The result is neutral, which provides weaker protection than ~all or -all.

Stale records

SPF records accumulate include: entries over time as you add services. When you stop using a service, the include stays. This wastes DNS lookups and can push you over the limit. Audit your SPF record at least annually.

Using ptr mechanism

The ptr mechanism is deprecated by RFC 7208. It's slow, unreliable, and should not be used. Some services still recommend it in their documentation — ignore those instructions and use include: or ip4: instead.

Best practices

1. Start with ~all, aim for -all — Use softfail while setting up, switch to hardfail once you're confident all legitimate sources are listed
2. Audit regularly — Review your SPF record quarterly. Remove unused includes. Check lookup counts
3. Use subdomains for different services — notifications.yourdomain.com, marketing.yourdomain.com, each with its own lean SPF record
4. Always pair with DMARC — SPF alone checks the envelope sender, not the visible "From" header. DMARC adds the alignment check that closes this gap
5. Monitor with DMARC reports — DMARC aggregate reports show which IPs are sending as your domain and whether they pass SPF. This is the best way to discover unauthorized senders or misconfigured legitimate ones
6. Don't forget IPv6 — If your mail servers have IPv6 addresses, include ip6: mechanisms too

Ready to check your SPF record? Use our free SPF Checker tool, or see the full email authentication guide to understand how SPF works together with DKIM and DMARC.