What is an SPF record? And the 10-lookup limit that breaks it

Published October 14, 2026 · about a 7-minute read

SPF is the oldest and simplest of the three email-authentication checks, and it's the one I see broken most often — not because people set it up wrong, but because it quietly outgrows a limit almost nobody knows about. You add a new sending tool, then another, and one day your SPF just stops working. No bounce, no warning. Let me walk you through how SPF actually works, and the gotcha that bites nearly everyone eventually.

What SPF does

SPF — Sender Policy Framework — is a published list of which mail servers are allowed to send email using your domain. It lives in DNS as a TXT record. When a receiving server gets a message that claims to be from you@yourdomain.com, it looks up your SPF record and asks a simple question: did this message come from a server you've authorized? If yes, SPF passes. If no, it fails, and that failure feeds into your DMARC decision about what to do with the message.

That's the entire idea. SPF doesn't encrypt anything or sign anything — that's DKIM's job. SPF just answers "is this sender on the list." It's a bouncer with a clipboard.

Reading a record

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.25 ~all

Piece by piece:

• v=spf1 — the version tag. Every SPF record starts with it.
• include:_spf.google.com — "also trust whatever this other domain's SPF record authorizes." This is how you bless Google Workspace, Mailchimp, your CRM, and so on. Each provider gives you an include string.
• ip4:198.51.100.25 — a specific server IP you trust directly. There's an ip6: equivalent.
• ~all — the catch-all at the end, and it must be last. It says what to do with everything not matched above.

That final all mechanism matters more than it looks:

• -all (hardfail) — "if it's not on my list, reject it." The strong setting.
• ~all (softfail) — "if it's not on my list, treat it as suspicious but don't hard-reject." A reasonable place to sit while you're still confirming you've listed every legitimate sender.
• +all — "allow anything." This authorizes the entire internet to send as you. Never use it; it's the same as having no SPF at all.

Start at ~all while you verify your senders, then tighten to -all once you're confident. Leaving softfail in place forever means a spoofer sending from an unlisted IP still slips through the gap.

The 10-lookup limit — the part that breaks everything

Here's the gotcha. SPF evaluation is capped at 10 DNS lookups, per RFC 7208. Go over, and the check returns a PermError — and a PermError means SPF effectively fails, no matter how carefully you built the record.

What counts toward the 10? Every include, a, mx, ptr, exists and redirect mechanism. The trap is that it's recursive. One include:_spf.google.com isn't one lookup — it's one, plus every lookup inside Google's record, plus everything inside those. A single include from a big provider can quietly eat three or four of your budget on its own.

I've audited records that looked completely reasonable — five or six includes, nothing obviously wrong — that were sitting at 13 or 14 actual lookups once you followed every nested record. The owner had no idea SPF had been failing for months.

There's a second, sneakier cap too: no more than 2 "void" lookups — DNS queries that return nothing (NXDOMAIN or no records). A stale include pointing at a provider you've dropped can burn through that limit and trigger a PermError by itself.

The cruel part is the same pattern as so much of email auth: it fails silently. Nothing bounces at your end. Your mail just starts landing in spam or getting rejected downstream, and unless you're reading DMARC reports or actively checking, the first sign is a customer saying "I never got your email."

How to get back under the cap

If you're over 10 (or close), here's the order I work in:

1. Count your real lookups. Don't eyeball it — a checker that recursively resolves the record will tell you the true number. You often find you're closer to the edge than you'd guess.
2. Remove senders you no longer use. The most common fix is deleting the include for a tool you stopped using two years ago. Dead includes are pure waste — and a removed provider's record can become a void lookup.
3. Drop unnecessary a and mx mechanisms. Plenty of records carry an a or mx that authorizes the domain's own web/mail host when nothing actually sends from there. Each one is a lookup you may not need.
4. Replace a stable provider with its IP ranges. If a sender publishes fixed ip4/ip6 ranges, listing those directly costs zero lookups (IP mechanisms don't count). Only do this for senders whose IPs genuinely don't move.
5. Delegate high-volume senders to a subdomain. Send your marketing blasts from news.yourdomain.com with its own SPF record and its own 10-lookup budget, separate from your main domain.

You'll see "SPF flattening" recommended a lot — tools that resolve all your includes down to a flat list of raw IPs so the record only ever needs one lookup. It works, but understand the tradeoff before you commit: you've swapped a lookup problem for a maintenance problem. The moment Google or your ESP changes their sending IPs, your flattened record is wrong and you won't know until mail breaks. If you flatten, you need something keeping that list fresh automatically — a static flattened record is a time bomb.

One record, and watch the From alignment

Two more things that trip people up. First: you get exactly one SPF record per domain. Publish two v=spf1 TXT records and that's an instant PermError — merge them into one. Second: SPF authenticates the hidden "envelope" sender (the Return-Path), not the From address your recipient sees. That's why SPF alone can't stop spoofing, and why DMARC exists — DMARC ties the SPF result back to the visible From domain. SPF is necessary, but it's one leg of a three-legged stool.

If you're a sender covered by the Google and Yahoo bulk-sender rules, SPF passing and aligned isn't optional — it's a requirement for getting into the inbox at all.