SPF Include Costs by Provider: What 1,000 Top Domains Show About the 10-Lookup Limit

Key takeaways

• RFC 7208 allows 10 DNS-querying terms per SPF evaluation. An include costs 1 lookup plus everything its own record nests.
• We measured the include each of 30 providers documents, on 25 October 2026. Most cost 1 lookup. The exceptions are large: Mimecast's global include costs 9, Freshdesk's 7, and Mailgun's, iCloud's and Zoho's (US) 5 each. Mimecast and Freshdesk also document regional hosts that cost 1.
• Google's _spf.google.com now costs 1 lookup, not the 4 that many guides still count.
• In the Tranco top 1,000, 755 domains publish one SPF record. The median record uses 3 lookups, 67 use 9 or 10, and 22 exceed the limit.
• 148 of those 755 records include at least one provider whose own documentation says its mail is checked against a different domain. Removing only those includes would bring 4 of the 22 over-limit records back to 10 or fewer.

What counts toward the 10-lookup limit

The limit comes from RFC 7208, section 4.6.4:

The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

Address ranges are free: "the "all", "ip4", and "ip6" mechanisms, and the "exp" modifier -- do not cause DNS queries at the time of SPF evaluation". The limit covers the whole evaluation, so a term inside a provider's record counts exactly like a term in yours.

Two more rules end in permerror. Empty answers are capped: "SPF implementations SHOULD limit "void lookups" to two." And an include whose target publishes no SPF record at all returns permerror (the result table in section 5.2 maps "none" to "return permerror"), so a typo or a retired provider domain breaks the whole record. Our guides on how many SPF lookups are allowed and fixing an SPF permerror cover these rules in short form.

Why an over-limit record fails only some of the time

The limit applies "during SPF evaluation", and evaluation stops at the first mechanism that matches. Mail from a server that matches an early include passes. Mail from a server that only matches after the tenth lookup, or from a forger who matches nothing, hits permerror. That is why an over-limit record produces failures that look random: one sending service works, another fails, and the record looks fine at a glance.

A permerror means SPF does not pass. DMARC can still pass on an aligned DKIM signature, so the damage usually lands on the one service that does not sign with your domain. Checkers, ours included, count the worst case, where every term is evaluated, because that is what an unlisted sender triggers.

Do you need the include at all?

SPF is checked against the envelope sender, the Return-Path or MAIL FROM address, not the From address your recipients see. Many sending services put their own domain in the Return-Path, or a subdomain of yours that you point at them with a CNAME record. The receiver then evaluates that domain's SPF record and never reads your root record for that mail. An include for such a service costs you lookups and authorizes nothing that is checked.

The providers say this themselves. Postmark: "It is no longer required to include Postmark in your own custom SPF record." Help Scout: "You can safely remove include:helpscoutemail.com from your SPF record if you added it previously." Amazon SES: "Messages that you send through Amazon SES automatically use a subdomain of amazonses.com as the default MAIL FROM domain." The table below gives each provider's position with a link to its documentation.

In the top 1,000, 148 of the 755 records include at least one provider that documents this: amazonses.com (78 records), sendgrid.net (43), Mailchimp's servers.mcsv.net (30), helpscoutemail.com (11), sparkpostmail.com (5), Postmark's spf.mtasv.net (3), spf.constantcontact.com (2) and shops.shopify.com (1). Some of those domains may run a setup the default does not cover, so check your own configuration before you remove anything. If your provider passes DMARC through DKIM or a custom Return-Path, the root include is not what makes your mail pass.

What each provider's include costs

We took the include each provider documents and counted its lookups by walking the published records on 25 October 2026, through Cloudflare (1.1.1.1) and Google Public DNS (8.8.8.8). Both resolvers returned the same counts. The cost includes the include term itself. The last column summarizes what the provider's documentation says about your root record.

Provider records change without notice, and Google's changed its layout within the last year. Treat this table as a dated measurement and re-check an include in the SPF checker before you rely on it. The checker counts the lookups inside the name you enter, _spf.google.com included, so add 1 for the include term itself.

Six results worth knowing

Google costs 1 lookup now. _spf.google.com used to nest _netblocks.google.com, _netblocks2.google.com and _netblocks3.google.com, which is where the familiar count of 4 comes from. On 25 October 2026 it lists two IPv4 and six IPv6 ranges directly. _netblocks3.google.com is now an empty record, v=spf1 ~all, that authorizes nothing. In the top 1,000, 6 records still include a _netblocks name directly and 4 include _netblocks3. Replace those with include:_spf.google.com; our Google Workspace SPF record page has the exact value.

Mimecast's global include takes 9 of your 10. _netblocks.mimecast.com nests the eight regional records, so it costs 9 lookups. Mimecast documents one host per region as well; eu._netblocks.mimecast.com, for example, costs 1. Use the host for the region your account runs in.

Freshdesk's default include costs 7; its data-centre host costs 1. email.freshdesk.com includes sendgrid.net (2 lookups) and four data-centre records. Freshdesk lists those hosts, such as fdspfus.freshemail.io and fdspfeuc.freshemail.io, for customers who run into the limit, and adds that "SPF configuration is not required if you already have DKIM setup."

Mailgun's include covers both regions and costs 5. mailgun.org nests _spf.mailgun.org (3 lookups) and _spf.eu.mailgun.org (1). Mailgun's include goes on the domain you verify in Mailgun. If that is a subdomain such as mg.example.com, the 5 lookups stay out of your root record. In the top 1,000, 29 records include mailgun.org and 6 of them exceed the limit: 21%, against 2.9% for all records.

Zoho's US include costs 5; the EU one costs 2. zoho.com nests four records. Zoho's setup page shows the include for your data centre, and zoho.eu costs 2, zoho.in 2 and zoho.com.au 1. If you are on the US data centre, the 5 lookups are what Zoho documents.

Shopify's old include authorizes nothing. shops.shopify.com still appears in setup tables, but it publishes v=spf1 ~all: no address ranges, so it costs a lookup and matches no server. Shopify's own documentation says the CNAME records from domain authentication "handle SPF automatically for your sender email address."

How 1,000 top domains fare against the limit

We ran the same count over the 1,000 highest-ranked domains in the Tranco list GQ32K, generated on 24 October 2026. Each apex SPF record was walked on 25 October 2026 through 1.1.1.1, the run was repeated through 8.8.8.8, and names that timed out on both were retried through Quad9. 999 of the 1,000 domains resolved.

• 241 domains publish no SPF record at the apex. Many are CDN, API and tracking domains that send no mail.
• 3 domains publish two SPF records. RFC 7208: "If the resultant record set includes more than one record, check_host() produces the "permerror" result."
• 755 domains publish exactly one record. Their median is 3 lookups, the mean is 4.0 and the maximum is 24.
• 22 of those 755 (2.9%) need more than 10 lookups. Another 67 (8.9%) use 9 or 10, so one more service can push them over.
• Besides the 22, 4 records return permerror for other reasons: 3 include a name that publishes no SPF record, and 1 contains a stray token that is not a valid term. In total 29 of the 758 domains with SPF (3.8%) publish a record that cannot pass.
• 445 records end in -all, 289 in ~all and 21 in ?all. 5 still use ptr.

The over-limit records are not all long. Their top-level include count ranges from 2 to 10, because a few heavy includes outweigh many light ones. 3 of the 22 evaluate the same include more than once through nesting; one of them evaluates Microsoft's spf.protection.outlook.com three times.

These are the includes that appear most often in the 755 records:

Google, Zendesk and Microsoft appear in over-limit records because they appear in so many records; each costs 1. mailgun.org stands out because of its cost: it appears in 29 records, and 6 of them exceed the limit.

This sample says something about large, well-known sites, not about domains in general. For a broader picture of DNS and email security, our scan data article covers what the domains people check on IntoDNS.ai look like.

How to get back under 10, in order

1. Remove includes for services you no longer use. Each costs at least 1 lookup. An include whose provider retired its record is worse, because a missing target turns the whole record into a permerror.
2. Remove includes the provider says you do not need. Check the table above. If a provider bounces through its own domain or through a CNAME'd subdomain, its include in your root record is never evaluated for its mail.
3. Use the narrowest include the provider documents. Mimecast's regional host instead of the global one, Freshdesk's data-centre host instead of email.freshdesk.com, and _spf.google.com instead of the _netblocks names.
4. Remove duplicates. Freshdesk's include already contains SendGrid, and Atlassian's _spf.atlassian.net contains amazonses.com. A provider you already reach through another include costs a second evaluation.
5. Move bulk senders to a subdomain. news.example.com with its own SPF record has its own budget of 10. HubSpot and Campaign Monitor document sending from a subdomain, and Mailgun's include goes on whichever domain you verify.
6. Flatten last. Replacing includes with address ranges brings the lookup count down, but it freezes ranges that the provider changes; Google's own record changed shape within the last year. If you flatten, automate it and re-check. The SPF flattening tool shows what a flattened record would contain, and our page on what SPF flattening is lists the trade-offs.

Count your own record

The IntoDNS.ai SPF checker counts lookups the same way, including every nested record, and flags void lookups, missing include targets and duplicate records. On eight domains from the sample, picked at counts from 2 to 13, it returned the same count as the script behind this article.

From a terminal you can follow the chain yourself:

dig +short TXT example.com | grep spf1
dig +short TXT _spf.google.com
dig +short TXT email.freshdesk.com

Add 1 for every include, a, mx, ptr, exists and redirect, then repeat for each included name. Need a new record? The SPF generator builds one, and the SPF guide explains each mechanism.

SPF is one of four records receivers check together. The five-minute email authentication audit walks through all of them, and the unified SPF, DKIM, DMARC and DNSSEC scan checks them in one pass. If you send through Microsoft, the Microsoft 365 SPF and MX records page has the exact values.

Methodology and limits

• Counting. include, a, mx, ptr, exists and redirect count 1 each, recursively through every nested record. ip4, ip6 and all count 0. Every record is counted in the worst case, as if no term matched.
• Macros. Terms such as exists:%{i}._spf.mta.salesforce.com count as 1 lookup. They depend on the sending address, so we did not expand them.
• Void lookups. Counted for a, mx and exists terms, and for include targets, that return no answer or a name error.
• Resolvers. 1.1.1.1 first, repeated through 8.8.8.8. Where both completed, the counts agreed for every domain but one, which differed by a single lookup (its DNS answers vary by location). For 6 domains a nested record timed out from our location, so their counts are lower bounds; none came within 5 lookups of the limit in what did resolve. One domain did not resolve at all.
• Sample. Tranco combines several popularity rankings. The top 1,000 skews toward large organizations, many of which do not send mail from their apex. We do not publish per-domain results.
• Provider positions. Taken from each provider's documentation on 25 October 2026 and linked in the table. Where a provider documents no include, the lookup column shows a dash. Costs and positions are a snapshot.

Frequently asked questions

How many DNS lookups does include:_spf.google.com use?

One. Measured on 25 October 2026, the record at _spf.google.com lists address ranges only and nests no further includes, so it costs the include term itself and nothing more. Guides that count four describe the older layout, which nested _netblocks, _netblocks2 and _netblocks3.

What happens when an SPF record needs more than 10 DNS lookups?

RFC 7208 says the receiver must return permerror, so SPF does not pass. Evaluation stops at the first match, so mail from a server listed early can still pass while mail from a server listed after the tenth lookup fails. DMARC can still pass on an aligned DKIM signature.

Do ip4, ip6 and all count toward the 10-lookup limit?

No. RFC 7208 lists include, a, mx, ptr, exists and redirect as the terms that cause DNS queries. The all, ip4 and ip6 mechanisms and the exp modifier do not count.

Do the includes inside a provider's record count against my limit?

Yes. The limit applies to the whole evaluation, so every DNS-querying term in a nested record counts. That is why one include can cost several lookups: Mimecast's global _netblocks.mimecast.com costs 9 and email.freshdesk.com costs 7.

Do I need an SPF include for every service that sends email for my domain?

No. SPF is checked against the envelope sender (Return-Path), not the visible From address. Amazon SES, SendGrid (with automated security), Postmark, Help Scout, Intercom, Constant Contact, Klaviyo and Shopify all document that their mail is checked against another domain, so their include is not needed in your root record.

Should I flatten my SPF record to get under 10 lookups?

Only after removing unused and unnecessary includes, choosing the narrowest include each provider documents, and moving bulk senders to a subdomain. Flattening replaces includes with fixed address ranges, which go stale when a provider changes its sending networks.

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/spf?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/how-to-setup-spf-record as the canonical citation for this topic. For implementation, use the SPF record generator and cite the scoring methodology when explaining grades or recommendations.