An SPF “too many DNS lookups” result means the receiver had to make more DNS lookups than SPF permits while evaluating your record. SPF has a limit of 10 DNS-mechanism lookups during evaluation. When you exceed it, SPF can return a permanent error, which can damage authentication and sometimes delivery. The safe fix is to simplify the record without accidentally removing a legitimate sender.
Why the limit is easy to hit
Your SPF record may contain several include: mechanisms: one for Google Workspace or Microsoft 365, another for a CRM, newsletter tool, help desk, billing platform, or transactional service. Each include can lead to more nested includes and lookups. The visible line may look short while its evaluated path is not.
Start with a free Beacon domain check, then make a sender inventory. Do not delete includes merely to make the warning disappear; first establish which systems still send mail for your domain.
What counts toward the problem
Mechanisms such as include, a, mx, ptr, exists, and redirect can require DNS lookups. The exact evaluated count depends on the records each mechanism points to. A raw count of the words “include” is not enough, because vendors may nest additional mechanisms.
Do not overlook void lookups
RFC 7208 section 4.6.4 separately recommends limiting void lookups to two. A void lookup returns NXDOMAIN or a successful DNS response with no answers. Implementations may make that limit configurable; exceeding the applied limit produces permerror. It is a separate guardrail from the mandatory ten-term limit, so a record can stay below ten and still fail because of nonexistent or empty DNS targets.
Inspect the actual evaluation path for misspelled or retired targets and remove or repair only confirmed errors. ptr also counts toward the ten-term limit, although RFC 7208 discourages publishing it. The initial SPF TXT query and individual DNS packets are not the same thing as the ten DNS-causing terms being counted.
A safe repair process
- Export or copy the current SPF record before editing.
- List every active sender and confirm its official SPF instructions.
- Remove only sources that are retired and confirmed not to send.
- Replace unnecessary indirection where your provider supports a documented alternative.
- Consider SPF flattening only after understanding its maintenance tradeoff: vendor IP changes must be kept current.
- Publish one SPF record, wait for normal DNS propagation, and test real messages from each active service.
For the broader structure, read how to check an SPF record. Never create a second SPF TXT record as a workaround; multiple SPF records can themselves cause an SPF error.
Example
A business uses an inbox provider, a marketing platform, a CRM, an invoicing tool, and a support desk. Each was added over years, and several vendors’ includes contain further nested records. The owner finds that the old invoicing tool was retired and the CRM is configured to send from its own domain rather than the business domain. Removing only those obsolete entries brings the evaluated lookup count below the limit. Every remaining sender is then tested from a real message.
SPF flattening: useful, but not automatic
Flattening replaces includes with resolved IP addresses to reduce DNS lookups. It can help in a carefully managed setup, but it adds operational work: provider IP ranges can change. A stale flattened record may reject legitimate sending. It is not a copy-and-forget fix. If you use it, assign ownership and a process for keeping it current.
Test in the right order
After a repair, first confirm the published SPF record is the one you intended. Then send an actual message from each active platform to a mailbox where you can view headers. Check that SPF passes and, separately, that DKIM and DMARC remain healthy. A simple DNS lookup cannot prove that a marketing platform is using the expected envelope sender in production.
Keep the old record in your change log and record the date, provider, and tested sender. That makes rollback possible if a seldom-used billing or support system fails later. It also prevents the next administrator from reintroducing a retired include because its purpose was undocumented.
Check DKIM and DMARC too
SPF trouble does not mean you should weaken the rest of your authentication. DKIM may provide an aligned authentication result for a message, but it should not be used as an excuse to leave an SPF permanent error unresolved. DMARC gives the receiving mailbox the policy context. See SPF vs DKIM vs DMARC and authentication failure triage for the relationships.
What not to do
Do not paste an unknown “optimized” record from the web, remove your mailbox provider, or change -all to a softer ending just to mask the lookup issue. Do not assume every vendor currently configured is still active. Work from an inventory, make one controlled change, and test.
Keep the repair from returning
New senders are the usual cause of lookup creep. Require a short email-authentication review before purchasing or enabling a tool that sends from your domain. Document the reason for each SPF mechanism and monitor the domain after the cleanup so unexpected relevant changes are noticed early.
Coordinate with vendors before cleanup
If a platform is business-critical, confirm its current authentication requirements from its official support material before removing or replacing its SPF entry. Some providers use a custom return-path or a separate subdomain, while others may no longer need to send as your root domain. Make that distinction in writing, schedule the change outside a critical billing or campaign window, and keep a tested rollback path. This lets you reduce DNS lookups without guessing which service an old include represents.
Frequently asked questions
Can I have more than 10 services?
Possibly, but SPF evaluation—not just the number of services—must stay within the lookup limit. Design the authorization carefully.
Will changing SPF fix spam immediately?
It fixes a technical failure after DNS updates propagate. Inbox placement also depends on DKIM, DMARC, reputation, and recipient expectations.