Email Authentication

The SPF 10-Lookup Ceiling Is Quietly Forcing MSPs to Rearchitect Client Domains

October 6, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

Every MSP that manages a client's DNS has run into the same wall eventually: an SPF record that looks perfectly reasonable on screen, yet quietly fails the moment a receiving mail server tries to evaluate it. The culprit is almost never a typo. It is a hard limit written into the SPF specification itself, one that was reasonable in 2014 and is increasingly out of step with how many vendors a single client now uses to send mail.

In short, the SPF 10-lookup ceiling caps how many DNS-querying mechanisms, such as include and a, a receiving mail server may follow while checking one domain's SPF record. Cross that limit and the check returns a permanent error rather than a pass or fail, silently blocking legitimate mail from every vendor listed after the tenth lookup.

What Is the SPF 10-Lookup Limit, and Where Does It Come From?

The limit comes straight from the protocol document that defines SPF. RFC 7208 states that SPF implementations must cap the number of DNS-querying mechanisms in a single evaluation at ten, and if that limit is exceeded the check must return a permanent error. The mechanisms that count toward the cap are include, a, mx, ptr, and exists, along with the redirect modifier, while ip4, ip6, and all mechanisms do not require a lookup and are free.

That distinction matters because most client domains do not blow the limit with IP ranges. They blow it with include statements, one for every marketing platform, help desk, CRM, and payroll provider that has ever been told to "just add this to your SPF record." Ten include-driven lookups sounds generous until a domain is routing mail through Microsoft 365, a marketing automation tool, a CRM, a support desk, and a payroll processor, each with its own nested includes.

Why Is This Suddenly an MSP Problem?

It is not new, but the pressure behind it has changed. Two forces are converging: SaaS sprawl inside client organizations, and the fact that major inbox providers now punish authentication failures more visibly than they used to. Both make a record that has quietly exceeded ten lookups far more costly than it was five years ago.

The first force is simply the number of tools a typical business now uses to send mail on its own behalf. Every new platform a client adopts, from a help desk to a scheduling tool to an e-signature service, typically comes with instructions to add its domain to the SPF record. Each addition is often a single include line, but that line can itself expand into two, three, or more nested lookups once the receiving server resolves it, which is exactly the kind of silent multiplication that pushes long-standing domains past the ceiling without anyone touching the record in months.

The second force is enforcement. Starting in February 2024, Google and Yahoo began requiring bulk senders to authenticate mail with SPF and DKIM and to have DMARC in place, a shift that Sinch Mailgun's 2025 State of Email Deliverability research found prompted roughly half of aware senders to make concrete changes to their email programs. The same research recorded a jump in DMARC adoption from 42.6% of senders in 2023 to 53.8% in 2024. As more domains move DMARC policy from monitoring to enforcement, an SPF record that silently permerrors stops being a theoretical problem and starts bouncing real customer mail.

How the Ceiling Breaks Without Anyone Noticing

An SPF permerror is not a gradual degradation. It is binary: once a domain crosses ten lookups, receiving servers are supposed to treat the whole SPF check as a permanent error rather than partially trusting it, per the same evaluation rules in RFC 7208. That means every mechanism after the tenth is irrelevant, including the fallback most administrators assume is protecting them.

Void lookups compound the problem. Guidance from Google Workspace on SPF records notes that a TXT record for SPF should not include more than 10 references to other domains or servers, and separate best-practice discussions of the spec point out that DNS queries returning no answer still count against the budget. A stale include pointing at a decommissioned vendor does not just sit there harmlessly. It consumes part of the same ten-lookup allowance as the includes that are actually delivering mail today.

Microsoft's own documentation for Microsoft 365 domains is direct about the ceiling. Microsoft Learn's guidance on external DNS records states that a domain can only have one SPF record, and the total DNS lookups that record triggers cannot exceed ten, a limit framed explicitly as protection against denial-of-service load on the DNS system. That framing is a reminder that the limit was never about email deliverability in the first place. It exists to protect DNS infrastructure, and email authentication has to live within that constraint whether or not it is convenient.

Is SPF Flattening the Right Fix?

Flattening, which replaces include mechanisms with the literal IP addresses they resolve to, does bring a record back under ten lookups, but it is not a permanent fix and it introduces a new maintenance burden of its own. A flattened record has to be re-flattened every time one of the underlying vendors rotates its sending IPs, and if that update is missed, mail from a legitimate provider can start failing SPF for reasons that have nothing to do with the record's syntax.

That trade-off is precisely why more MSPs are treating this as an architecture decision rather than a one-time cleanup. Some consolidate multiple client tools behind a single subdomain dedicated to third-party senders, isolating the blast radius so that a vendor change does not risk the primary domain's deliverability. Others push vendors to support DKIM-only authentication where SPF alignment is optional, reducing how many includes the root domain actually needs to carry.

The practical options MSPs are weighing generally fall into a short list:

• Auditing every include for vendors the client no longer uses and removing them before adding anything new.
• Delegating third-party sending to a dedicated subdomain so the root domain's SPF record stays lean.
• Automating flattened records with monitoring that catches IP changes before they cause silent permerrors.

None of these is a substitute for visibility. An MSP managing SPF across dozens of client domains cannot reasonably hand-count lookups every time a client signs up for a new SaaS tool, which is the operational gap that domain-scanning tools are built to close by flagging a record before it crosses the threshold rather than after a client calls about bounced invoices.

What This Means for MSP Service Delivery

The shift underway is less about SPF syntax and more about how MSPs price and scope domain security work. A client with five SaaS integrations is a fundamentally different SPF maintenance job than the same client after two years of platform adoption, and flat-fee engagements that do not account for that drift tend to lose money on exactly the accounts that need the most attention.

Firms that have started treating SPF lookup budgets as a recurring line item, checked on the same cadence as certificate expirations or DNS record audits, are the ones avoiding the emergency calls when a client's newsletter platform suddenly stops landing in inboxes. That is also why more MSPs are formalizing the check as part of onboarding rather than an afterthought. Teams building this into their process from scratch can walk through the setup in the getting-started guide, which covers how to baseline a client's existing lookup count before adding anything new.

For MSPs weighing whether to bring this in-house or keep patching records manually across a growing client list, the calculus increasingly comes down to scale. A shop with a handful of domains can track lookups by hand, but one managing dozens or hundreds is better served by continuous scanning, and the pricing page lays out how that cost compares to the billable hours spent untangling a permerror after the fact. Firms that want to see how their current client domains stack up against the ten-lookup ceiling can create an account through the signup page and run a baseline audit before the next SaaS renewal cycle adds another include nobody planned for.

The 10-lookup ceiling is not going away, and neither is the push toward stronger email authentication for the organizations MSPs serve. CISA's Binding Operational Directive 18-01 already requires federal agencies to set a DMARC policy of reject, a posture that depends on SPF actually resolving correctly rather than silently erroring out, and that same enforcement logic is spreading to commercial inbox providers. Domains that were built one include at a time, without anyone tracking the running total, are the ones most exposed as that enforcement tightens.