The SPF 10-Lookup Limit: How Agencies Should Debug It

The SPF 10 lookup limit means an SPF check can fail if the receiving mail server has to perform too many DNS lookups while evaluating the sender's SPF record. For agencies, this usually happens when a client keeps adding SaaS senders to one domain: Google or Microsoft, a CRM, a newsletter tool, an ecommerce platform, a helpdesk, an invoicing system, and several old vendors nobody has removed.

The practical answer is not "make the SPF record longer." The answer is to identify which SPF mechanisms trigger DNS lookups, remove stale senders, avoid unnecessary nested includes, and move some services toward DKIM alignment where possible.

CertPilot's Inbox Pulse helps agencies audit email-authentication configuration across multiple client domains. It is not a full deliverability platform and it does not guarantee inbox placement, but it gives teams a faster way to spot domains that deserve a closer SPF review.

For broader SSL, DNS, and domain expiry checks, run a free 10-domain agency audit or use the single-domain health check.

SPF 10 lookup limit: the agency version

SPF lets a domain publish which servers are allowed to send mail for that domain. The record lives in DNS as a TXT record. During mail delivery, the receiver evaluates the SPF policy.

Some SPF mechanisms require DNS lookups. The important ones for agencies are:

| SPF mechanism | Counts toward the limit? | Agency note | |---|---:|---| | include: | Yes | Common for SaaS senders and often nested. | | redirect= | Yes | Sends SPF evaluation to another domain. | | a | Yes | Looks up A or AAAA records. | | mx | Yes | Looks up MX records and then related hosts. | | exists: | Yes | Advanced and easy to misunderstand. | | ip4: / ip6: | No | Direct IP ranges do not trigger DNS lookups. | | all | No | Sets the default result. |

The limit is evaluated by the receiver at message time. If evaluation exceeds the limit, SPF can return a permanent error. That can affect DMARC if the domain relies on SPF alignment.

Why agency-managed domains hit the limit

Agencies inherit messy DNS. A client's SPF record may represent years of marketing experiments, vendor migrations, and emergency fixes.

Common causes:

• A client moved from Mailchimp to Klaviyo but kept both includes.
• The CRM was replaced but the old include remains.
• Google Workspace or Microsoft 365 was added alongside several website plugins.
• An ecommerce app, helpdesk, booking tool, and invoicing system all send mail.
• A previous vendor used include: where DKIM setup would have been better.
• The SPF record includes another domain that includes several more domains.

The record can look reasonable at a glance and still fail because nested includes expand behind the scenes.

This is why agencies need a repeatable process. Use Inbox Pulse to find domains with risky email-authentication posture, then inspect the SPF chain for the domains that actually send mail.

Includes are the usual source of trouble

The include: mechanism tells receivers to evaluate another domain's SPF policy as part of the current one.

Example:

v=spf1 include:_spf.google.com include:send.example.net include:mail.vendor.test ~all

Each include can trigger more DNS work. The included domain may include other domains. That nesting is where the count can grow quickly.

For an agency, every include should map to a known sending service. If nobody can explain why the include exists, it belongs in the review queue.

Use this checklist:

• Which service owns this include?
• Is the client still using that service?
• Does that service send from this exact domain?
• Does the service support DKIM alignment instead?
• Is the include documented in the client account notes?

Do not delete records blindly. Confirm the service is no longer needed first.

Can an SPF Record Include Multiple Domains?

Yes. One SPF record can include multiple vendor domains with include: mechanisms. That is common for client domains that use Google Workspace or Microsoft 365 for inboxes, plus Mailchimp, HubSpot, Zendesk, a CRM, support software, or a transactional email platform.

The risk is not the number of include statements by itself. Two includes can be fine. Six includes can be fine if they are active, documented, and stay within the SPF 10 DNS lookup limit. The real risk is hidden expansion: one include can point to a domain that includes several more domains, and old vendors can remain in the record long after the client stops using them.

For agencies, every included domain should answer a business question: which platform sends mail, who owns it, and does the client still use it?

SPF Multiple Includes vs Multiple SPF Records

Multiple include mechanisms inside one SPF record can be valid. Multiple separate SPF TXT records for the same domain are not a valid SPF setup.

Example of one SPF record with multiple includes:

v=spf1 include:_spf.google.com include:mail.zendesk.com include:send.example.net ~all

Example of duplicate SPF records:

v=spf1 include:_spf.google.com ~all
v=spf1 include:send.example.net ~all

The first pattern may be acceptable after lookup counting. The second pattern should be consolidated. For duplicate-record cleanup, use the multiple SPF records guide.

| SPF pattern | Valid? | Main risk | Agency action | |---|---|---|---| | One SPF record with two includes | Usually | Each include may expand into more lookups | Confirm both vendors are active | | One SPF record with six vendor includes | Maybe | Lookup limit or stale sender bloat | Count DNS-triggering mechanisms and remove retired vendors | | Two separate v=spf1 records | No | SPF PermError-style behavior | Merge confirmed mechanisms into one record | | Old include from unused vendor | Technically possible but risky | Authorizes a sender no one owns | Confirm with the client, then remove if retired | | Nested include chain | Maybe | Hidden lookup count grows quickly | Expand the chain before publishing changes |

Redirect can hide the real SPF policy

The redirect= mechanism delegates SPF evaluation to another domain.

Example:

v=spf1 redirect=spf.example.com

This can be clean when intentionally managed. It can also confuse teams because the visible domain's record looks short while the real evaluation happens elsewhere.

For agencies, redirect is not bad by itself. The risk is ownership and visibility. If the redirect points to a vendor or legacy domain, make sure the client still controls the relationship and understands the consequences.

The silent failure pattern

SPF problems are often described as silent because the website still loads and mail may still appear to send. The issue shows up at the receiver side, and behavior can vary by mailbox provider, policy, and message stream.

An agency may first hear about it through vague reports:

• "Our newsletters are going to spam."
• "Invoices are not arriving."
• "Some clients get our emails and some do not."
• "The CRM says DNS is configured, but mail still fails."

SPF is only one part of deliverability, so avoid overpromising. A failed SPF evaluation can be important, especially for DMARC alignment, but fixing SPF does not guarantee inbox placement.

The practical agency response is to check the full authentication picture: SPF, DKIM, DMARC, and the sender's actual From domain.

Decision tree for debugging SPF

Use this decision tree when a client domain may be near the SPF lookup limit.

| Step | Question | Action | |---|---|---| | 1 | Does the domain have one SPF record? | Multiple SPF records are invalid. Consolidate carefully. | | 2 | Does every include map to an active sender? | Remove stale vendors after confirming with the client. | | 3 | Are there nested includes? | Expand the chain and count DNS-triggering mechanisms. | | 4 | Are a or mx mechanisms necessary? | Replace with direct IPs or vendor guidance when appropriate. | | 5 | Can a sender use DKIM alignment instead? | Prefer DKIM where the vendor supports a clean setup. | | 6 | Is the record still too complex? | Split sending strategy by subdomain or reduce vendors. |

This keeps the review operational rather than theoretical.

Common SaaS sender pattern

Most agency clients use more than one system to send mail. A normal client stack might include:

• Google Workspace or Microsoft 365 for employee mail.
• A marketing platform for campaigns.
• A CRM for sales sequences.
• A helpdesk for support replies.
• An ecommerce system for receipts.
• A website plugin for form notifications.
• A transactional provider for application mail.

The temptation is to authorize every sender through SPF on the root domain. That can become fragile.

A better workflow is to ask:

• Which systems need to send as the root domain?
• Which can send from a subdomain?
• Which support DKIM alignment?
• Which are obsolete?
• Which are only used for internal notifications?

This conversation is especially useful during onboarding. It turns a DNS cleanup into a client operations inventory.

SPF and DMARC alignment

SPF by itself checks whether the connecting mail server is authorized for a domain used in the return path. DMARC cares whether that authenticated domain aligns with the visible From domain.

That means a message can pass SPF for a vendor-owned return-path domain but not help DMARC for the client's visible From domain.

Agencies should look for:

• SPF present but DMARC still not passing for real mail.
• Vendor setup instructions that mention custom return-path domains.
• DKIM records that may provide a cleaner alignment path.
• Marketing platforms that require both SPF and DKIM steps.

Inbox Pulse gives a configuration snapshot. For real message validation, send test messages and inspect authentication results in the receiving mailbox headers.

How to reduce SPF lookup risk

There is no universal SPF cleanup template, but the pattern is consistent.

Remove stale senders

Ask the client which platforms still send mail. Check billing, admin accounts, marketing calendars, and form plugins. Old vendors are common.

Prefer DKIM where appropriate

Many SaaS platforms support DKIM. If DKIM aligns with the client's domain, the client may not need to rely on SPF alignment for that sender. Follow the sender's documentation and verify the result.

Avoid unnecessary a and mx

The a and mx mechanisms can be convenient but may add lookups. If the sender is known and stable, direct IP ranges or vendor-provided includes may be clearer. Use caution because IP ranges can change.

Use subdomains intentionally

Some clients benefit from sending marketing or application mail from subdomains. This can separate risk and make configuration easier to reason about.

Document every sender

The SPF record is not the documentation. Keep a client note that maps each include to a platform, owner, and reason.

Agency maintenance cadence

Review SPF during:

• client onboarding
• email platform migrations
• quarterly technical reviews
• deliverability complaints
• DNS provider migrations
• website launches that add form or ecommerce email

Pair the email check with broader domain operations. Use Inbox Pulse for email-authentication configuration, Watchtower for SSL expiry calendars, 47-Day Renewal Pre-Flight for renewal readiness, and the agency audit for SSL, DNS, and domain expiry.

For DNS change process, see the DNS drift agency guide. For SSL renewal risk, see the ACME readiness check guide.

What not to promise

Fixing SPF is important, but agencies should avoid broad claims.

Do not promise:

• guaranteed inbox placement
• guaranteed deliverability
• legal compliance
• complete protection from spoofing
• that SPF alone fixes DMARC

Promise the practical thing: the agency will identify visible configuration risk, clean stale authorization paths, and verify setup against the client's actual senders.

Related resources

• Inbox Pulse email authentication checker
• Multiple SPF records cleanup guide
• DMARC, SPF, and DKIM explained for agencies
• Bulk DMARC check for client domains
• DKIM selectors cheat sheet
• How CertPilot checks domains

Frequently Asked Questions

What is the SPF 10 lookup limit?

It is the limit on DNS lookups a receiver can perform while evaluating SPF. Mechanisms such as include, redirect, a, mx, and exists can count toward it.

Can an SPF record include multiple domains?

Yes. An SPF record can include multiple domains with include: mechanisms, and that is normal for clients with several sending platforms. The record still needs one v=spf1 policy, one final all mechanism, and a lookup count that stays within SPF limits. Agencies should document each included domain so old vendors do not remain authorized indefinitely.

How many SPF includes are too many?

There is no safe number by itself. One include can expand into several nested DNS lookups, while several simple includes may still pass. The practical limit is the SPF 10 DNS lookup limit. Agencies should expand the chain, count DNS-triggering mechanisms, and remove stale senders before assuming the record needs flattening.

Does every include count toward the SPF 10 lookup limit?

Yes, the include: mechanism counts toward SPF's DNS lookup limit, and the included domain may trigger additional lookups inside its own SPF policy. That is why nested includes create surprise failures. Direct ip4: and ip6: mechanisms do not count as DNS lookups, but they can be harder to maintain when providers change infrastructure.

What is the difference between SPF multiple includes and multiple SPF records?

SPF multiple includes means one SPF record contains several include: mechanisms. That can be valid if the lookup limit is respected. Multiple SPF records means the same hostname publishes two or more TXT records that begin with v=spf1. That is not valid SPF setup and usually needs consolidation.

Do IP addresses count toward the SPF lookup limit?

No. ip4 and ip6 mechanisms do not trigger DNS lookups. They can still become hard to maintain if a sender's IP ranges change.

Why does SPF fail after adding a new sender?

The new sender may add another include, and that include may contain nested lookups. If the total evaluation exceeds the limit, SPF can fail.

Should agencies flatten SPF records?

Flattening can reduce lookups, but it can also create maintenance risk when providers change IPs. Use it carefully and only with a process for updates.