The ten-lookup problem

SPF is the oldest of the three email authentication mechanisms and the one most firms assume is simply done. It is a single DNS record listing the servers permitted to send mail for a domain. It is also the mechanism most likely to be silently broken, because of a limit written into the standard that almost nobody tracks.

The limit

Evaluating an SPF record can require the receiving server to perform DNS lookups: every include, a, mx, exists, and redirect mechanism costs one, and lookups nested inside an included record count against the same budget. The specification caps the total at ten. Past ten, the receiving server stops evaluating and returns a permanent error. The standard is explicit that this is a hard boundary, not a suggestion.

What failure looks like

Nothing. That is the problem. A record over the limit does not bounce mail on its own, produce a warning, or notify anyone. Mail generally continues to flow, carried by DKIM or by receiving servers’ tolerance, and the domain’s owner has no signal that one of their three authentication mechanisms has stopped functioning. The failure becomes material at exactly the wrong moment: during DMARC enforcement, when authentication results begin determining delivery, a firm can discover that the SPF record it has trusted for years returns an error for every message.

How records drift over the limit

No one writes a broken SPF record on purpose. They accumulate. Each new service, the email platform, the marketing tool, the invoicing system, the e-signature vendor, the helpdesk, instructs the firm to add our include and each include may carry nested lookups of its own. A record that started at three lookups in 2018 sits at eleven in 2026, and the change that broke it was adding a perfectly legitimate vendor. In our scanning across title and escrow domains, over-limit SPF records appear regularly, always at firms with no idea anything is wrong.

Getting back under

Three approaches, in ascending order of maintenance cost. Prune: most over-limit records contain includes for services the firm stopped using years ago, and removing them is free. Delegate: move high-lookup senders to a subdomain with its own record. Flatten: replace includes with the IP ranges they resolve to, which buys headroom at the price of owning every future change those vendors make to their ranges. Flattening without a maintenance plan trades a visible problem for an invisible one.

The check takes thirty seconds

Any SPF evaluation tool will count lookups for a domain and name the mechanisms responsible. It is worth running annually and after every new sending vendor, because this is the one authentication failure that produces no symptoms until the day it matters.

Most over-limit records can be repaired in an afternoon by whoever manages the domain. If your firm would rather have the whole authentication stack handled, that is what we do.