Advanced SPF Management for Multiple Email Providers

Once you start using more than one email provider, SPF very quickly stops being a “set it once and forget it” record. Marketing platform, CRM, support desk, billing system, your own SMTP on a VPS… each one wants you to add another include:. Before long, you hit the infamous 10 DNS lookup limit and mailbox providers start treating your SPF as if it doesn’t exist. In other words: your carefully configured email infrastructure quietly loses one of its main authentication layers.

In this article we’ll look at SPF from the perspective we use when helping dchost.com customers: real domains, multiple providers and long‑lived DNS setups. We’ll break down exactly what counts as an SPF lookup, how to count them, and what to do when you’re already over the limit. Then we’ll walk through practical strategies – IP consolidation, subdomains, redirect=, and safe SPF flattening – that work reliably on shared hosting, VPS and dedicated servers alike.

If you already understand the basics of SPF, DKIM and DMARC, this is the next step: keeping SPF valid and maintainable when your email ecosystem gets complex.

Why SPF Hits a Wall with the 10 DNS Lookup Limit

SPF is simple in theory: you publish a TXT record telling the world which servers are allowed to send on behalf of your domain. But SPF evaluation is not purely string‑based. The receiving server has to perform DNS lookups to expand the mechanisms you’ve written and build a list of allowed IPs. To protect the DNS system – and prevent SPF checks from becoming too slow or abusive – the RFC caps this at 10 DNS lookups per SPF evaluation.

When you’re using multiple external providers, each include: you add typically hides several more include:s inside it. Two or three vendors can be enough to break SPF, even if the record still “looks” short. Once the receiver counts more than 10 lookups, the SPF result becomes permerror (permanent error). Many mailbox providers then treat this as if SPF failed or did not exist, which can downgrade your DMARC result and push messages closer to the spam folder.

So advanced SPF management is mostly about one thing: delivering the intent of your policy while staying under that 10‑lookup ceiling.

Quick Refresher: How SPF and DNS Lookups Actually Work

If you need a step‑by‑step primer on SPF, DKIM and DMARC, we’ve written a dedicated guide: SPF, DKIM and DMARC explained for cPanel and VPS email. Here we’ll focus on the pieces that matter for the lookup limit.

Mechanisms that Count Toward the 10 Lookup Limit

In SPF, these mechanisms do trigger DNS lookups:

• include:example.com – fetches the SPF record of another domain.
• a or a:example.com – resolves A/AAAA records.
• mx or mx:example.com – resolves MX, then A/AAAA for those hosts.
• ptr – reverse DNS lookups (and it’s discouraged in modern SPF).
• exists:example.com – resolves that host.
• Any mechanism or modifier using SPF macros that forces a DNS lookup.

These mechanisms and modifiers do not trigger DNS lookups:

• ip4:203.0.113.0/24
• ip6:2001:db8::/32
• all, +all, ~all, -all
• redirect=otherdomain.com – this is special; it causes one SPF fetch, but does not add to the 10 lookup counter twice (details below).

How to Manually Count SPF Lookups

The lookup limit operates on the fully expanded SPF policy, not just the text in your DNS. To estimate your usage:

1. Start with your top‑level SPF record, e.g. v=spf1 include:mailvendor.com include:crm.example.net ~all.
2. For each include:, fetch that domain’s SPF and repeat the process.
3. Within every SPF you encounter, count each include:, a, mx, ptr and exists as one lookup.
4. Ignore ip4, ip6 and all – they don’t add lookups.
5. Stop if you reach 10. Anything beyond that will be ignored by a strict SPF implementation.

This can be tedious to do by hand, but it’s worth doing at least once for your domain so you get a feel for how “expensive” your current providers are in SPF terms.

Typical Multi‑Provider SPF Problems

Let’s look at a pattern we see regularly when auditing SPF records for customers hosting DNS, websites or mail infrastructure with us.

Example: Marketing, CRM, Helpdesk and In‑House SMTP

Imagine a mid‑size company using:

• A hosted email suite for day‑to‑day mailbox use.
• An email marketing platform for newsletters.
• A CRM that sends automated follow‑ups.
• A support/helpdesk platform for ticket emails.
• An on‑prem or VPS‑based SMTP service for application alerts and transactional mail.

Their SPF often ends up looking like this:

example.com. IN TXT "v=spf1 
  include:_spf.mail-suite.com 
  include:spf.marketing-platform.com 
  include:spf.crmvendor.com 
  include:spf.helpdesk.com 
  include:spf.vps-smtp.example.net 
  ~all"

Each of those includes might pull in another 2–4 includes, plus MX and A lookups. On paper you see five includes. In practice the receiver might be processing 14–16 lookups. Result: permerror, SPF is effectively broken, and DMARC alignment suffers.

Symptoms You’ll See in the Real World

When SPF is over the limit, you won’t necessarily see a clear error in your own logs, especially if you’re not running your own inbound mail server. Most teams notice it indirectly:

• Deliverability for some providers suddenly drops while others look fine.
• DMARC aggregate reports show a lot of spf=permerror even for legitimate traffic.
• Messages from certain systems (often the “last” ones you added) land in spam more often.
• Some online testers warn about “too many DNS lookups” or “SPF too complex”.

If you’re working through a broader deliverability checklist, our article Inbox or spam? A friendly, step‑by‑step guide to SPF, DKIM, DMARC and rDNS shows how SPF fits into the bigger picture.

Strategic Fixes Before You Touch DNS

Before diving into technical SPF tricks, it’s worth asking some architectural questions. Often the cleanest SPF setup starts with email strategy, not syntax.

Consolidate Providers Where It Makes Sense

Every new provider you add has a cost in SPF complexity, DNS records, and operational overhead. If your stack has grown organically over the years (one tool added per team), consider:

• Do you still need every platform that’s allowed to send from your main domain?
• Could some campaigns move to an existing provider instead of a new one?
• Are there legacy systems that no longer send but are still present in SPF?

Pruning unused or low‑value senders is often enough to bring SPF back under the limit without any advanced techniques.

Separate Sending Domains for Different Use Cases

One of the most powerful levers you have is the domain itself. Instead of letting every system send from @example.com, you can move some traffic to dedicated subdomains or sibling domains:

• news.example.com for newsletters.
• crm.example.com for CRM automation.
• support.example.com for helpdesk replies.
• billing.example.com for invoices and receipts.

Each sending domain then has its own SPF record. That means the 10‑lookup limit is per domain, not shared across all your use cases. It also gives you cleaner DMARC reporting and clearer separation in users’ inboxes.

We’ve explored this pattern in detail in our article using separate sending domains for transactional vs marketing emails. If you’re struggling with both deliverability and SPF complexity, this is often the best long‑term fix.

Align SPF Strategy with DMARC Policy

DMARC ties SPF (and DKIM) to the visible From: domain. When DMARC policy and SPF architecture are designed together, you can:

• Keep only DMARC‑aligned senders in the main domain’s SPF.
• Move non‑aligned systems to subdomains with their own DMARC and SPF.
• Use DMARC aggregate (RUA) reports to see which services actually send.

That last point is important: DMARC reports reveal forgotten systems that still send email. Cleaning those up reduces both SPF complexity and surprise reputation issues later.

Technical Tactics to Stay Under 10 Lookups

Once you’ve decided which systems should legitimately send for each domain or subdomain, it’s time to design SPF syntax that stays within the limit.

1. Prefer ip4/ip6 Over include Where Possible

Many providers’ SPF documentation tells you to just add their include: and be done. That’s convenient for them, but not always optimal for you. If a provider is using a small, stable set of IP ranges, you can often replace an include: with explicit addresses:

v=spf1 include:spf.vendor.com ~all

might become:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.10 ip6:2001:db8:1234::/48 ~all

Advantages:

• No DNS lookups for those entries.
• Full control over exactly which IPs are allowed.

Trade‑offs:

• You must monitor the provider’s IP range changes (status pages, documentation, mailing lists).
• More manual work if they change infrastructure frequently.

This approach works best for systems you control (e.g. your own VPS or dedicated server at dchost.com) and for providers with clearly documented, rarely changing ranges.

2. Use redirect= to Split Responsibilities Cleanly

The redirect= modifier lets one SPF record delegate all checking to another domain’s SPF. For example:

example.com. IN TXT "v=spf1 redirect=_spf.example.com"</code>

_spf.example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.10 ~all"

Key points:

• redirect= itself doesn’t add to the lookup count in the same way as nested include:s; the receiving server just evaluates the target domain’s SPF as the policy.
• You must not mix mechanisms with redirect= in the same record. Once redirect= is present, its target SPF fully replaces the current one.
• This pattern is great for centralizing complex logic under a helper domain (e.g. _spf.example.com) while leaving example.com with a short, simple record.

We often use this when customers want a clean public SPF for the root domain but still need room to grow under the hood. You can maintain all the complexity on _spf.example.com and keep example.com simple and readable.

3. Move Edge Use‑Cases to Subdomains

If your main domain is already near the limit, offload non‑critical or noisy senders to subdomains with their own SPF records. For instance, instead of letting a monitoring system send from [email protected], move it to [email protected] with:

infra.example.com. IN TXT "v=spf1 ip4:198.51.100.20 ~all"

Advantages:

• Keeps the primary domain’s SPF focused on user‑facing mail (which impacts brand reputation most).
• Gives you another 10‑lookup budget per subdomain.
• Separates operational email from customer‑facing traffic in DMARC reports.

This approach pairs nicely with a robust hosting setup – for example, running monitoring and automation tools on a VPS with their own sending identity – instead of trying to squeeze everything into one busy SPF record.

4. Remove Deprecated or Redundant Mechanisms

As SPF evolved, some mechanisms fell out of favor, especially ptr. If your record still contains ptr or overly broad a/mx mechanisms, you may be wasting lookups:

• Replace mx with explicit IP ranges if your inbound and outbound infrastructure are separate.
• Remove ptr completely; it’s rarely needed and often slow.
• Trim wildcard a mechanisms that accidentally authorize more servers than intended.

Each removed lookup is room you can spend where it matters more.

SPF Flattening: When and How to Use It Safely

Sometimes you really do need several providers, and their SPF policies are “heavy”: lots of nested includes, geo‑sharded IPs, and so on. That’s when SPF flattening becomes useful.

SPF flattening means: resolve all the includes and other lookup‑based mechanisms ahead of time, then publish an SPF record that contains only ip4/ip6 ranges (and maybe a small number of necessary includes). The receiver no longer has to perform all those lookups; you’ve done that work yourself.

We’ve published a dedicated, very hands‑on guide to automated flattening: how to beat the 10 lookup wall with automated SPF flattening. Below is the conceptual version for planning.

Manual Flattening for Small, Stable Setups

For a simple stack that doesn’t change often, you can flatten once and update occasionally:

1. Take your current SPF and list all include:, mx, a and other lookup‑based mechanisms.
2. Use dig, nslookup or a trusted tool to resolve each to its IP ranges.
3. Compose a new SPF record using only ip4 and ip6 (and maybe a small number of truly necessary includes), for example:
   v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.10 ip6:2001:db8:1234::/48 ~all
4. Publish it as a TXT record and test.

Manual flattening is low‑tech but perfectly valid. The main risk is staleness: whenever a provider adds or removes IPs, you need to repeat the exercise. For “quiet” infrastructures (your own dchost.com VPS, a fixed on‑premise gateway), this is perfectly manageable.

Automated Flattening with CI/CD and DNS APIs

For more dynamic or larger setups, automation is your friend. The pattern we like looks like this:

• Keep a “source of truth” SPF template in version control (e.g. Git) that still uses includes: v=spf1 include:spf.marketing-platform.com include:spf.crmvendor.com ~all.
• Have a scheduled job (CI pipeline, cron job on a management VPS, etc.) that:

1. Resolves the template SPF into a flat list of IPs.
2. Builds a flattened SPF string.
3. Updates the TXT record via your DNS provider’s API.
4. Optionally stores the generated SPF in Git for history/auditing.

This gives you a “living” SPF record that stays under the lookup limit while tracking upstream IP changes automatically. If you’re already using automation tools for your infrastructure – for example, provisioning VPSs with Ansible or Terraform as in our guide automating VPS setup with Terraform and Ansible – adding SPF flattening into that flow is a natural step.

How Often Should a Flattened SPF Be Refreshed?

There’s no one answer, but a practical rule of thumb is:

• High‑change providers (big global email platforms): refresh daily or several times per week.
• Moderate‑change providers: refresh weekly.
• Your own infrastructure (VPS/dedicated servers with static IPs): refresh when you change servers or IP allocations.

Automated flattening makes this schedule easy to maintain. You can even let different parts of the SPF come from different sources (some static IP ranges, some dynamic from flattening) as long as the final published record stays under DNS size limits and within the 10‑lookup budget.

Testing, Monitoring and Ongoing Maintenance

SPF is not a “set and forget” record once you’re using multiple providers. A few lightweight habits keep it healthy:

1. Always Test New SPF Changes

Before and after changing SPF:

• Use command‑line tools (dig, nslookup) to verify the TXT record is correct and propagated.
• Send test emails to major mailbox providers (Gmail, Outlook.com, etc.) and inspect the message headers to confirm SPF=pass.
• Use a reputable SPF syntax/lookup checker to confirm you’re under the 10‑lookup limit and there are no hidden includes.

If you run your own inbound mail server on a VPS or dedicated server, you can also check the logs for SPF evaluation results directly.

2. Watch DMARC Reports for permerror and Fails

DMARC aggregate (RUA) reports are an excellent early‑warning system. If you already have DMARC set up to send reports, look for:

• Rows where spf=permerror for legitimate IPs.
• New senders that appear from IPs or providers you didn’t expect.
• Differences between SPF and DKIM alignment (sometimes you can rely on DKIM and simplify SPF).

For a deeper dive into DMARC analysis and BIMI, see our article beyond p=none: advanced DMARC, RUA/RUF analysis and BIMI.

3. Consider Forwarding and SRS/ARC Impacts

SPF is evaluated on the connecting IP, so traditional email forwarding often breaks SPF (and therefore DMARC). If you rely heavily on forwarding rules, you’ll want to:

• Use forwarders that implement SRS (Sender Rewriting Scheme) to preserve SPF semantics.
• Leverage ARC (Authenticated Received Chain) where supported to carry authentication results through forwarding chains.

We’ve covered this in detail in why forwarding breaks SPF/DMARC and how SRS and ARC help. While forwarding is not directly part of the 10‑lookup limit problem, it strongly influences how your SPF strategy behaves in the wild.

4. Re‑Audit Your SPF Once or Twice a Year

Businesses change marketing platforms, CRM tools and support systems all the time. Put a recurring reminder on your calendar to:

• List all systems that actually send email for each domain.
• Compare with what your SPF and DMARC reports say.
• Remove any systems you no longer use.
• Recalculate lookup counts and adjust includes or flattening schedules as needed.

This is also a great moment to align with broader hosting and infrastructure reviews – for example, when you’re planning upgrades to your VPS or consolidating services across data centers.

How dchost.com Can Help You Build a Clean, Scalable SPF Strategy

Good SPF design lives at the intersection of DNS, email providers and the servers that actually send your mail. Because dchost.com provides domains, DNS, shared hosting, VPS, dedicated servers and colocation, we get to see the full picture with many different customer setups.

Here’s how we typically help teams struggling with the 10‑lookup limit:

• DNS and domain planning: Designing a domain/subdomain layout that separates marketing, transactional and support mail, with clear SPF and DMARC policies for each.
• Hosting mail gateways on VPS/dedicated servers: For customers who want a central SMTP relay or self‑hosted mail stack, we size and deploy servers that can handle volume reliably while keeping SPF simple (often just a few ip4/ip6 entries).
• SPF flattening automation: Integrating SPF generation into your existing CI/CD or management scripts, using DNS APIs and the same automation mindset you might already apply to your web stack.
• End‑to‑end deliverability tuning: Aligning SPF work with DKIM, DMARC, rDNS and IP reputation. Our guides such as dedicated IP warmup and email reputation management fit naturally into this process.

If you’re planning a new email architecture, migrating providers, or simply suspect your SPF is “too complicated”, it’s a good time to step back and design it properly. With the right domain strategy, a sensible choice of providers, and a bit of automation where it pays off, the 10 DNS lookup limit stops being a hard wall and becomes just another design constraint you know how to work with.

And if you’d like to pair that with a solid hosting foundation – from shared hosting up to high‑performance VPS and dedicated servers – our team at dchost.com can help you design both the email and server side so they work together cleanly.