SPF's 10-Lookup Limit: What It Is and How to Stay Under It

Why SPF Has a DNS Lookup Cap

The SPF specification (RFC 7208) imposes a hard limit of ten DNS lookups during evaluation of a single SPF record. The limit exists to prevent resource exhaustion on receiving mail servers—but it catches a surprising number of legitimate senders off guard. Exceed it and your SPF check returns permerror, which many mailbox providers treat as a hard fail. That means no SPF pass, a weakened DMARC alignment result, and mail that looks unauthenticated to every receiving server that checks.

What Counts as a Lookup

Not every SPF mechanism triggers a lookup. The ones that do:

• include: — one lookup per include, plus all lookups inside the referenced record
• a: — one lookup
• mx: — one lookup, plus one per MX hostname returned
• ptr: — one lookup (and also deprecated; don't use it)
• exists: — one lookup
• redirect= — one lookup

Mechanisms that do not count toward the limit: ip4:, ip6:, and all. That's why ip4: ranges are the safest way to authorize sending IPs when you control the infrastructure directly.

How You Blow Past 10 Without Noticing

A typical mid-size company might have an SPF record that looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.zendesk.com include:mktomail.com include:_spf.salesforce.com ~all

That's six include: statements. Each third-party SPF record chains into further includes. Google's SPF record alone can consume three or four lookups by the time it resolves all its nested includes. Add Salesforce, Marketo, and Zendesk, and you're well over ten. The result: permerror, and none of your sending services pass SPF.

You can test your current count with any SPF validation tool. Run:

dig TXT yourdomain.com

Then paste the result into a validator—it will tell you exactly how many lookups your record costs.

Three Ways to Get Back Under the Limit

1. Remove Stale Includes

Audit every include: in your record. Ask: does this service still send mail on our behalf? Old ESPs, CRMs you've migrated away from, and abandoned marketing tools often linger in SPF records for years. Removing a single stale include can recover two to four lookups.

2. Replace Includes With ip4: Ranges

If you know the exact IP ranges your ESP uses, you can drop their include: and publish the IPs directly. For example, instead of include:sendgrid.net, you would add the static IP blocks SendGrid documents for your account. This trades one lookup-heavy include for zero-lookup ip4: entries. The downside: you need to update your record if the provider changes their IP ranges.

3. SPF Flattening

SPF flattening resolves all the includes in your record down to their final IP addresses and rewrites the record as a flat list of ip4: and ip6: entries. The record goes from a chain of nested lookups to a single DNS query with no further recursion needed.

A flattened version of the example above might look like:

v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip4:149.72.0.0/16 ip4:136.143.0.0/16 ip4:192.254.112.0/20 ~all

The tradeoff: flattened records go stale. When your providers rotate their IPs, your record no longer covers the new addresses. You either maintain it manually or use a dynamic flattening service that auto-updates the record when upstream ranges change.

The ~all vs -all Question

While you're editing your SPF record, pay attention to the trailing qualifier. ~all (softfail) marks unmatched senders as suspicious but still delivers the mail. -all (hardfail) instructs receiving servers to reject mail from unauthorized IPs. If you have a solid DMARC policy in place, -all is the more assertive choice—but only after you're confident your record covers every legitimate sender.

The Relationship Between SPF and DMARC

A permerror on SPF doesn't automatically mean your mail is rejected—it depends on whether DKIM passes and how your DMARC policy is configured. If DKIM alignment succeeds, DMARC can still pass even with a broken SPF record. But relying on DKIM as your only authentication path is fragile. Fixing the SPF lookup count ensures you have two independent authentication mechanisms working, which is the more resilient setup.

If you're uncertain about your current authentication posture, the MailDog DNS security checker will validate your SPF, DKIM, and DMARC records in one pass and flag any lookup overflows. For a broader look at how authentication failures contribute to deliverability problems, see our guide on why emails land in spam.

Quick Reference: SPF Lookup Budget

• Total allowed lookups: 10
• Exceeding the limit: returns permerror (treated as fail by most providers)
• Safe mechanisms (no lookup cost): ip4:, ip6:, all
• Most expensive includes: Google Workspace, Microsoft 365, Salesforce, Marketo
• Fix priority: remove stale includes first, then flatten if still over limit

Keeping your SPF record clean is an ongoing task—every new SaaS tool you add for email is another potential include. Treat it like a dependency list: audit it quarterly and remove anything you no longer use. A lean SPF record is a reliable SPF record.