Your SPF Record Has a Speed Limit: Auditing the Include Chain Before It Breaks

SPF is one of those bits of email plumbing that feels solved right up until it isn't. You add a marketing tool, then a CRM, then a helpdesk, then a booking widget that insists it needs to send as your domain. Each vendor hands you an include: line. Each line looks harmless. And then one Tuesday your invoices start landing in junk folders while the weekly newsletter sails through.

The culprit is often the ten-DNS-lookup ceiling in SPF. It is not a suggestion, a soft limit or a warning sign. It is baked into the way SPF is evaluated, and when you cross it the record does not dramatically explode. It returns a permerror, which is exactly as friendly as it sounds.

Ten lookups sounds generous until you map the chain

SPF checks the envelope sender against a list of authorised senders. Simple records use ip4: and ip6: entries and ask DNS for almost nothing. The trouble starts with mechanisms that trigger extra DNS queries: include:, a, mx, ptr, exists and redirect. Each one can pull in another record, and that record can pull in another.

A typical UK SME record in 2026 might include a workspace provider, a newsletter platform, a CRM, a support desk, a payment reminder service and a charity fundraising tool. Six includes does not mean six lookups. It means six initial lookups plus whatever each vendor's _spf record contains. One provider may nest three more includes. Another may use a and mx mechanisms. Before long you are at eleven or twelve, and the whole record is invalid for receivers that enforce the limit strictly.

There is also the void-lookup limit to keep in mind. SPF allows a small number of DNS queries that return nothing useful, but repeatedly asking for records that do not exist can push you over a separate ceiling. It is another reason why a record that looks tidy in a web tool can behave badly in the wild.

The permerror nobody sees

A permerror is not a nice, visible bounce. It is a verdict that says the SPF record could not be evaluated properly. Some receiving systems treat that as no SPF at all and fall back to other signals. Others mark it as suspicious. A few may still accept the message because DMARC or reputation carries it. That inconsistency is what makes the problem so annoying: the same outgoing mail can be accepted by one recipient and quietly penalised by another.

For a UK charity sending donor updates or a small business sending invoices, this is not an abstract RFC issue. It means deliverability depends on which mailbox provider the recipient uses, which filtering stack sits in front of it and how much reputation your domain has banked. The record is broken, but the symptoms look random.

A practical audit you can do this week

Start by collecting the actual record from DNS, not from the screenshot a vendor sent you two years ago. Run it through a reputable SPF checker that reports the lookup count and shows the full include tree. Then make a simple table: vendor, purpose, include host, number of nested lookups, who owns the relationship and when it was last reviewed.

Next, look for redundancy. Two products from the same parent company may share an SPF include. An old helpdesk you stopped using in 2024 may still be in the record because nobody removed it. A booking tool may send through your CRM and not need its own include at all. Removing dead weight is the cheapest fix, and it is usually overdue.

If you are still near the ceiling, consider whether every sender really needs to use the same envelope domain. Marketing mail, transactional mail and helpdesk replies can often sit on separate subdomains, each with its own SPF record and its own reputation. That does not solve every alignment question, and it needs planning with DMARC, but it stops one noisy bulk sender from crowding out the rest.

Flattening is useful, but it is not a one-off

SPF flattening replaces nested includes with a static list of IP addresses. It can bring a monster record back under ten lookups, and for some organisations it is a sensible interim fix. The catch is maintenance. Vendor IP ranges change. Cloud senders add and retire addresses. A flattened record that nobody monitors is just a future deliverability incident with a tidy-looking DNS entry.

If you flatten, use a service or internal process that checks the underlying vendor records regularly and alerts you when they change. Keep a human-readable note of which vendor each range belongs to. Do not flatten once and forget it. And do not assume that a low lookup count means the record is correct; syntax errors, missing mechanisms and stale IPs can all cause trouble without breaking the ten-lookup limit.

Monitor before the next tool arrives

A monthly check is enough for most small teams, but the important moment is any change: a new CRM, a new newsletter platform, a new payment provider, a domain migration or a rebrand. Ask for the SPF include before the contract is signed, not after the first campaign. Count the lookups, check the void queries and confirm that the vendor is not asking you to authorise a shared range that also sends for thousands of other customers.

SPF is only one leg of authentication, so pair this with DMARC reporting and a sensible DKIM setup. But do not skip the lookup count. It is the quiet limit that can make a perfectly legitimate email look like a policy failure. In 2026, with more tools than ever wanting a piece of your domain, a ten-line SPF record is less of a configuration and more of a capacity plan.