Why SPF lookup counts matter for your email deliverability

You send a campaign through Mailchimp, but half your messages bounce. You check the logs—no clear error. Then you see it: "SPF lookup limit exceeded." It’s not a typo. It’s a technical limit that silently kills your delivery.

SPF lookup count isn’t just a backend metric. It’s the gatekeeper to inbox placement. Every time a receiving server checks your SPF record, it counts. Exceed the limit—usually 10 lookups—and your email fails validation. That’s why tools like Salesforce, HubSpot, and Mailchimp often trigger SPF failures, even when everything else seems right.

Think of SPF validation like a security checkpoint. Too many checks, and the system rejects the passenger. You’re not just verifying addresses—you’re validating trust at scale.

Key takeaways

  • SPF lookup counts directly impact whether your emails reach the inbox or get rejected.
  • Each DNS query during SPF validation consumes a lookup; exceeding 10 typically results in failure.
  • Integrated platforms like Salesforce, HubSpot, and Mailchimp accumulate lookup counts through nested includes, increasing the risk of SPF failure.

How many SPF lookups does Salesforce actually trigger?

Salesforce can trigger up to 10 SPF lookups per outbound email if it routes messages through multiple third-party services or includes multiple domains in the MAIL FROM or HELO commands. Each domain in those headers counts as a separate DNS lookup, and shared infrastructure like marketing platforms multiplies the total. This can push you over the 10-lookup limit, causing SPF failures and delivery issues.

What drives SPF lookup counts in Salesforce?

When Salesforce sends email, it uses the MAIL FROM and HELO commands to identify the sending domain. Each domain listed in those headers triggers its own SPF DNS lookup. If your email includes a custom domain from a third-party tool—like a Mailchimp campaign or a HubSpot automation—that domain gets counted. So if your message passes through Salesforce, then HubSpot, then Mailchimp, each service’s domain may add one or more lookups.

That’s why SPF validation fails so often in complex workflows. The SPF policy for the final sender domain might be valid, but when the total lookup count exceeds the standard limit of 10 (defined in RFC 7208), the server may reject the message outright. This isn’t a Salesforce flaw—it’s how DMARC enforcement works. Many senders overlook this, assuming authentication is “set and done.”

Let’s be clear: SPF only validates one sending domain at a time, but the number of checks grows fast. For example, if Salesforce forwards a message with a Salesforce domain, a marketing tool domain, and a customer-facing domain, that’s at least three lookups. Add in a delivery service like SendGrid, and the count climbs quickly. This is especially common in customer support flows using Zendesk or HubSpot, where automated emails often carry multiple domains.

For deeper insight, RFC 7208—the standard defining SPF—specifies that implementations must not exceed 10 DNS lookups. Exceeding this limit results in a permanent failure. This is why checking SPF configuration early in the delivery chain is critical. Tools like MailTester’s integrations help spot these issues before your first campaign lands in spam.

How to avoid SPF lookup overages in complex setups

Start by auditing your email flow. Which tools are involved? Do they inject their own domains into MAIL FROM or HELO? Simplify where possible—use a single, verified sending domain across all services. Avoid mixing multiple domains in one message if you can.

Using a real-time verifier like MailTester’s API or bulk list verification lets you test whether domains in your workflow are configured properly. You can catch SPF lookup risks before sending. This is especially useful when integrating Salesforce with tools like HubSpot or Mailchimp, where shared domains are common.

Ultimately, SPF lookup count isn’t just a technical detail—it’s a deliverability gate. A single email with six domains might pass today, but if one domain changes, the structure breaks. The fix is visibility and control. Use tools that map your entire delivery path and show you where lookups pile up. That’s how you keep your email in the inbox.

HubSpot SPF lookup behavior: What you need to know

You must include HubSpot in your SPF record to send emails on your behalf. Each campaign uses a unique sender domain, adding one SPF lookup per campaign. If multiple HubSpot customers share the same domain, you risk exceeding SPF limits—this can break email delivery. Always verify SPF configurations to avoid bounces.

Why HubSpot needs inclusion in your SPF record

When you use HubSpot to send emails, it acts as your sending agent. Without your domain explicitly authorizing HubSpot in your SPF record, receiving servers will reject your messages. This is required by SPF standards—specifically, RFC 7208, which defines how sender policies are validated.

Each time you send a campaign, HubSpot uses a unique subdomain (like campaign123.hubspot.com). This creates a new DNS lookup each time. If you run 20 campaigns, you could trigger 20 additional SPF lookups—each consuming one of the 10 allowed by the SPF specification.

This doesn’t just affect HubSpot. If you share a domain with other HubSpot users, their campaigns contribute to your overall lookup count, increasing the risk of exceeding the limit. That’s why shared domains are problematic—even if you’re not the one sending them.

How to avoid SPF lookup overload

Let’s keep it simple: if your domain is shared across HubSpot customers, your SPF record is more likely to fail. Even if you’re not sending thousands of emails, a single campaign from another user can tip the balance.

One way to manage this is to avoid overly complex SPF records. Instead of listing every possible sender, consider using a dedicated sending domain—so HubSpot sends from hubspot.yourcompany.com instead of your primary domain. This reduces the number of lookups on your main DNS record.

Use tools like MailTester’s bulk verification to test how many real emails you’re sending. This helps you gauge whether you need to reduce campaign volume or restructure your sending domains. You can also run an inbox placement test to verify that your emails land in inboxes, not spam folders.

For real-time checking, our verification API lets you validate email addresses and detect issues early. It integrates with platforms like HubSpot, Mailchimp, and Salesforce, so you can audit sender reputation and email health across your stack.

For more on SPF, see the official SPF specification on IETF.org. It’s the definitive reference on how SPF records are processed.

Mailchimp SPF lookups: The hidden toll on your sender reputation

You need to include mailchimp.net in your SPF record when using Mailchimp, but if your list has domains that trigger multiple SPF checks—especially with complex email routing or shared infrastructure—your total SPF lookup count can spike. Even with correct alignment, exceeding the 10-lookup limit can lead to temporary verification failures, harming deliverability and sender reputation. Let’s break down how this happens.

Why SPF lookups matter in Mailchimp campaigns

Mailchimp sends emails through its own infrastructure, so your domain's SPF record must explicitly authorize mailchimp.net as a sending domain. This is non-negotiable. Without it, authentication fails before delivery even begins.

But here’s where things get tricky: for every email address you send to, the receiving server may perform an SPF check, and that check can trigger nested lookups if the domain uses multiple third-party services or complex DNS setups. For example, if an address ends in @example.com, and that domain has a complex SPF policy with multiple include statements, each one compounds the lookup count.

How high counts sabotage deliverability

SPF lookups are limited—most email providers enforce a maximum of 10 lookup steps per validation. If the total exceeds this, the receiver treats the check as a temporary failure. This doesn’t mean the email is blocked outright, but it can lead to delayed delivery, increased bounce rates, or even temporary rejection.

Even if your list’s domains are valid, high lookup counts from repeated include statements (like including multiple vendors, shared IPs, or old domains) can cause this. A single domain with five include statements may trigger six lookups—just from SPF. Add in DKIM or DMARC checks, and the count grows fast.

According to the RFC 7208, the SPF specification explicitly caps lookups at 10. Exceeding it results in a temporary failure, not a permanent rejection. That nuance matters: it’s not a hard block, but it introduces risk in large-volume campaigns.

Let’s say you’re sending to a list with 20,000 contacts. If even 10% of them come from domains with overly complex SPF records, you’re already at risk of hitting lookup limits. This leads to inconsistent inbox placement, especially with providers that rely heavily on real-time reputation systems.

Even minor SPF record complexities can cause measurable delivery delays when scaled across large lists.

Using a tool like MailTester’s bulk verification helps catch problematic domains early. It flags high-lookup risk domains, catch-alls, and disposable addresses before you send. You can also test your sender setup with our inbox placement tester, which checks deliverability based on real provider behavior.

Are your tools causing SPF lookup limits to be exceeded?

Yes — if you’re using multiple marketing or service platforms like Salesforce, HubSpot, or Mailchimp, each integration adds DNS lookups to your SPF record. Most domains limit SPF checks to 10 lookups. Exceeding that causes a permanent failure, leading to email delivery issues. If you’re seeing consistent bounces or rejected messages, check your SPF lookup count first.

How SPF lookups work in practice

Every time an email is sent, the receiving server checks your domain’s SPF record. It resolves each mechanism in the record (like include, redirect, or a, mx, ip4) as a DNS query. You have a hard cap: 10 lookups per SPF evaluation. Once you hit that limit, the check fails — even if the rest of your record is valid.

Now imagine you use HubSpot for CRM, Salesforce for sales ops, Mailchimp for email campaigns, and a helpdesk tool like Zendesk. Each of these likely adds its own include directive to your SPF record. One include can cost you 3–5 lookups, especially if they’re nested. It’s easy to exceed 10 without realizing it.

Common sources of SPF lookup bloat

Tools like Salesforce, HubSpot, and Mailchimp each require an include entry in your SPF record to authorize them to send on your behalf. If you have five such tools, and each includes two or three nested lookups, you’re already at 10 + — and some of them may fail silently.

One SPF record can include up to 10 mechanisms, but if one includes another record that itself has 5 mechanisms, you’re consuming 6 lookup points in seconds. It’s not just the number of tools — it’s how deeply they’re nested.

According to RFC 7208, the standard for SPF, the lookup limit is strictly enforced. A single failure at this stage prevents delivery, even if the email content is clean. This is why many B2B senders see sudden spikes in rejection rates after enabling new integrations.

Let’s say your current SPF fails checks. You can verify your record’s lookup count using tools like MxToolbox or DNSstuff. These services show how many lookups your record consumes and where they come from. If you’re over 10, your record is invalid.

Use MailTester’s bulk verification to test if your sender reputation and deliverability are being hurt by SPF misconfigurations. It checks your records in real-world conditions, showing you where your emails are failing — including SPF lookup limits.

Fixing SPF requires careful auditing. Consolidate includes where possible, use SPF aligns with DMARC, and avoid over-adding tools. If you’re unsure, test your entire setup with inbox placement tools to see what receivers actually receive.

A step-by-step guide to check SPF lookup counts for your stack

Use a real-time DNS lookup tool like MxToolbox or DNSDumpster to test your domain’s SPF record. Enter your domain, then examine the full SPF chain—including every include directive and expanded record. Each include counts as one lookup, so tally all third-party domains like mailchimp.net, hubspot.net, or salesforce.com. If the total exceeds 10, you risk failing SPF validation. Re-test after simplifying or removing duplicates to confirm the fix.

Check your SPF record structure

  1. Go to a DNS lookup tool like MxToolbox or DNSDumpster. Enter your domain and select the SPF record lookup option.
  2. Review the full SPF chain. Look for every include: directive, especially those pointing to third-party domains such as include:mailchimp.net or include:spf.protection.outlook.com.
  3. Count each include as one lookup. If one include references another SPF record, that counts as a second lookup—each expansion counts toward the limit.
  4. Note that some services use multiple includes or complex chains. For example, Salesforce or HubSpot may require nested includes, which can quickly add up. Keep track of every third-party domain involved.
  5. Once you’ve mapped the full chain, verify how many lookups your record uses. The limit is 10—exceeding it can cause SPF failures and delivery issues.
  6. After simplifying your record—removing duplicates, consolidating includes, or using a single, unified domain—re-test the record to confirm the count has dropped below 10.

Prevent issues before they impact deliverability

SPF lookup limits are enforced by receiving servers and are defined in RFC 7208. If your chain exceeds 10 lookups, the server may reject your message entirely—even if the sender is legitimate.

Many brands using HubSpot, Mailchimp, or Salesforce unknowingly hit the limit due to multiple third-party includes. You can avoid this by auditing your setup regularly. Tools like MailTester’s integrations help verify sender identity and alignment across platforms.

Keep your SPF record lean. Use inbox placement testing to validate deliverability after changes. If you’re managing a large list, bulk verification ensures your sender reputation stays clean.

How email verification helps prevent high SPF lookup counts

High SPF lookup counts happen when your email service checks multiple SPF records during delivery, which can trigger rejection if you exceed the 10-lookup limit. Email verification helps by filtering out invalid, disposable, or catch-all addresses before they’re sent—reducing unnecessary DNS lookups and keeping your SPF checks within safe boundaries. You're not just cleaning your list; you're hardening your deliverability.

Moving early validation prevents DNS overreach

Let’s start with the basics: SPF checks happen at the DNS level. Every time you send an email via an external provider, your sending domain’s SPF record may trigger lookups against third-party domains (like Salesforce, HubSpot, or Mailchimp). If your list includes outdated or invalid emails, those send attempts still go through the full SPF validation process—even if the address is fake.

By running a bulk verification check upfront—using tools like MailTester’s email list verification—you catch and remove domains that don’t resolve. That means fewer emails sent to addresses that would otherwise trigger a multi-record SPF lookup. No send? No lookup. Simple.

Cleaner lists mean fewer problematic senders

Disposables or role-based addresses (like admin@, support@, or [email protected]) often appear valid but don’t route reliably. They may pass syntax checks but sit behind catch-all configurations that can’t verify individual users. If your mailer sends to them, it's not just wasted effort—it can indirectly increase SPF lookups if the domain is part of a larger chain of authenticated services.

MailTester’s system flags these as “risky” or “catch-all,” which means you can quarantine these addresses before they cause trouble. This keeps your outbound flows clean. And since you’re only sending to confirmed real users, your overall DNS traffic drops meaningfully.

According to RFC 7208, SPF lookup counts are capped at 10 across all included mechanisms. Exceeding this limit triggers a temporary failure. This isn’t theoretical—many senders hit this limit with oversized or poorly maintained lists. Email verification helps stay under the line.

Even if your email service supports up to 10 SPF lookups, sending to 500 invalid addresses doesn’t just cost you time—it costs you deliverability. Verification reduces that load. Every email you don’t send is an SPF lookup you never made. That’s real savings.

For automated workflows, the verification API at MailTester’s API checker integrates directly into your onboarding or sync process, ensuring only clean addresses ever reach your tools—no matter if they’re routed through Salesforce, HubSpot, or Mailchimp.

The real impact of catch-all and invalid emails on SPF

Send to a catch-all domain, and you risk SPF validation failures even if the email isn’t technically invalid. These domains accept all mail, but often fail to route it correctly, causing SPF checks to reject the message—wasting sender reputation, inflating lookup counts, and harming deliverability. You’re not just sending to junk; you’re risking your domain’s trust.

Catch-alls don’t just accept mail—they mislead mail servers

Catch-all domains are set up to accept any email sent to them, regardless of whether the specific address exists. That might seem helpful for inbox reliability, but it’s a known loophole spammers exploit. When a mail server sees a catch-all, it can assume the domain is less trustworthy—especially if the receiving server has no way to validate that the email actually reached a human.

More importantly, catch-alls can break SPF checks. SPF validates the origin of an email based on the sending domain’s policy. If the receiving server can’t determine the proper delivery path (because no address exists), the SPF check may fail. Even if the email is real, it might be flagged as invalid due to routing ambiguity. This leads to unnecessary hard bounces and increased SPF lookup volume—overhead that doesn’t improve delivery but harms your sender reputation.

Invalid emails aren’t just wasted send attempts—they hurt SPF reliability

Sending to invalid addresses—especially those on catch-all domains—doesn’t just waste bandwidth. Every failed delivery, even a soft bounce, counts against your sender reputation. Spam filters track these patterns over time. The more times you try to send to unverifiable or non-existent addresses, the more likely your domain is to be flagged as noisy or unreliable.

SPF lookup counts rise not just from the number of emails sent, but from the number of validation attempts each email triggers. If your list includes dozens of catch-alls or invalid addresses, your domain could face repeated SPF authentication failures across different servers, especially when sending at scale to tools like Salesforce, Zendesk, HubSpot, or Mailchimp. These platforms rely on consistent deliverability—and any instability in your email system can affect delivery across all integrations.

Let’s be clear: you don’t need to clean your list for “soft bounces” alone. You need to clean it for real delivery risk. Tools like MailTester identify catch-alls, invalid emails, and role accounts before you send. Use bulk verification to catch them early.

Proactive email validation is a baseline check. It’s not optional—it’s how you maintain SPF integrity across tools like HubSpot and Mailchimp that depend on clean sender reputation. The cost of not verifying? Higher bounce rates, longer delivery delays, and harder-to-recover sender reputation.

Learn more about how SPF works, and why even correctly configured policies fail when sent to unreliable targets: RFC 7208. Also consider how reputation is formed: Spamhaus’s overview on sender reputation and IP hygiene.

Using MailTester to audit your domain’s SPF health

MailTester’s real-time verification API checks if an email address is valid and whether it’s compatible with your domain’s SPF records. You can scan your list to find addresses that trigger high SPF lookup counts due to misconfigured routing, and use the results to reduce bounce rates and improve inbox placement. Bulk verification identifies risky or invalid addresses before you send, so you don’t waste resources on addresses that will fail.

How SPF lookup counts impact deliverability

Every time an email is sent, receiving servers may perform an SPF check, which involves querying DNS records. If your domain’s SPF record includes too many mechanisms—like multiple include directives—it can hit the 10-lookup limit defined in RFC 7208. Once surpassed, the SPF check fails, often leading to delivery failure or spam tagging. You’re not just at risk of bounces; you’re also damaging your sender reputation.

Using real-time verification to detect problems

MailTester’s verification API performs a live check on each address, including SPF compatibility. When an email is flagged as “invalid” or “risky,” it may be due to a malformed address, a catch-all domain, or an SPF violation. Let’s say you’re sending to a list with old marketing leads: some may be valid, but their domains could be routing emails through services that trigger excessive SPF lookups. Using bulk verification lets you isolate these addresses and clean them up before sending.

Once you run a verification, you’ll see clear verdicts like “valid,” “invalid,” “catch-all,” or “risky.” A high number of “risky” results often means SPF or routing issues. The in-app AI assistant helps you interpret why—whether it’s due to overlapping includes in SPF, outdated domains, or role-based addresses like support@ or info@. It suggests real steps, like removing redundant includes or excluding catch-alls, based on industry practices documented by the IETF’s RFC 7208.

Integrate MailTester with Mailchimp, HubSpot, or Zendesk via our integrations to automate checks before every send. You can also validate individual addresses in real time with the verification API. For final confirmation, test your message’s inbox placement with our inbox tester. All this helps you send confidently, knowing your emails are both technically valid and trusted by receivers.

SPF lookup count limits: What to expect in 2026 and beyond

You’re limited to 10 DNS lookups when validating SPF records—this cap is fixed in the industry standard and won’t change by 2026 or beyond. Systems are built to fail fast when that threshold is reached, not to extend it. The focus isn’t on increasing lookup quotas; it’s on reducing spam and enforcing sender reputation through stricter validation.

Why the 10-lookup ceiling exists

SPF checks follow a strict rule set defined in RFC 7208: no more than 10 DNS lookups are allowed per validation. Exceeding that limit results in a "TempError" or "PermError" from receiving servers. This design prevents abuse—malicious actors can’t craft overly complex SPF records to slow down or clog email validation systems.

This limit is enforced by all major email providers, including Gmail, Yahoo, and Outlook. If your SPF record references too many mechanisms (like includes, a, mx, ip4, ip6), you’ll hit the limit and risk failing email delivery. It’s not a flaw; it’s a security guardrail.

What you can expect after 2026

No new lookup limits are coming. The standards body (IETF) has not proposed changes to the SPF specification since RFC 7208 was published. Instead of expanding quotas, future improvements will focus on sender reputation, real-time blocklist monitoring, and better detection of credential abuse.

That means the real work isn’t in squeezing more lookups out of SPF records—it’s in keeping your domain and IP address clean. A poor sender reputation can block emails even if your SPF structure is technically valid.

Let’s be honest: trying to push past 10 includes is a dead end. You’ll just create more failure points. Instead, focus on reducing complexity. Use a single, well-maintained SPF record, apply best practices, and verify your domains regularly. Services like MailTester’s bulk verification can show you if your senders are still in compliance—before they get flagged.

Final takeaway: Keep your SPF lookup count under control

High SPF lookup counts occur when multiple integrated tools — such as Salesforce, Zendesk, HubSpot, and Mailchimp — each send mail through separate mechanisms, adding up to 10 checks per domain. This exceeds the standard limit of 10 lookups, risking DMARC failure and inbox drop.

Regular list cleaning and real-time verification reduce the volume of emails sent, directly lowering the number of SPF lookups. This preserves deliverability and avoids unnecessary load on DNS.

Use tools that catch problems early

  • MailTester identifies invalid, catch-all, and risky addresses before they get sent.
  • Its 98.9% accuracy helps maintain strong sender reputation and ensures only verified addresses enter your workflow.
  • By integrating real-time checks, you avoid sending to domains that trigger excessive SPF queries.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What happens if SPF lookup count exceeds 10?

SPF validation fails, often resulting in email rejection. This harms deliverability and sender reputation.

Can I use multiple SPF records?

No. Only one SPF record per domain is allowed. Multiple records cause validation failure.

How do I check my SPF lookup count?

Use DNS tools like MxToolbox or dig to resolve your SPF record and count included domains.

Do all my tools require SPF inclusion?

Only third-party email senders like Mailchimp or HubSpot need to be included in your SPF record.

What’s the impact of role accounts on SPF?

Role accounts (e.g. sales@, info@) are often catch-alls. Sending to them can waste send volume and increase lookup load.

How can MailTester help with SPF issues?

It verifies email validity, flags risky addresses, and helps clean lists before sending, reducing SPF load.

Is SPF lookup counting still relevant in 2026?

Yes. The 10-lookup limit remains unchanged and is enforced by major mail providers.

Can disposable domains cause SPF lookup issues?

They don’t directly increase lookup counts, but they contribute to poor sender reputation when sent to.

Why do some tools like Salesforce trigger more lookups?

They use multiple sender domains or third-party services, each requiring a separate SPF lookup.

Should I use a single SPF record for all integrations?

Yes. Consolidate all included domains into one record to stay under the lookup limit.

What’s the best way to avoid SPF problems at scale?

Verify emails before sending, remove invalid addresses, and keep SPF records simple and manageable.

How accurate is MailTester’s email verification?

MailTester achieves 98.9% accuracy in identifying valid, invalid, catch-all, and risky email addresses.