SPF too many DNS lookups: what each ESP include costs

If a checker or your DMARC reports flag "SPF too many DNS lookups", the standard advice says you have too many email vendors and should flatten your record. We measured what each provider's include costs today. For most records, that advice points at the wrong fix.

The limit is 10 DNS lookups, not 10 vendors, and providers differ by a factor of five. Seven of them together cost less than Google Workspace, SendGrid and Mailgun.

Lookups per ESP include, measured October 22, 2026

At 17:40 UTC we queried each provider's SPF record through Google Public DNS over HTTPS and followed every nested include to the bottom. It is the same tree walk our ESP Checker runs in your browser. The number below is what one include of that host adds to your record: 1 for the include itself, plus every include, redirect, a, mx, ptr or exists term underneath it.

Provider	Include	Lookups	What's inside
Google Workspace	_spf.google.com	1	ip4 and ip6 ranges only
Microsoft 365	spf.protection.outlook.com	1	ip4 and ip6 ranges only
Mailchimp	servers.mcsv.net	1	three ip4 ranges, -all
Amazon SES	amazonses.com	1	ip4 ranges only
Postmark	spf.mtasv.net	1	four ip4 ranges, -all
Brevo	spf.brevo.com	1	ip4 ranges (legacy spf.sendinblue.com is also 1)
HubSpot	[account ID].spf0X.hubspotemail.net	1	ip4 ranges (tested with a sample ID)
Mailjet	spf.mailjet.com	1	ip4 ranges only
Mandrill	spf.mandrillapp.com	1	ip4 ranges only
Zendesk	mail.zendesk.com	1	ip4 ranges only
SendGrid	sendgrid.net	2	includes ab.sendgrid.net
Salesforce	_spf.salesforce.com	2	one exists: macro
SparkPost	_spf.sparkpostmail.com	2	one exists: macro
Zoho Mail	zohomail.com	2	includes spf.zohomail.com
Zoho (older include)	zoho.com	5	four nested includes
Mailgun	mailgun.org	5	_spf.mailgun.org, then _spf1 and _spf2, plus _spf.eu.mailgun.org

Google Workspace, the include nearly every company carries, costs 1. Plenty of the guides ranking for this error still say 4, which was true until Google flattened _spf.google.com in December 2025. Suitebriar documented that change, and our lookup confirms the record is now plain ip4 and ip6 ranges. Then Mailgun: mailgun.org includes _spf.mailgun.org, which includes two more records, and it also pulls in a separate EU record. Five lookups, half your budget, from one line.

You can re-run any row. Open dns.google/resolve?name=_spf.google.com&type=TXT in a browser and read the data field, then swap in any host from the table. Where a record contains include: or redirect=, query each target and add them up. Records change, so the date on this table matters more than usual.

What counts toward the SPF DNS lookup limit

RFC 7208, section 4.6.4, caps SPF evaluation at 10 terms that trigger a DNS query: include, a, mx, ptr, exists and the redirect modifier. ip4, ip6 and all cost nothing, because the answer is already in the record. That is why a long record full of IP ranges is cheap and a short one full of includes isn't.

Two less obvious rules catch people. An exists mechanism with a macro, which Salesforce and SparkPost both use, is one more query, so their includes cost 2 each. The same section also limits void lookups, answers that come back empty or NXDOMAIN, to two. Past either limit the result is PermError for the whole record, not a soft fail for one vendor.

PermError means SPF does not pass for any mail that depends on that record, so DMARC has to pass on DKIM alone. With aligned DKIM everywhere you can run like that for months without noticing. Then a DKIM key rotation goes wrong and there is no SPF pass behind it. Gmail and Yahoo also ask bulk senders for both SPF and DKIM, so a broken record is a compliance problem too (our bulk sender requirements guide has the details).

Why "too many DNS lookups" rarely means too many vendors

The usual rule says four or five ESPs puts you over. Our own SPF, DKIM and DMARC explainer said that until this week, and we have corrected it. Do the arithmetic from the table instead. Google Workspace, Microsoft 365, Mailchimp, Amazon SES, Postmark, Brevo and HubSpot together cost 7 lookups. Google Workspace, SendGrid and Mailgun cost 8.

Seven vendors, cheaper than three.

substack.com shows the pattern on a real domain. Its root record carries three includes, Google, Mailgun and Zendesk, and they cost 7 of the 10 lookups. Mailgun alone accounts for 5. Add a single two-lookup tool like SendGrid and that record sits at 9, one bad include away from PermError, with four vendors in it.

Old includes cost you too. Zoho's older include:zoho.com nests four records and costs 5. include:zohomail.com costs 2. If your record still carries the old one, check Zoho's current setup instructions before you touch anything else, because that swap alone gives back three lookups.

Includes you can delete from your root record

SPF checks the domain in the Return-Path, the bounce address from the SMTP MAIL FROM command, not the From address your readers see. When a platform bounces through its own domain, receivers check that platform's SPF record. The include in yours does nothing for that mail except spend a lookup.

Klaviyo says so plainly in its help center: "Klaviyo does not require you to add a mechanism to an existing SPF record." Our platform detector sees the same thing from the other side. One of the signals it uses to tag a newsletter as Klaviyo is a Return-Path on klaviyomail.com, and it tags ConvertKit (now Kit) partly on a convertkit.com Return-Path. Mail bouncing through those domains never gets checked against your root SPF. That detection is what powers our ESP Finder.

beehiiv's custom domain setup uses "three CNAME records, one for SPF and two for DKIM", per its support docs. A CNAME can't live at the root of a domain, so beehiiv's SPF sits on a subdomain and costs your root record nothing. Mailchimp campaigns bounce through Mailchimp's own mcsv.net servers, which is why Gmail shows mailed-by mcsv.net on them (we covered that in Gmail mailed-by, signed-by and via). servers.mcsv.net is the cheapest line in the table, but for those campaigns it doesn't change the SPF result.

One caution. Delete an include for a service that does put your domain in MAIL FROM and its mail starts failing SPF. So check one real message from each service first. In Gmail, open Show original and read the Return-Path line. If the domain there isn't yours, the include in your root is decoration.

A guessed include is worse than a wasted one

An unnecessary include wastes a lookup. A wrong one breaks the record. When people can't find a vendor's official value they guess, and the guesses look plausible. We tried two: _spf.klaviyo.com returns NXDOMAIN, and spf.convertkit.com exists in DNS but has no TXT record at all.

Under RFC 7208 section 5.2, an include whose target has no SPF record returns PermError, and that error belongs to your whole record. It also spends one of your two void lookups. One bad guess does more damage than three wasted includes. If you send with Kit, copy the value from your Kit dashboard, not from a forum thread.

Mailgun and Ghost: move the include to a subdomain

Every hostname gets its own SPF record and its own budget of 10. That is the cleanest fix for a heavy include. Mailgun sets up a sending domain per account and recommends a subdomain such as mg.example.com, with include:mailgun.org published there. Its 5 lookups get spent on the subdomain, and your root record keeps its budget for Google Workspace and anything that really sends as example.com.

Ghost's newsletter delivery runs on Mailgun, so a self-hosted Ghost publication inherits the same 5-lookup include. Put it on the subdomain your Ghost bulk email sends from, never the root. Amazon SES works the same way with a custom MAIL FROM domain, which SES requires to be a subdomain of your verified domain.

The cost: a subdomain is one more set of DNS records to own. SPF alignment for DMARC also holds only under relaxed alignment, the default, where mg.example.com counts as aligned with example.com. If your DMARC record sets aspf=s, SPF on the subdomain won't align and you are relying on DKIM. Our guide to email sending subdomains covers when the split pays off beyond the lookup count.

How to fix SPF too many DNS lookups, with flattening last

Flattening replaces includes with the IP ranges they resolve to. It works on the day you do it. But the ranges belong to the provider, and they change on the provider's schedule. If a provider adds a range your copy doesn't have, mail from that range fails SPF and nothing tells you.

Google's December 2025 change is the best argument against doing it by hand. The large providers are flattening their own records, which is why Google Workspace and Microsoft 365 cost 1 today. Flattening those gains you nothing. What's left is Mailgun, Zoho's older include and the exists-based records from Salesforce and SparkPost, and you can't flatten an exists macro at all, because its answer depends on the sending IP.

So here is the order we'd work in:

1. Delete includes for platforms that bounce through their own domain, such as Klaviyo, beehiiv and Mailchimp campaigns, after checking a real Return-Path.
2. Remove any include whose target returns no SPF record.
3. Swap legacy includes for current ones, like zoho.com for zohomail.com where Zoho's docs say so.
4. Move Mailgun, SES and other bulk senders to a sending subdomain.
5. Flatten what's left, and only with a service that refreshes the ranges automatically. Your SPF then depends on that vendor staying up, which is the price.

The same DNS walk works on other brands. A competitor's root record lists every tool they authorise, which is one of the signals we use to map a sender's stack, and our MailCharts comparison covers how that differs from browsing an archive of screenshots. For the manual version on a single newsletter, see how to tell which email platform a newsletter uses.

If you only do one thing today, open your record, find the heaviest include, and ask whether that provider ever puts your root domain in its Return-Path.

Frequently asked questions

How many DNS lookups does Google Workspace SPF use?

One. On October 22, 2026, _spf.google.com returned only ip4 and ip6 ranges, so include:_spf.google.com costs 1 of your 10 lookups. Until Google flattened the record in December 2025 it nested three more records and cost 4, which is why older guides still quote that number.

Does SendGrid's SPF include count as 1 or 2 lookups?

Two. include:sendgrid.net costs 1, and the sendgrid.net record includes ab.sendgrid.net, which costs another. SendGrid's domain authentication can put the bounce address on a subdomain of yours, so check the Return-Path on a real message before you keep the root include.

Do I need Mailchimp in my SPF record?

Usually not for campaigns. Mailchimp campaigns bounce through Mailchimp's own mcsv.net domain, so receivers check Mailchimp's SPF record rather than yours, and DMARC passes on the DKIM signature for your domain. include:servers.mcsv.net costs only 1 lookup, so removing it matters most when you are close to the limit.

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

Evaluation stops and the result is PermError, under RFC 7208 section 4.6.4. The error applies to the whole record, so no mail that depends on it passes SPF and DMARC has to pass on DKIM alone. An include that points at a host with no SPF record also returns PermError, under section 5.2.

Should I flatten my SPF record?

Only after pruning. Flattening copies a provider's IP ranges into your record, and the copy goes stale when the provider changes them, with no warning to you. Delete includes for platforms that bounce through their own domain, move heavy includes like Mailgun's to a sending subdomain, and flatten only what is left, with a service that refreshes the ranges automatically.

Related reading