Authentication
SPF allows 10 lookups. We counted what 18 email services use: Google 1, Freshdesk 7
SPF gives your domain 10 DNS lookups, and the one line you paste for a new email tool can spend more than one of them. We counted 18 of those lines from live DNS: Google Workspace costs 1, not the 4 many guides still quote, and Freshdesk costs 7.
You add a helpdesk, or a newsletter tool, and its setup page says to put one more include: in your SPF record. It looks like one small addition. It might be, or it might be most of what you have left, and nothing warns you when you go over. Mail keeps leaving. The DNS screen stays green.
Our SPF explainer covers what the record is for. This one answers a narrower question: how many of the 10 does each service use, and how close are real domains to the limit?
How we counted
- The rule: RFC 7208, section 4.6.4.
include,a,mx,ptr,existsandredirecteach cost one, and the ones inside an include count too.ip4,ip6andallare free. - The services: 18 whose include we could find on the vendor's own page or in Google's setup help. Each name in the table below links to that page. We left out services whose include we could only find on third-party blogs.
- The domains: the 188 with a mail server in the first 300 of the Tranco list, the same file we used for our DMARC count.
- When and how: 4 November 2026, 05:53 to 05:55 UTC, asking 1.1.1.1 and 8.8.8.8 separately. We sent no email. The two resolvers agreed on every service and on 187 of the 188 domains. The odd one out, hichina.com, publishes two SPF records, which is an error all by itself, so we left it out of the counts below.
What one line costs
| Service | Lookups | What you add | Why |
|---|---|---|---|
| Freshdesk | 7 | include:email.freshdesk.com | SendGrid inside (2), plus four regional records |
| Mailgun | 5 | include:mailgun.org | Its US and EU records together |
| iCloud custom domain | 5 | include:icloud.com | A redirect, then three more records |
| Namecheap Private Email | 4 | include:spf.privateemail.com | Three records underneath |
| GoDaddy | 3 | include:secureserver.net | Microsoft's record is one of its two |
| Proton Mail | 2 | include:_spf.protonmail.ch | |
| Salesforce | 2 | include:_spf.salesforce.com | At least 2: one part can only be read with a real email |
| SendGrid | 2 | include:sendgrid.net | |
| Zoho Mail | 2 | include:zohomail.com | |
| Amazon SES | 1 | include:amazonses.com | |
| Fastmail | 1 | include:spf.messagingengine.com | |
| Google Workspace | 1 | include:_spf.google.com | Plain address ranges, nothing nested |
| Mailchimp | 1 | include:servers.mcsv.net | |
| Mailjet | 1 | include:spf.mailjet.com | |
| Microsoft 365 | 1 | include:spf.protection.outlook.com | |
| Postmark | 1 | include:spf.mtasv.net | |
| Shopify | 1 | include:shops.shopify.com | |
| Zendesk | 1 | include:mail.zendesk.com |
The line you paste counts as one, so the lowest possible score is 1. Nine of the 18 sit there.
These are one morning's numbers. Vendors edit these records without telling anyone, and Google is the proof. Guides, including one dated March 2026, count _spf.google.com as 4, because it pointed at three _netblocks records. We asked Google's own name server to be sure: today it lists its address ranges directly, so it costs 1. If a guide or an old spreadsheet tells you Google takes 4, your budget may be better than you think.
Google's help page also puts the limit as "up to 10 include: tags". That's a fair shorthand for a simple record, but the tags aren't what gets counted. Freshdesk's single tag spends 7.
It adds up faster with some tools than others
| What the business uses | The sum | Lookups |
|---|---|---|
| Google Workspace, Mailchimp, SendGrid, Zendesk, Shopify | 1 + 1 + 2 + 1 + 1 | 6, plenty of room |
| iCloud custom domain, Mailgun | 5 + 5 | 10, full with two lines |
| Namecheap Private Email, Freshdesk | 4 + 7 | 11, over with two lines |
Five tools can fit in 6 lookups while two can go over. The number of lines in your record tells you very little.

How close real domains get
Of the 188 domains, 12 have no SPF record at all. Here are the 175 that have one good record:
| Lookups in the SPF record | Domains (of 175) | Some of them |
|---|---|---|
| 0 to 3 | 89 | google.com (1), outlook.com (1), linkedin.com (2), apple.com (2) |
| 4 to 6 | 44 | amazon.com (4), microsoft.com (6), zoom.us (6) |
| 7 or 8 | 26 | netflix.com (7), openai.com (7), dropbox.com (7) |
| 9 or 10 | 13 | github.com (10), ebay.com (10), oracle.com (10), mit.edu (10), paypal.com (9), canva.com (9) |
| More than 10 | 3 | who.int (17), applovin.com (15), iiko.it (15) |
The median is 3, so most domains are nowhere near trouble. But 16 of the 175 are within one lookup of the limit or past it, and 7 sit at exactly 10, where the next tool anyone adds breaks the record. 44 of the 175 use a macro somewhere, a part that can only be followed with a real email in hand. We counted each of those as one, so their real totals can be a little higher.
What going over actually does
The answer is less dramatic than "all your mail fails", and sneakier. Receivers read an SPF record left to right and stop at the first match. The limit only bites if they get that far. So we ran the over-limit domains through pyspf, a separate SPF library, with one address listed early in each record and one listed nowhere (192.0.2.1, an address reserved for examples), with github.com for comparison:
| The sending server | who.int (17) | applovin.com (15) | iiko.it (15) | github.com (10) |
|---|---|---|---|---|
| Listed early in the record | pass | pass | pass | pass |
| Listed nowhere | permerror | permerror | permerror | softfail, the normal answer |
- A server near the front still passes. That is why nobody notices. Your main mailbox provider is probably first in line, and its mail looks fine.
- A server after the tenth lookup is never reached. The receiver gets a permanent error instead of a pass, and it is usually your newest tool that pays, because that's the line you added last.
- A fake gets an error, not a fail. On who.int and applovin.com, the listed-nowhere address hit the lookup limit. On iiko.it it hit a second limit first, two lookups that come back empty. 10 is still fine: github.com gave its normal answer.
- DKIM can save you, for DMARC at least. DMARC passes if either SPF or DKIM passes and matches your domain, so an aligned DKIM signature still gets the mail through that check. It doesn't fix the record.
A limit on this test: pyspf is one library and we sent no real mail. How each receiver treats a permanent error is up to the receiver.
Getting back under 10
- Delete the tools you left. The old newsletter tool, the helpdesk from two years ago. This is free and it is often enough.
- Check whether the include does anything. Many senders use their own bounce address, and SPF is checked against that, not your From line. Postmark says outright that its include is no longer required and does nothing on your root domain. Amazon SES passes SPF on its own default domain. dmarcian makes the same case for Mailchimp and suggests removing the line. Read the current setup page for your tool, make sure its DKIM is on, and then remove the line.
- Give a heavy sender a subdomain.
news.yourshop.comhas its own SPF record and its own 10. This suits newsletters and app mail, and it keeps their reputation apart from your everyday mail too. - Flatten only as a last resort. Flattening means pasting a vendor's addresses straight into your record. Google did it to its own record and went from 4 to 1, but Google owns those addresses. When a vendor changes theirs, your copy goes stale and nobody tells you.
Count your own
Go through your record by hand with the rule above, or run this. It follows includes and redirects and gave the same totals as our full counter on google.com (1), github.com (10), who.int (17) and applovin.com (15):
# pip install dnspython
import sys
import dns.resolver
def spf(name):
try:
for r in dns.resolver.resolve(name, "TXT"):
text = b"".join(r.strings).decode()
if text.lower().startswith("v=spf1"):
return text
except dns.exception.DNSException:
pass
return ""
def count(name):
total = 0
for term in spf(name).split()[1:]:
t = term.lstrip("+-~?").lower()
if t.startswith(("include:", "redirect=")):
total += 1 + count(term.split(":" if ":" in term else "=", 1)[1])
elif t.split(":")[0].split("/")[0] in ("a", "mx", "ptr", "exists"):
total += 1
return total
print(count(sys.argv[1]))Save it as spfcount.py, then run python spfcount.py yourdomain.com.
To read the record itself, along with DMARC and DKIM, put any address on your domain into our deep email check. It shows the full SPF record and its ending, as in the screenshot above, and sends nothing. It doesn't add up the lookups for you yet, which is why the script is here. And if all you need is sign-in codes from an app, sending through email59 from an @email59.com address spends none of your 10, because your domain isn't involved.
The short version
- Of 18 services, 9 cost 1 lookup. Freshdesk costs 7, iCloud and Mailgun 5, Namecheap Private Email 4.
- Google Workspace now costs 1, not the 4 older guides give.
- Of 175 busy domains, the median is 3, 7 sit at exactly 10 and 3 are over.
- Over the limit, servers near the front of the record still pass, which is why it goes unnoticed. The ones after the tenth lookup aren't reached.
- Remove tools you left and includes your senders don't need, then move heavy senders to a subdomain, before you flatten anything.
Sources
- RFC 7208, SPF (sections 4.6.2 and 4.6.4)
- RFC 7489, DMARC
- Google Workspace, Set up SPF (also the source for the GoDaddy, Amazon SES, Mailchimp, Salesforce and Shopify includes)
- Tranco top-sites list GQ3LK (first 300 rows)
- The vendor pages linked from the first table, read on 4 November 2026.
- Our own count: one row per service and domain, from 1.1.1.1 and 8.8.8.8, 4 November 2026, 05:53 to 05:55 UTC.