Webmaster & Network·3 min read

Fixing SPF: The 10-Lookup Limit and Other Silent Failures

SPF records rarely break on the day they are written. They break a year later, when someone adds one more include for a new newsletter tool, a helpdesk or a payroll service, and the record quietly crosses a limit that nobody was counting. Mail keeps flowing, but receivers start treating every message as unauthenticated. This guide explains how SPF is evaluated, why the limit exists and how to get back under it without guesswork.

Open the free SPF Record Checker All insights

How receivers read an SPF record

Left to right, first match wins.

An SPF record is a TXT record that starts with v=spf1 and lists the servers allowed to send mail for your domain. When a message arrives, the receiving server takes the sending IP address and walks through the record from left to right. ip4 and ip6 terms match addresses directly. a and mx match the addresses of your own web and mail servers. include hands the question to another domain's SPF record, and all matches everything left over.

The first term that matches decides the result, and its qualifier sets which one: pass for a plain or + term, fail for -, softfail for ~ and neutral for ?. If nothing matches and there is no all, the result is neutral, which protects nothing.

The 10-lookup limit, counted properly

Includes inside includes count too.

To stop SPF checks from turning into a flood of DNS traffic, the standard caps each evaluation at 10 DNS lookups. Every include, a, mx, ptr, exists and redirect costs one, and so does every such term inside the records you include. ip4, ip6 and all cost nothing. Go over 10 and the receiver stops with a permanent error, which most treat the same as a failed check.

The trap is that the count is invisible in the record itself. include:_spf.google.com looks like one lookup, but Google's record includes several more. SPF Record Checker follows every include and redirect, shows the total against the limit of 10 with a coloured bar, and draws the whole include tree with a lookup count on each branch, so you can see at a glance which service is using up your budget.

A worked example: one include too many

Seven services, eleven lookups.

A growing company's record reads: v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net include:spf.protection.outlook.com a mx ~all. It looks tidy. The checker counts 11 lookups: one for each include, the lookups nested inside some of them, plus one each for a and mx. The result for every message is a permanent error.

The tree shows the culprits. Microsoft 365 is left over from a trial nobody finished, so that include goes. The a mechanism covers a web server that has never sent mail, so it goes too. The count drops to eight, the bar turns amber, and a test of a Google sending IP in the Test a sending IP box now returns pass, decided by include:_spf.google.com.

Ways to cut lookups safely

Work through these in order, from safest to most maintenance:

Remove includes for services you no longer use. Old trials and replaced tools are the most common source of wasted lookups.
Drop a and mx if those servers never send mail, or replace them with ip4 ranges if the addresses are fixed.
Move bulk senders such as newsletter or ticketing platforms to a subdomain, for example news.example.com, with its own SPF record and its own 10-lookup budget.
Flatten only as a last resort. Replacing an include with the IP ranges it currently holds saves lookups, but the list goes stale whenever the provider changes its ranges. The checker's allowed IP ranges list shows what such a list would contain today.

Other silent SPF failures

Beyond the lookup count.

Two SPF records on one domain is the most common error after the lookup limit. It usually happens when a new service's setup guide says to add a record rather than edit the existing one. Receivers see two v=spf1 records and fail SPF for everything. Merge them into one.

Other problems the checks list flags: an include that points at a domain with no SPF record, which is also a permanent error; +all, which authorises the whole internet; mechanisms placed after all, which are never read; the deprecated ptr mechanism; and more than two lookups that return nothing. Before publishing any change, paste the draft into Test a record and check it the same way.

SPF is one third of the picture

Alignment decides what DMARC sees.

A clean SPF record is necessary but not enough. SPF checks the envelope sender, which many mailing services set to their own domain, so it can pass without proving anything about the From address people see. DMARC closes that gap by requiring SPF or DKIM to pass for your own domain. After fixing SPF, run DMARC Checker to see your policy and which DKIM keys are published, and use MX Lookup to confirm incoming mail still routes correctly after any provider change.