SPF in Depth: The 10-Lookup Limit and Common Mistakes

Most guides explain what an SPF record is and give you a one-line example. This article is about what goes wrong afterwards. SPF has a strict limit on how many DNS lookups a receiving server will perform, and a record that exceeds it fails outright, often without anyone noticing until mail starts landing in spam. If you have added several sending services over the years, check your record now.

A short reminder of how SPF works

SPF, the Sender Policy Framework, is a TXT record on your domain that lists which servers may send mail using it. When a message arrives, the receiving server looks at the envelope sender (the "return-path" domain), fetches that domain's SPF record, and checks whether the connecting IP address is allowed. The record ends with a qualifier that says what to do with everything else.

v=spf1 ip4:203.0.113.10 include:_spf.example-mail.net -all

The address above is from a range reserved for documentation. Replace it with your own details.

The 10-lookup limit

The SPF specification limits the number of DNS-querying terms to 10 per check. The mechanisms and modifiers that count are:

• include
• a
• mx
• ptr (which you should not use at all)
• exists
• redirect

The ip4, ip6 and all terms do not cost a lookup. The catch is that include is recursive. If you include a provider, and that provider's record includes three more, all of those count towards your 10. When the limit is exceeded, the result is a permanent error (permerror), which receivers treat as a failed SPF check, even if the sending IP was in fact listed.

There is also a limit of two "void" lookups, meaning lookups that return no data. A record with several includes pointing at hostnames that no longer exist can trigger that limit as well.

How records grow past the limit

A typical small business slowly accumulates services: the mail host, a newsletter service, a CRM, a helpdesk, an invoicing tool, a form handler. Each one tells you to add its own include. A few years later the record is over the limit. Because the failure shows up as occasional spam placement rather than an obvious error, nobody connects it to DNS.

How to count your lookups

1. Write down every include, a, mx, exists and redirect in your record.
2. For each include, look up that domain's own TXT record and count the same terms inside it, repeating for nested includes.
3. Add them all up. More than 10 means you have a problem.

Free online SPF checkers do this automatically and are the quickest option. Re-check whenever you add a service, because providers can change their own records without telling you.

Ways to get under the limit

Remove what you no longer use

Old services are the easiest saving. If you cancelled a tool two years ago, delete its include.

Replace mechanisms with IP ranges

If you control a server, writing ip4: terms directly costs no lookups. Do this only for IPs that rarely change. For third-party services whose IPs change, flattening by hand is risky because your record becomes stale.

Use a subdomain per service

Many services can send from a subdomain such as news.example.com. That subdomain gets its own SPF record with its own 10-lookup budget, and keeps the main domain simple.

Use an SPF management service

Some commercial services keep a flattened record updated automatically. This helps, but it adds a dependency, so weigh it against simply reducing the number of senders.

Other frequent SPF mistakes

• Two SPF records. A domain must have only one TXT record beginning with v=spf1. Two records cause a permanent error. Merge them into one.
• Syntax slips. Missing spaces, a stray quote, or a typo in an include: hostname. Always re-test after editing.
• Forgetting the ending. Without -all or ~all, the record does not state what to do with unlisted senders.
• Using +all. This allows anyone to send as you and makes the record pointless.
• Using ptr. It is slow, unreliable and discouraged by the specification.
• Assuming SPF protects the visible From address. SPF checks the envelope sender. DMARC is what ties the result to the From domain, through alignment.
• Breaking on forwarding. When mail is forwarded, the forwarder's IP is not in your record, so SPF fails. DKIM usually survives forwarding, which is why you need both.

Choosing between -all and ~all

Ending	Meaning	When to use
-all	Fail: unlisted senders are not authorised	When your record is complete and verified
~all	Softfail: unlisted senders are suspicious	While you are still discovering all senders
?all	Neutral	Rarely useful

With DMARC in place, many receivers treat both endings similarly, so correctness matters more than the choice between the two.

SPF on Zebra Hosting

For mailboxes hosted with Zebra Hosting, the SPF record you need is straightforward, and support in 17 languages can review it with you when you add third-party senders. See the email plans, or read about the full setup in our knowledge base.