Skip to content
notspoofed.comSPF · DKIM · DMARC

Count your SPF DNS lookups

Enter a domain, or paste a draft record, and see where each of the ten lookups goes — and the exact term where a receiver would give up.

By · Published

What the 10-lookup limit is

An SPF record is a list of servers allowed to send mail for your domain, and a receiver checking it has to resolve every name in that list. To stop one message from triggering an unbounded chain of DNS queries, RFC 7208 caps the terms that cause a lookup at ten per evaluation. The count covers the whole tree: your record, every record it includes, and every record those include.

Reaching the eleventh is not a soft failure. The receiver stops evaluating and returns PermError, which DMARC treats as SPF not passing. A server listed before the limit may still pass at a receiver that stops at the first match; everything after it cannot. Nothing bounces to tell you, so the first sign is usually a DMARC report full of failures from a service you added last.

What counts, and what does not

Each of these costs one lookup, wherever it appears in the tree:

  • include: — plus everything inside the record it points to.
  • a and mx — one each, even though mx then resolves each mail server’s address. Those follow-on queries are capped separately at ten mail servers.
  • ptr — deprecated, slow, and ignored by some receivers, but still charged.
  • exists: — usually with a macro, so what it queries depends on the sender.
  • redirect= — a modifier rather than a mechanism, but it fetches another record and is counted like one.

These cost nothing: ip4:, ip6: and all. They are answered from the record itself, so you can list as many addresses as fit. The counter counts the worst case — every term evaluated — because the sender that breaks is the one whose address sits in the last include.

Void lookups: the second limit

A void lookup is one that comes back empty: the name does not exist, or it exists with no record of the type asked for. RFC 7208 allows two per evaluation. The third is a PermError on its own, however few lookups the record uses in total. Voids usually come from an include left behind for a service that has since shut down or moved its record, or an a: pointing at a retired hostname. The counter shows which term caused each one, so you know which line to delete.

Why flattening is a tradeoff

Flattening replaces an include: with the ip4: and ip6: ranges it resolves to today. Those cost no lookups, so the count drops by the include’s whole subtree. The catch is that the include was how the provider kept your record current. Once you copy their addresses, you are responsible for noticing when they change, and when they do, mail from their new servers fails SPF without warning.

So this tool treats flattening as the last resort. It removes includes that are already pulled in by another include first, because that costs nothing. Only then does it flatten, starting with the costliest include and stopping as soon as the count is legal. Everything else stays an include. Before you flatten anything, check your list for a service you no longer use. Removing its include is safer than any rewrite, and only you can know which one it is.

For the full walkthrough, see SPF: too many DNS lookups. To see SPF alongside DKIM and DMARC, with the record to publish, run the full checker.

Common questions

How many DNS lookups does SPF allow?
Ten per evaluation, counted across every nested include (RFC 7208 §4.6.4). The terms that count are include, a, mx, ptr, exists and the redirect modifier. ip4, ip6 and all cost nothing, so you can list as many addresses as fit in the record.
What happens when an SPF record needs more than 10 lookups?
The receiver stops at the eleventh and returns PermError instead of a pass or fail. DMARC treats that as SPF not passing, so any server authorised after that point stops passing SPF, and its mail fails DMARC unless DKIM passes. Nothing bounces to tell you: the failure only shows in DMARC reports.
Do nested includes count toward the limit?
Yes. include:mailgun.org costs one lookup, but Mailgun’s record includes two more, and one of those includes two more again, so that one line costs five. The limit applies to the whole tree, which is why a record with five includes can still be over. The counter above shows each include’s full cost.
Is SPF flattening safe?
It works on the day you publish it. The risk comes later: a flattened record lists a provider’s addresses as they were that day, and when the provider adds or moves servers, mail from the new ones fails SPF without warning. Flatten as few includes as you can, prefer providers whose addresses rarely change, and re-check monthly.