How to Check SPF Lookup Count and Why the Ten-Lookup Limit Matters

Across Melbourne boardrooms and Brisbane back offices, plenty of Aussie admins still treat the Sender Policy Framework as a set-and-forget checkbox. Then one arvo a transactional email bounces, a customer phones in grumbling, and someone realises the SPF record has quietly crept past the ten-DNS-lookup ceiling. The rule comes straight from RFC 7208 §4.6.4, and it is enforced silently by receiving servers — there is often no warning email, no cheerful alert, just failed delivery.

When an SPF check involves more than ten mechanisms that trigger a DNS query, the result is a hard fail known as PermError. The sending domain stays technically valid, but authentication collapses. For Australian businesses running their own marketing platforms, this often shows up as missing invoices, undelivered OTP codes, or newsletter bounces during peak periods. Understanding how to count those lookups — and slim them down — keeps deliverability humming along the NBN-fed networks most local firms rely on.

What Counts as a DNS Lookup in an SPF Record

Every SPF mechanism that resolves through the DNS costs one lookup. The include, a, mx, ptr, exists, and redirect mechanisms all ask the DNS for an answer, and each one counts. Mechanisms like all, ip4, and ip6 are evaluated locally and do not consume a query budget.

The clever bit — and the trap — is that an include statement pulls in another SPF record, which can itself contain more include statements. A record starting with v=spf1 include:_spf.google.com include:mail.zendesk.com include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.atlassian.net already burns five lookups on its own. Resolve each of those in turn, count the nested ones, and a Sydney-based SaaS business can easily blow past the limit without realising it.

Why Ten Is the Magic Number

The RFC authors picked ten because most DNS implementations struggle beyond that. Resolvers cache aggressively, but the moment a chain stretches into a dozen queries, recursion time rises, timeouts become likely, and receiving servers may simply give up. Under those conditions, the verification returns PermError rather than pass or fail.

For Australian senders governed by the .au Domain Administration (auDA) rules and watched over by the Australian Cyber Security Centre, the practical impact is harsher than for overseas-only operators. If an authentication check fails on an email purporting to come from a bank's domain, ACMA and ACSC guidance pushes receivers toward treating the message as suspect, which feeds scam-tracking services like Scamwatch. A broken SPF record therefore costs you inbox placement and may also drag a brand into the orbit of fraud reporting.

Signs Your SPF Record Has Too Many Lookups

You will rarely get an error message stating "you used twelve lookups". The symptoms are softer and easier to miss. Open rates dip without a clear cause. Transactional messages land in junk while marketing mail keeps flowing. The receiving server is not punishing you for content — it is silently rejecting the authentication result.

Another tell is uneven delivery between regions. Australian recipients on Telstra- or Optus-hosted inboxes sometimes still pass through cached results, while overseas Microsoft 365 tenants, which strict-fail more aggressively, start rejecting outright. If your IP blocklist check routine comes back clean yet delivery is still patchy, an SPF lookup overrun is a prime suspect.

How to Count and Audit Your Lookups

Manual counting is tedious but reliable. Start at v=spf1, walk each mechanism in order, and tally one for every include, a, mx, ptr, exists, or redirect. Open each included domain, repeat the walk, and keep adding. If you reach eleven before you finish, the record is over budget.

There are smarter ways. The domain admin tool on Trusted Sender Score parses an SPF record and reports the lookup count alongside DMARC and DKIM status, which spares you the manual tally on a Friday arvo when you would rather be at the pub. mxtoolbox.com's SPF record check and Kitterman's online SPF decoder offer similar services. Whichever you pick, run the audit after every change to your sending infrastructure — a new marketing automation platform or an extra ticketing system can quietly add two or three lookups in one sitting.

Streamlining and Fixing an Overloaded SPF Record

The cleanest fix is consolidation. Replace multiple include statements for the same vendor with a single include, where the vendor supports it. Microsoft 365, for example, lets customers use one consolidated include rather than several regional ones. Remove any include pointing to a service you no longer use — old survey tools, lapsed CRM trials, defunct event platforms all leave DNS footprints.

For a domain that genuinely needs more than ten lookups, the industry workaround is an SPF flatten — a service that replaces nested includes with a flat list of ip4 and ip6 ranges. Vendors such as Sendmarc, AutoSPF, and even self-hosted scripts can rewrite the record automatically. After flattening, re-run your audit and confirm the lookup count sits comfortably below ten. It is a fair dinkum five-minute job that saves hours of chasing mysterious bounces next week.