Vendor Stacking and the SPF Lookup Limit: Why Enterprise Email Breaks

Vendor stacking overview:

SPF only protects senders explicitly listed in the record, and RFC 7208 caps it at 10 DNS lookups.
Exceeding that limit produces a PermError, which most receiving servers treat as an authentication failure.
Vendor stacking, not vendor count, is the main driver of lookup-limit breaches.
Fixing a record near the limit means auditing usage, replacing includes with direct IPs, and using subdomains.
No single validator’s count should be trusted; manually trace the full include chain to confirm your real total.

You have added an SPF record to your DNS. You have included your email provider, your CRM, and your marketing platform. From the outside, it looks complete. But if your record doesn’t account for the 10 DNS lookup limit, you may have already exceeded it.

SPF is a foundational email authentication control. However, its hard limits and implementation complexity mean most organizations deploy it incompletely.

This post covers how SPF works, how exceeding the 10-lookup limit causes real failures, how vendor stacking pushes records past it, and how to redesign your include chain.

What SPF Does (and Doesn’t) Protect Against

SPF is a DNS-based email authentication protocol. A domain owner publishes a TXT record that lists the servers authorized to send email on behalf of that domain.

When a receiving server gets a message, it checks whether the sending IP matches the domain’s SPF record. If it does, the check passes. If it doesn’t, the receiving server handles the message based on your DMARC policy.

SPF only protects what’s explicitly listed. If a sending service doesn’t have an SPF entry, its messages fail SPF, regardless of whether you legitimately use that service. For an audit, this means checking the record’s syntax isn’t enough. You also need to confirm exactly which senders it’s authorizing.

The 10-Lookup Limit

RFC 7208, the standard that defines SPF, sets a hard limit of 10 DNS lookups per SPF evaluation. This limit applies to mechanisms that require DNS lookups: include, a, mx, and exists. Mechanisms like ip4 and ip6 don’t consume lookups.

When a receiving server evaluates your SPF record and hits the 10-lookup limit, the result is a PermError. Most receiving servers treat it as an authentication failure.

Consider this SPF record:

Host	Type	Value
`@`	`TXT`	`v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.mandrillapp.com include:servers.net include:mail.zendesk.com include:spf.salesforce.com -all`

The record contains 7 include mechanisms. Each include triggers at least one DNS lookup, and an include chain can nest further lookups.

This is the vendor-stacking problem.

How Vendor Stacking Damages Your SPF Record

Enterprises typically send messages from many sources: A primary email server, a marketing automation platform, a CRM, a transactional service, and possibly several regional or departmental tools added over time. Each vendor requires an SPF entry, typically an include mechanism, pointing to their SPF record.

The problem isn’t the number of vendors. The problem is that each vendor controls their own SPF infrastructure and optimizes it for their needs, not yours. Vendors add and change IP ranges, and their nested include chains expand over time. You have no visibility into those changes unless you audit regularly.

The operational consequence: A record that resolves within the 10-lookup limit at deployment can exceed it months later, when a vendor updates their own SPF infrastructure.

The record itself never changed – vendor stacking did the damage from the outside.

SPF Fixes: Redesigning Your `include` Chain

For businesses already near the 10-lookup limit, the fix for vendor stacking isn’t to add more includes. Each step below works toward the same outcome: A production-ready SPF record that holds up as vendors change their infrastructure.

Audit what you actually use. Pull your DMARC aggregate reports and identify every sending source that’s passing SPF, then check how each one affects your overall lookup count. Remove stale SPF entries for services you no longer use. Legacy vendors and deprecated platforms often remain in SPF records long after they’re decommissioned.
Replace your include chain with direct IP ranges where possible. If a vendor sends from a stable, documented set of IPs, replace their includes with ip4 or ip6 mechanisms. This eliminates lookup cost for that sender and lowers your overall lookup count.
Use subdomains for specific sending services. If your primary domain record is near capacity, delegate transactional or marketing emails to a subdomain. Each subdomain can have its own SPF record with its own 10-lookup budget.
Validate after every change. After updating your record, run a full lookup count. Do not rely on just one validator’s number. Open every include by hand, see what it points to, and count each lookup it adds, including any nested include inside it.

How Sendmarc Helps

Managing SPF at scale, across multiple domains, and sending vendors requires visibility that DNS inspection alone doesn’t provide. Sendmarc’s SPF Optimization feature continuously monitors every domain’s SPF record and automatically flattens nested includes into direct IP addresses, neutralizing vendor stacking and keeping the record within the 10-lookup limit even as vendors change their infrastructure.

Sendmarc tracks every nested include and every vendor change that could shift your lookup count, so your domains stay protected as your sending environment evolves.

Explore Sendmarc’s SPF management capabilities.