Somewhere in the setup guide of nearly every platform that sends email on your behalf is the same instruction. Add this line to your DNS. One include, five minutes, a green tick at the end of the wizard. The instruction is accurate, the change is easy, and the guide is written as if this platform is the only one you will ever connect.
It never is, the CRM asked for a line when it went in, the booking system asked for one, the helpdesk and the newsletter tool. The accounting platform that sends invoices, the survey tool someone in marketing trialled in 2021 and never quite decommissioned. Each arrived years apart, each was added by whoever was looking after DNS that day, and each vendor's documentation carried the same quiet assumption of sole tenancy. Nobody was wrong but nobody was watching the total either.
The total is the problem, because this is one of the few places on the internet where complexity has a hard, enforced ceiling, and almost nobody contributing to it knows the ceiling exists.
The ceiling nobody mentions
The record all those instructions were editing is SPF, the DNS record that lists who is allowed to send email using your domain name. The standard that governs it, RFC 7208, sets a limit, evaluating a record may trigger no more than ten DNS lookups. Past ten, the receiving server is entitled to stop evaluating and return a permanent error. Your authorisation list stops being read at all, which means the servers receiving your mail can no longer confirm your own systems are allowed to send it.
What makes the limit dangerous rather than merely strict is that the counting is recursive. Every include in your record is an instruction to go and fetch another record, and whatever that record contains counts against your budget, not the vendor's. An include that looks like one line can conceal several more beneath it. One record we scanned carried five includes on its face and cost twelve lookups once the tree was expanded. A major email platform's include contains a further include inside it, so a business pays two lookups for what its setup guide described as one line. The record's real cost is invisible from its text, and the person adding line number six has no way of seeing they just spent the budget that line number three had already consumed.
So the ledger fills silently. Ten years of reasonable, individually correct five-minute changes, made by different people following different vendors' instructions, and no line item anywhere showing the running total against a limit none of the instructions mentioned.
The failure is quiet, and it aims at the busiest
Crossing the ceiling produces no bounce message to the sender, no dashboard alert and no invoice. Authentication simply starts failing at some receiving servers, and a share of legitimate mail starts landing in spam or vanishing. The business finds out the way one winery owner described it to me: customers kept missing the one email their subscription depended on, and nothing anywhere had announced a problem.
Notice who this failure affects the most. A dormant domain with one mail system never approaches the limit. The businesses that cross it are the ones running a modern marketing stack: the CRM, the campaign platform, the booking engine, the review tool. The limit punishes, almost precisely, the operators trying hardest to reach their customers. In our scanning this shows up as a pattern that has little to do with industry, the over-limit records belong to a recognisable business shape, the marketing-active operator stacking tools, whether it sells wine, houses, or book-keeping. In our most recent scan run, 99 of the 391 domains we checked were over the ten-lookup limit. One business in four.
We have also watched it happen in slow motion. One domain we scanned twice, months apart, went from about 14 lookups to about 22 with no visible change in the business. Vendors restructure their own records underneath yours, and your budget moves while your record's text stands still. The ledger updates itself even when nobody at your end touches anything.
The limit is not the villain
Here is the concession, because the limit is doing its job. Without a ceiling, a crafted SPF record becomes a machine for generating unbounded DNS traffic, and mail servers evaluating it become unwitting participants in denial-of-service attacks. The ten-lookup budget exists to keep a useful mechanism from being a weapon, and it succeeds. The standard is not badly designed.
The vendors are not villains either, at least not individually. Each instruction is correct in isolation, the failure lives in the gap between them, the sum has no owner. The CRM does not know about the booking system. The booking system's onboarding wizard cannot see your helpdesk's include. Every party optimises its own five minutes, and the one number that matters belongs to nobody.
Anyone who has watched a shared server accumulate agents, or a firewall accumulate rules, will recognise the shape. This is that story, with the unusual feature that the ceiling is written into an RFC and enforced by strangers.
The standard advice makes it worse
There is a well-known escape, and it is a trap. The internet's standard answer to a record over the limit is to flatten it. Resolve every include to its underlying IP addresses and publish those instead, spending zero lookups. The record passes evaluation the day you do it, the green ticks return, and the problem appears solved.
What it actually does is trade a visible failure for an invisible one. The addresses you pinned belong to the vendors, and the vendors' documentation is explicit that those addresses change. When they do, and they do, nothing tells you. Mail from the vendor's new addresses starts failing authentication, silently, weeks or months after the fix, and the record now contains a wall of raw numbers no future administrator can read or safely maintain. The visible failure at least prompted someone to look. The flattened record fails while looking healthy, which is actually worse.
Complexity budgets do not need your permission
The lesson generalises well past email. Every system carries complexity budgets, whether or not anyone administers them. Connection limits, dependency depth, rule counts, the finite attention of whoever inherits the configuration. Most are soft, so they degrade gracefully and let everyone keep not noticing. SPF's is hard, published, and enforced by every mail server on Earth, which makes it one of the rare places you can watch the general problem produce a specific, measurable failure.
The businesses affected by it did nothing unreasonable. They bought good tools, followed each vendor's instructions, and grew. The ceiling was published in 2014. Most of them will find it the same way, by accident, from the inside.
I read these records for a living. The text tells you what a business bought. The lookup count tells you what it cost.