SPF Records and Subdomains: How to Stay Under the 10-Lookup Limit

You add a newsletter tool to your store, and it asks you to put one more include: into your SPF record. A month earlier it was your email host, before that a transactional mail service. Now a checker tells you the record has a permanent error for exceeding the DNS lookup limit, and your order confirmations are landing in spam. Nothing looks broken in WordPress. The problem is a single line of DNS text that has quietly grown past what the standard allows.

This guide answers the two questions that come up first when that happens: whether subdomains need their own SPF record, and how to get a record back under the ten-lookup limit without breaking any of the services that send mail for you. I queried the records of several common senders on 4 October 2026 to put real lookup costs in the table below, because most guides still quote old numbers.

Do subdomains need their own SPF record?

If a subdomain sends email, yes. If it never sends email, give it a record that says so. SPF is not inherited. A receiving server checks the exact domain in the message’s envelope sender, and if that name has no SPF record, the result is simply “none”. It does not fall back to the record on your main domain. The standard, RFC 7208, describes that “none” outcome in section 4.3.

That gives you three cases to sort every subdomain into:

• It sends mail. A shop at shop.example.com, a newsletter at news.example.com. Publish a separate TXT record on that name listing only the services that send from it.
• It never sends mail. Most subdomains. Publish v=spf1 -all on it, which tells receivers that no server is allowed to send as that name. This closes the door on someone forging mail from anything.example.com to your customers.
• A sending service uses its own bounce address. Many providers ask you to add a CNAME on a subdomain such as bounces.example.com. The SPF check for that provider’s mail then runs against that name, not your root domain. The record you edit by hand on the root domain is not the one being tested for those messages.

One related point causes confusion. DMARC has its own subdomain setting, the sp tag, but it controls what receivers do with failing mail. It does not copy your SPF record down to the subdomains, so setting it does not replace the records above.

How the ten-lookup limit works

To evaluate an SPF record, the receiving server has to run DNS queries for some of its terms. RFC 7208 section 4.6.4 caps that at ten. Go over, and the result is a permanent error, which means the SPF check does not pass for that message.

Term in the record	Counts toward the limit of 10?
include:	Yes, plus every lookup inside the included record
a and mx	Yes, one each
redirect=	Yes
exists: and ptr	Yes (and the standard says ptr should not be published at all)
ip4: and ip6:	No
all	No

Two more rules sit next to it. There is a second, quieter cap: the standard recommends allowing no more than two lookups that come back empty (a name that does not exist or has no answer), and a receiver that follows it returns the same permanent error. And a domain may publish only one SPF record. Two separate TXT records that both start with v=spf1 produce a permanent error too, which is why the habit of pasting a provider’s snippet on a new line instead of merging it is so damaging.

What common senders really cost

The cost of an include: is one lookup for the include itself, plus however many lookups the provider’s record contains inside. These are the figures I got by querying each record on 4 October 2026:

Include	Total lookups it costs
include:_spf.google.com (Google Workspace)	1
include:spf.protection.outlook.com (Microsoft 365)	1
include:servers.mcsv.net (Mailchimp)	1
include:sendgrid.net (SendGrid)	2
include:_spf.mail.hostinger.com (Hostinger email)	3
include:spf.web-hosting.com (Namecheap shared hosting)	7

Two things stand out. First, older guides say Google Workspace costs four lookups, because its record used to chain through three more includes. When I queried it, the record listed its address ranges directly, with nothing nested. Second, a single hosting include can eat most of your budget. The Namecheap one alone uses seven of the ten.

Providers change these records without telling anyone, so treat the table as a snapshot and check your own set before relying on it. For reference, the SPF record on this site is a single include to our email host, which costs three lookups.

A store that went over without noticing

Here is how a perfectly ordinary setup breaks. A store on Namecheap shared hosting sends order emails from WordPress through the host, uses Google Workspace for staff mail, sends a newsletter through Mailchimp, and added SendGrid for transactional mail. The record reads:

v=spf1 include:spf.web-hosting.com include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

Add it up: 7 + 1 + 1 + 2 is eleven. One over the limit, so the whole record fails, including for the services that were fine on their own. Every message is affected, not just the one from the newest tool.

Count your own record

You do not need a paid tool. Look up your record, then add up the includes using the costs above or by looking each one up the same way.

nslookup -type=TXT example.com
dig +short TXT example.com

The first works on Windows, macOS and Linux. The second needs dig, which most Mac and Linux machines have. Run it again on every include name in your record to see what it contains. Free web checkers such as MXToolbox’s SPF lookup do the same recursion for you and show the total, which is quicker if you have more than three includes.

Cleaning up a bloated record, in order

1. Find out who really sends mail for you. Send a test message from each system (a WordPress form, a store order, the newsletter) to a Gmail address, open the message, choose “Show original” and read the SPF line in the authentication results. This tells you which sender is actually being authorised by which part of the record. It is much more reliable than trusting a list of services someone added years ago.
2. Delete the includes of services you no longer use. Old newsletter tools and abandoned contact-form services are the usual leftovers. Each one costs lookups for nothing.
3. Remove ptr. The standard says it should not be published, and it is slow and unreliable.
4. Replace a and mx with fixed addresses if your server never changes. An ip4: entry costs nothing. Only do this if you are sure the address is stable; a host that moves your site to a new server will break it silently.
5. Move a heavy sender to a subdomain. If your provider lets you set a custom sending domain, send the newsletter from news.example.com and give that name its own record. Each name gets its own budget of ten, so this is the cleanest long-term fix, and it keeps your newsletter’s sending reputation separate from your store email.
6. Treat flattening as the last resort. Flattening replaces includes with the provider’s raw IP addresses so the lookup count drops to zero. The risk is that providers change their addresses, and a flattened record does not follow them. Several email-security vendors, including Mailhardener, publish guidance against doing it by hand. If you must flatten, use a service that re-publishes the record automatically, and not a one-off copy-paste.

After each change, wait for the DNS cache to expire (your record’s TTL, often 30 minutes to a few hours), send another test message and check the authentication results again. Change one thing at a time so you know which edit caused any new failure.

Mistakes that keep SPF broken

• Editing DNS in the wrong place. The records that count are at whoever your domain’s nameservers point to. If your domain is registered with one company but uses Cloudflare or your host for DNS, an edit at the registrar changes nothing.
• Two SPF records instead of one. Always merge new includes into the existing record.
• Forgetting a sending subdomain. Mail from shop.example.com is checked against that name, not example.com.
• Jumping to -all too early. The ~all ending marks unlisted senders as a soft failure. Move to -all only once your test messages from every system pass.
• Long records pasted as one string. A single DNS text string is limited to 255 characters. Most DNS panels split a longer record for you, but if yours does not, the record can silently break.

A ten-minute audit to run this week

Pull up the record for your main domain and write down every include with its cost. If the total is eight or more, you are one new tool away from a failure, so tidy it now, while you can still test calmly. Then list every subdomain that sends mail and confirm each has its own record, and give one v=spf1 -all record to the ones that never send anything. If you only do one thing, send a test message from each system to Gmail and read the SPF result: a pass on all of them means the record is healthy today, and a fail tells you exactly which sender to fix first.