Guides

When SPF needs too many DNS lookups

SPF fails at large receivers once the record needs more than 10 DNS lookups. The count includes nested includes, not just the names you typed.

The limit is 10 lookups, not 10 names

An SPF record can name many senders and still be invalid. Receivers that follow the SPF specification stop after 10 DNS lookups that count. Include, a, mx, ptr, exists, and redirect count. Nested includes count too. A single include: from a marketing tool can itself include three more hosts. ip4: and ip6: do not need a lookup, so they do not add to the count.

Gmail and Microsoft treat a record over the limit as a permerror. The message fails SPF even though every company on the list is one you pay. InboxMonitor marks more than 10 lookups as critical and subtracts 25 points. At 8, 9, or 10 it subtracts 6 and files a warning, because the next tool you add can break the record.

How a record grows past the limit

The usual path is accumulation. The domain started with Google Workspace or Microsoft 365. Someone added a newsletter tool, then a cold-email tool, then a CRM, then a support desk, then a billing system that sends receipts. Each vendor's document says to paste one include:. Nobody recounts the nested lookups. Two SPF TXT records on the same name are a separate failure: publish one record.

You can see the walk in InboxMonitor and on the free SPF checker. The lookup count is the number that matters, not the number of words in the TXT string. A short-looking record can be over the limit. A long list of ip4: mechanisms can be under it.

What to remove first

List every service that still sends as the domain this month. Remove includes for tools you cancelled, trials you abandoned, and vendors who now send from their own domain. Check with the person who owns the CRM and the person who owns billing before you delete their include. A missing include does not bounce inside your DNS host. It fails SPF at the receiver.

If you still need every remaining vendor, ask each one whether they offer a flattened include or a dedicated ip4 range. Flattening copies their mechanisms into a record that does not nest as deeply. It goes stale when they change addresses, so treat it as something you review, not a one-time paste. Putting a vendor's current IPs in ip4: mechanisms also avoids lookups, with the same staleness.

Do not 'fix' the count by ending the record in +all. That authorizes every host and costs 22 points as a critical finding. End with ~all while you confirm the list, or -all when you are sure.

After you publish

Edit the one TXT record, wait for your DNS host to publish it, and run the check again. The lookup count should be 10 or under, and ideally not sitting on 10 if you expect to add another tool. InboxMonitor will clear the critical finding on the next daily check when the walk succeeds. The warning at 8 to 10 stays until you have more room.

If the walk errors partway, the check may show that SPF did not finish rather than a clean count. That costs 6 points. Run it again. A provider host that is down, or a chain that times out, is not the same as being over the limit.

InboxRescue can write the replacement record and the provider steps if you do not want to edit the include chain yourself. The Audit is a written report. The Fix plan adds the change steps. Neither one can make a receiver ignore the 10-lookup rule, and neither promises inbox placement.

Also: What the InboxMonitor score is counting · SPF, DKIM, and DMARC in plain English