SPF: The Most Commonly Broken Email Record

SPF (Sender Policy Framework) is one of the most important email authentication mechanisms — and one of the most frequently misconfigured. It's supposed to stop someone from forging your domain, but a subtly wrong SPF record can cause your legitimate mail to fail authentication and land in spam, or worse, leave you open to spoofing.

This guide explains what SPF actually does, the most common mistakes that break it, and how to check and fix your record.

What SPF actually does

SPF is a TXT record on your domain that lists which IPs/hosts are allowed to send mail for that domain. When a receiver gets a message claiming to be from yourdomain.com, it looks up your SPF record and checks whether the sending server is on the list.

A basic SPF record looks like:

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

The key parts:

• v=spf1 — the version.
• include: — pull in another domain's allowed senders (e.g. your email provider).
• ~all (soft fail) or -all (hard fail) — what to do with senders not listed.

The most common mistakes

1. Too many DNS lookups (the #1 killer)

SPF allows a maximum of 10 DNS lookups across include, redirect, a, mx, and ptr mechanisms. Every include your record pulls in counts as a lookup, and each of those may pull in more. When you exceed 10, SPF returns permerror, and many receivers treat permerror as a fail — your legitimate mail fails.

This usually happens when you stack multiple include: lines (Google, Salesforce, SendGrid, Mailchimp…) without checking the count.

2. A missing or wrong all mechanism

The all mechanism is the safety net. Without it, the record never says what to do with unlisted senders, and many receivers treat an absent all as "the record passes for anything," which defeats the purpose.

• ~all — soft fail (treat as suspicious, often spam).
• -all — hard fail (reject).

If you omit all entirely, you're not actually protecting against forgery.

3. The wrong include

An include must point at the host that actually sends your mail. A common mistake is including the wrong provider, or an include that itself has too many lookups, which cascades into a permerror.

4. Multiple SPF records

If your domain has more than one v=spf1 record, DNS returns them all, and the result is undefined — receivers often treat it as permerror. You should have exactly one SPF record per domain.

5. redirect used as include

redirect= tells the receiver to use the entire record of another domain, which means your own all mechanism is ignored. Confusing redirect with include is a subtle and common error.

6. Case or formatting errors

SPF is case-insensitive, but a stray space, a missing space, or a typo in the mechanism can invalidate the whole record.

How to check your SPF

Don't guess — check it. You can use the SPF inspector at /tools/spf-inspector (or your DNS tools) to:

• Fetch and parse the v=spf1 record.
• Count the DNS lookups and flag when you're near or over the 10-limit.
• Verify the all mechanism is present and check its strength.
• List every include so you can spot duplicates or wrong hosts.

A healthy result shows: 1 record, includes counted, lookups well under 10, and a clear ~all or -all.

Fixing a broken record

1. Consolidate includes. Keep only the providers that actually send your mail. If you're over the lookup limit, replace a heavy include with the specific IP ip4:/ip6: mechanisms for that sender.
2. Always end with ~all or -all. Start with ~all (soft fail) while you confirm you've listed everything, then tighten to -all once you're sure.
3. One record only. Remove duplicate v=spf1 TXT records.
4. Re-check after every change. SPF propagates over a few minutes to hours; re-run the inspector after changes.

The takeaway

SPF is simple in theory and easy to get wrong in practice. The three rules that prevent most failures: stay under the 10-lookup limit, always end with ~all/-all, and have exactly one record with the right includes. Check it regularly, and your legitimate mail will authenticate instead of landing in spam.

If you're setting up DMARC (which builds on SPF), see the DMARC migration guide and the DKIM alignment guide.