What the limit actually is
RFC 7208 section 4.6.4 lists the terms that cause DNS queries: the include, a, mx, ptr and exists mechanisms and the redirect modifier. Implementations must limit the total of those terms to 10, and if the limit is exceeded they must return permerror. [1] The count is a single global limit across all nested evaluations, so an include that itself contains includes costs more than one. [1]
The terms all, ip4, ip6 and exp do not count. [1] Separately, each mx term may resolve no more than 10 address records, and implementations should stop after two void lookups (lookups that return nothing). [1]
Google's troubleshooting page puts it plainly: complex SPF records that include several third-party services can exceed the limit, and nested domains count. [2]
Count the lookups in a worked record
Here is an illustrative record for example.com. The Google, Microsoft, SendGrid and Salesforce values are real include targets whose current records we resolved on October 29, 2026; the three example- entries are placeholders for typical small-business tools, each assumed to cost one lookup. [4] [5] [6] [7]
v=spf1 a mx include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com include:spf.example-crm.net include:spf.example-helpdesk.net include:spf.example-invoices.net ~all
| Term | Lookups | Why |
|---|---|---|
| a | 1 | Counts as a lookup term [1] |
| mx | 1 | Counts as a lookup term; its address lookups are capped separately [1] |
| include:_spf.google.com | 1 | Its record currently holds only ip4 and ip6 ranges [4] |
| include:spf.protection.outlook.com | 1 | Its record currently holds only ip4 and ip6 ranges [5] |
| include:sendgrid.net | 2 | Its record contains include:ab.sendgrid.net, which holds only ip4 ranges [6] |
| include:_spf.salesforce.com | 2 | Its record uses an exists mechanism, which also counts [1] [7] |
| Three placeholder includes | 3 | Assumed one each |
| Total | 11 | One over the limit: permerror [1] |
Safe fixes, in the order to try them
These keep SPF dynamic, so vendors can change their IP ranges without breaking your record.
- Remove includes for services that no longer send for you, and remove duplicate mechanisms or ones that refer to the same domain. Google lists both as fixes. [2] In the example, a business that moved from Microsoft 365 to Google Workspace drops include:spf.protection.outlook.com: 10 lookups.
- Drop a and mx if your website host and inbound mail servers do not send mail as your domain. Removing a takes the example to 9, which leaves headroom.
- Ask each vendor whether its include is needed at all. SPF is checked against the envelope sender (MAIL FROM) domain [1]; if a service uses its own bounce domain, its include in your root record may not help your DMARC result, which can pass through aligned DKIM instead.
- Move a sender to a subdomain such as news.example.com or billing.example.com. Google says each subdomain you send from needs its own SPF record, which gives that subdomain its own 10-lookup budget. [3]
- Recount after every change and check the result in your DMARC aggregate reports before removing anything else.
Risky fixes: flattening and hand-written IP lists
Flattening replaces include terms with the ip4 and ip6 ranges they currently resolve to. It removes lookups, but you take over a job the vendor was doing: if they add an IP range and you do not update your record, their mail from that range fails SPF.
Google's guidance points at the other costs: SPF strings have a 255-character limit when you add ip4 and ip6 mechanisms, and you should avoid broad, shared IP ranges in favor of fixed, assigned addresses. [2] The sendgrid.net record alone listed 11 ip4 ranges when we resolved it. [6]
| Fix | Lookups saved | Ongoing maintenance | Risk |
|---|---|---|---|
| Remove unused include | 1 or more | None | Low, if the service truly stopped sending |
| Drop a or mx | 1 each | None | Low, if those hosts never send mail |
| Subdomain per sender | All of that sender's lookups | One more record to manage [3] | Low; From address changes for that mail |
| Flatten to IP ranges | Up to all | Track every vendor's IP changes | High: silent failures when ranges change |
| Publish a second SPF record | None | None | Breaks SPF; one record per domain [2] |
Check your record before and after
Google suggests the Check MX tool in the Google Admin Toolbox to count lookups. [2] You can also count by hand: resolve your TXT record, then resolve each include target and add any include, a, mx, ptr, exists or redirect terms you find inside it.
- Lower the record TTL a day before editing if your DNS host allows it.
- Edit the existing SPF record rather than adding a new one. [2]
- Allow time for the change: Google says SPF changes can take 24 to 48 hours to take effect globally. [2]
- Send a test from each service and look for spf=pass in the Authentication-Results header.
- Watch your next week of DMARC aggregate reports for new SPF failures by source IP.
Questions before you decide
Do ip4 and ip6 count toward the limit?
No. RFC 7208 says all, ip4, ip6 and the exp modifier do not cause DNS queries at evaluation time and are not subject to the limit.
Do nested includes count?
Yes. The limit is tracked as one global count for the whole evaluation, so includes inside includes add to your total. Google's help says the other domains count toward your limit.
Can I publish two SPF records to split the lookups?
No. Google says each domain can have only one SPF record and that multiple SPF records can send mail to spam. Merge them into one.
What is a void lookup?
A lookup that returns no records. RFC 7208 says implementations should limit void lookups to two, and exceeding that produces permerror, so remove includes that point at names that no longer exist.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- RFC 7208: Sender Policy Framework (SPF) Accessed 29 Oct 2026
- Google Workspace Admin Help: Troubleshoot SPF issues Accessed 29 Oct 2026
- Google Workspace Admin Help: Set up SPF Accessed 29 Oct 2026
- Google Public DNS lookup: _spf.google.com TXT Accessed 29 Oct 2026
- Google Public DNS lookup: spf.protection.outlook.com TXT Accessed 29 Oct 2026
- Google Public DNS lookup: sendgrid.net TXT Accessed 29 Oct 2026
- Google Public DNS lookup: _spf.salesforce.com TXT Accessed 29 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.