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.

The lookups limit and why it breaks records

The single most commonly broken SPF record exceeds the DNS lookup limit. SPF specifies that a policy may perform at most 10 DNS lookups while evaluating, and every include:, a:, mx:, ptr:, and exists: mechanism counts against that budget. When a record chains several include:s — one for each sending platform a company uses — it is easy to blow past 10 lookups, and when it does, the SPF check fails for everyone. The failure is subtle: the record exists and looks right, but senders evaluate it as a permanent error. Consolidating includes and measuring lookup counts is the fix.

The structural errors that silently fail

Several other SPF mistakes are common and silent:

• More than one SPF record. A domain must have exactly one TXT record starting with v=spf1. Multiple records make the whole policy invalid.
• Missing the ~all or -all term. Without a catch-all at the end, an unlisted sender is neither explicitly allowed nor denied, weakening the policy.
• Wrong include: or a reference to a record that is missing. An include: pointing at a domain with no valid SPF record fails that mechanism.
• ptr: mechanism. It requires a reverse-DNS lookup (counting toward the limit) and is unreliable; it is widely discouraged in favor of ip4:/ip6:.

Recognizing these patterns lets you audit a record by eye before you even run a tool.

Reading a policy check result

When you run an SPF check, read the result in context. A pass means the sender is explicitly allowed; a neutral or none is weaker (the policy did not explicitly allow, so receivers may treat it leniently); fail or softfail means the sender was not authorized. The failure you care about is the one where your legitimate platform is evaluated as not allowed — that is the record that is silently dropping or spamming your mail. The email authentication guide puts SPF into the full picture alongside DKIM and DMARC, since SPF alone rarely tells the whole story.

A disciplined way to keep SPF healthy

Keep SPF maintainable rather than accretive: consolidate platforms into a small number of include:s, monitor the lookup count so it stays well under 10, keep exactly one record, and add ~all (or -all once confident) at the end. Review the record whenever you add or remove a sending platform, and re-check it after any change. Treating SPF as a maintained policy rather than a one-time setup prevents the most common and most damaging misconfigurations.