RFC 7208 Section 4.6.4 limits an SPF evaluation to 10 DNS lookups. Cross the limit and the record silently produces a PermError — all your authentication work is wasted. This article explains the rule in detail, shows how to count lookups for every mechanism, documents the subtle ways the count creeps up on UK businesses, and lays out three practical remediation strategies when you are over the ceiling.
RFC 7208 Section 4.6.4 reads: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." Exceed the limit and the evaluation terminates with PermError.
The rule is not a guideline; it is mandatory. Every compliant SPF evaluator — Gmail's, Outlook's, Yahoo's, your hosting platform's, the Axigen deployment that underpins smartxhosting.uk email — enforces it. A record that crosses the limit is, in practice, equivalent to having no SPF at all.
The reason the limit exists is mathematical. Nested includes can create exponential fan-out: one include that contains three includes, each containing three more, quickly expands to a tree of lookups that would overwhelm DNS infrastructure. The 10-lookup ceiling prevents the attack surface from becoming a denial-of-service weapon and caps evaluation time at something receivers can afford to do in real time during the SMTP conversation.
Six mechanisms and modifiers count toward the limit:
| Token | Counts as | Why |
|---|---|---|
include:domain | 1 + what domain's SPF consumes | The TXT lookup for the included domain plus any lookups it causes internally. |
a or a:hostname | 1 (plus A and AAAA implicit) | DNS A/AAAA query for the hostname. |
mx or mx:hostname | 1 plus one per returned MX host (up to 10) | MX query, then A/AAAA per MX host. |
exists:domain | 1 | A query for the target domain. |
ptr or ptr:domain | 1 (but deprecated) | PTR and forward-confirm queries. |
redirect=domain | 1 + what domain's SPF consumes | TXT lookup for the redirected domain plus its internal cost. |
Mechanisms that do not count:
ip4: and ip6: — no DNS query needed.all — the terminator, always free.v=spf1 — the version tag, not a mechanism.The consequence is that any policy built entirely from ip4:, ip6: and all consumes zero lookups and can never hit the ceiling — but it becomes your responsibility to keep the IP list current as upstream providers rotate infrastructure.
RFC 7208 Section 4.6.4 adds a second cap: no more than two void lookups (lookups that return no result) during evaluation. The rule exists to prevent an attacker flooding your SPF with references to non-existent domains, forcing receivers to waste time on DNS queries that will never succeed.
In practice, the void-lookup limit is usually hit when an include: target domain has been decommissioned but the include was never removed. The evaluator queries the missing SPF, counts a void lookup, and after two such misses rejects the whole record. The fix is to remove the stale includes.
The documented cost of a provider's include: is often one or two lookups, but internally the provider's SPF chains into further includes. Actual cost per popular UK-relevant include at the time of writing:
| Include | Documented | Actual at expansion |
|---|---|---|
include:spf.protection.outlook.com | 1 | 2-3 |
include:_spf.google.com | 1 | 3-4 (nested _netblocks) |
include:amazonses.com | 1 | 1 |
include:sendgrid.net | 1 | 1 |
include:servers.mcsv.net | 1 | 1 |
include:_spf.salesforce.com | 1 | 2-3 |
include:spf.mtasv.net (Postmark) | 1 | 1 |
include:mailgun.org | 1 | 1-2 |
include:_spf.smartxhosting.uk | 1 | 1-2 |
mx (with 2 MX hosts) | 1 | 3 (MX + 2 A records) |
These numbers drift over time. A rolling audit — running your record through a counting tool quarterly — catches creep before it causes live failures.
SPF record growth is usually passive — additions accumulate over years as the business adds new SaaS tools, while nothing ever gets removed. The classic UK trajectory:
include:spf.protection.outlook.com — 2 lookups.include:servers.mcsv.net — 3 lookups.include:_spf.salesforce.com — 5-6 lookups.include:mail.zendesk.com — 7 lookups.Because SPF failure is stamped only into the Authentication-Results header and does not produce visible bounces (DMARC has not been tightened yet because SPF was "working"), the failure can go unnoticed for months until the IT team notices a drop in deliverability or the finance team reports missing invoices.
spf=permerror in the Authentication-Results header. The definitive signal. Every receiver that evaluates SPF produces PermError.| Tool | What it does |
|---|---|
| MXToolbox SPF Record Lookup | Shows expanded SPF with lookup count. Free for occasional use. |
| Hardenize | Full-stack audit including SPF lookup count and nested expansion. |
| Mail Hardener | UK-accessible SPF analyser with trend data. |
| NCSC Mail Check | For UK public sector — includes lookup-count checks. |
spfcheck Python tool | Scriptable — integrate into CI/CD for DNS changes. |
dig plus manual counting | Free-form but error-prone; use for one-off verification. |
Automate: a simple GitHub Action or GitLab CI job that runs spfcheck against your domain weekly and posts alerts if the lookup count crosses 8 is cheap insurance.
When an audit shows you are over (or close to) the 10-lookup ceiling, three options exist. Most UK deployments end up using a combination:
include: with explicit ip4: / ip6: ranges. Removes lookup cost but adds maintenance burden.Flattening means expanding every include: to the underlying IP ranges and publishing those ranges directly as ip4: / ip6: mechanisms. Since IP mechanisms consume zero lookups, the count drops to zero regardless of how many senders you list.
# Before — 12 lookups, PermError
v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:servers.mcsv.net -all
# After — 0 lookups, success
v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:172.217.32.0/20
ip4:173.194.0.0/16 ip4:198.2.128.0/18 -allThe cost is maintenance. Every time a provider rotates an IP range — and they do, several times per year — your flattened record is out of date and legitimate mail from that provider starts failing. Manual flattening requires quarterly audits at minimum.
The simplest long-term answer is often to send from fewer services. In a typical UK SME audit, we find the organisation is sending transactional receipts from three different providers (the marketing tool's transactional arm, a separate ESP, and a legacy SendGrid account that nobody remembers setting up). Consolidating to a single transactional provider drops one or two includes from the record.
Similarly, moving away from the "every department picks its own tool" pattern — which in 2026 is often driven by security and authentication pressures rather than cost — reduces SPF complexity alongside the other benefits (single-vendor reporting, unified deliverability monitoring, one contract to negotiate).
A hosted SPF service lets you point your SPF include at a provider-maintained macro that dynamically flattens to the current IP ranges of your chosen senders. The record becomes:
v=spf1 include:spf.your-vendor.com -allOne lookup from your side. The vendor's service expands the include behind the scenes, keeping the underlying IPs current as providers rotate. Commercial UK-accessible services include those from Red Sift, Valimail, EasyDMARC, and dmarcian. Costs range from free tiers for small senders to enterprise licenses for larger organisations.
Once you have solved the immediate problem, prevent recurrence:
include:_spf.smartxhosting.uk is a centrally managed macro that covers every piece of SmartXHosting email infrastructure. When backend servers change, the macro updates automatically — no action needed on your side. This is one of the architectural advantages of using the SmartXHosting Business Email or Business Email Server rather than running your own MTA with manually-maintained IP ranges.
exists: with macros to bypass the limitRFC 7208 Section 7 allows SPF macros, and a narrow use case involves using exists: with the %{i} (sender IP) macro to look up IP-specific authorisation in a purpose-built DNS subtree. Each lookup costs 1, but you can authorise millions of IPs through a single mechanism.
exists:%{ir}.%{d}._auth.example.comThis expands to a reverse-mapped DNS query per sending IP. Few UK SMEs need this level of sophistication, but large ESPs and some public-sector bodies with dynamically expanding sender fleets deploy it.
When an organisation runs multiple domains — for example a UK holding company with subsidiary brand domains — each domain has its own independent 10-lookup budget. Splitting senders across subdomains can be a tactical move:
firm.co.uk — staff mail, 3 lookups.news.firm.co.uk — marketing sends, 2 lookups.invoices.firm.co.uk — transactional sends, 2 lookups.This isolates failure domains: a problem with one subdomain does not block the others. It also simplifies DKIM and DMARC reporting per sender type. The trade-off is increased DNS management overhead.
Some UK enterprises run separate Microsoft 365 tenants for different business units or acquired companies. A single SPF can include all of them:
v=spf1 include:spf.protection.outlook.com -allThe include covers all Microsoft tenants on the same hosting infrastructure. You do not need a tenant-specific include — Microsoft's SPF covers the whole of its Exchange Online range.
A UK business with partial US operations may use Amazon SES in both eu-west-1 and us-east-1. The canonical include:amazonses.com covers both. No region-specific includes are needed unless your IP ranges are pinned regionally for regulatory reasons.
A non-sending domain needs v=spf1 -all — a record with zero mechanisms except the terminator. Zero lookups. But note the subtle point: this record, if published accidentally on a sending domain, instantly blocks all outbound mail. Lock down DNS change workflow so a typo in the admin console cannot accidentally empty an SPF record.
A 40-person UK architectural practice hit the 10-lookup limit during a routine Mailchimp newsletter send in Q3 2025. Their SPF:
v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:_spf.salesforce.com include:servers.mcsv.net include:sendgrid.net include:_spf.pardotemail.com include:mail.intercom.io include:mailgun.org ~allThe counting tool showed 15 lookups. The immediate symptoms were Gmail, Outlook and iCloud recipients reporting that newsletter emails were going to spam. DMARC reports showed spf=permerror for every sending source.
The resolution in stages:
~all with removal of two least-active includes (Intercom and Pardot, which had not been actively used). Dropped to 11 lookups — still over.The whole recovery took four working days including investigation. Weeks of reduced newsletter deliverability preceded it. The lesson for any UK SME reading: monitor proactively, do not wait for failure to surface.
Q: Does the limit reset between different messages?
A: No — the 10-lookup count is per-evaluation-of-your-SPF-record, regardless of how many messages you send. Every receiver that checks your SPF gets the same 10-lookup budget each time, but you do not "build up" lookups across messages.
Q: Can I cache SPF results somewhere to avoid DNS cost?
A: Receivers cache DNS results per their normal TTLs, so the DNS infrastructure is not overwhelmed even if many messages arrive. The 10-lookup cap is about the one-time evaluation, not about cross-message efficiency.
Q: Is the 10-lookup limit the same across every receiver?
A: Yes — RFC 7208 makes it mandatory. Every compliant SPF evaluator enforces 10. You cannot work around it by targeting a specific receiver.
Q: If I publish two TXT records, does each get 10 lookups?
A: No — two SPF records on one domain produces PermError on its own (the "more than one SPF record" rule). The limits are not additive.
Q: What is the smallest number of lookups a typical include-based SPF actually uses?
A: For a UK freelancer on a single hosting provider, one or two lookups. For a typical SME using Microsoft 365 and one marketing platform, three to four. Anything beyond six is getting crowded; beyond eight you should actively plan flattening or consolidation.
Q: If I flatten my SPF record, how often does it need updating?
A: Depends on the flattened providers. Google Workspace flattened ranges require review every 60-90 days. Microsoft 365 less often. Smaller providers rarely change. A quarterly review is the minimum standard; automated re-flattening is better.
Q: Does the void-lookup limit apply to mechanisms other than include?
A: Yes — any DNS lookup that returns no result counts, including a, mx, exists. In practice, void lookups almost always come from stale includes or broken exists-based policies.
Q: My SPF is at 9 lookups. Am I safe?
A: Technically yes — you are under the limit. But you have one lookup of headroom and upstream providers regularly change the cost of their includes. Treat 9 as a warning; plan a flattening or consolidation within the next quarter.
Q: If I move to ARC, can I skip SPF?
A: No. ARC preserves authentication results across forwarding but does not replace SPF or DKIM. You still need SPF (or DKIM) to pass initial DMARC alignment.
Q: Can I rely on DKIM alone and publish an empty SPF?
A: Technically DMARC can pass on DKIM alone if alignment is correct. But many receivers still weight SPF in their deliverability decisions, and omitting SPF reduces redundancy. The best practice remains to publish both.
Q: Is the 10-lookup rule being relaxed in DMARCbis or future RFCs?
A: No. DMARCbis is about DMARC, not SPF, and does not change the RFC 7208 rule. The lookup ceiling has been repeatedly debated in IETF working groups and consistently retained — the DNS load argument is still valid and no alternative with the same properties has been proposed.
Q: My DNS provider's UI does not let me paste long SPF records. What should I do?
A: Most modern DNS providers handle records up to 4,000 characters through their API even if the web UI limits to 255. Use the provider's dig-style verification to confirm the record is actually in place and correctly split into multiple strings.
Q: Does publishing SPF at a wildcard (*.firm.co.uk) help with the lookup limit?
A: Not directly. Wildcard SPF avoids the need to publish a record at every subdomain, but each query for a specific subdomain still evaluates the wildcard record and counts its lookups in the usual way. Wildcards are a nameserver management convenience, not a lookup-budget saver.
Q: What happens if my flattened SPF record contains an outdated IP range and a legitimate sender's IP changes?
A: Mail from the new IP fails SPF. If your DMARC policy is at p=reject, messages are rejected outright. Recipients may bounce-notify the envelope sender, so you see delivery failures — but only for the affected sender. Remediation is to update the flattened range as soon as possible and, in future, either automate re-flattening or switch to an include-based approach for that provider.