Introduction
If you are seeing “SPF PermError: too many DNS lookups,” your SPF record is usually over the evaluation limit. This often happens when multiple services are stacked into one SPF record, such as marketing, transactional, CRM, and helpdesk providers, and the receiver has to perform too many DNS queries to finish SPF evaluation.
This guide is for SaaS and development teams sending transactional email who want a safe and repeatable fix. It explains what counts toward the SPF lookup limit, how to measure your current lookup budget, and how to reduce it without breaking production. The lowest-risk fixes come first, including removing unused includes, replacing some lookups with ip4 or ip6, and splitting streams across subdomains. Then it covers when SPF flattening is the right choice.
SPF flattening can work well, but it is not a one-time fix. The main risk is drift, because vendors can change IP ranges over time. Before making updates, use the Mailcub documentation to confirm you are editing the correct sending domain DNS record.
Quick Answer
- SPF evaluation has a lookup limit, and if you exceed it, receivers can return a permerror.
- Count lookup-causing terms such as include, a, mx, ptr, exists, and redirect.
- Remove unused vendors and duplicate includes first because this is the fastest and lowest-risk fix.
- Use ip4 or ip6 for stable infrastructure to avoid DNS lookups during SPF evaluation.
- Split marketing and transactional streams across subdomains to keep SPF records smaller.
- Use SPF flattening only if you can keep flattened IP ranges updated.
Why This Matters
An SPF permerror can cause authentication to fail at the receiving server. Depending on mailbox policy, that can lead to stronger filtering, quarantine, or rejection.
For transactional email, this becomes a product reliability issue. Password resets, OTPs, and other critical messages can fail, which creates support load and user frustration. Fixing SPF lookup issues also makes troubleshooting much faster because your team can follow a clear process instead of guessing.
When SPF Flattening Is the Right Fix
SPF flattening replaces lookup-heavy mechanisms, usually include chains, with the underlying ip4 or ip6 ranges. This lowers DNS queries during SPF evaluation.
Flattening is a good option when cleanup and subdomain splits are not enough to get under the lookup limit. It can also work well when the vendor’s sending IP ranges are stable and you have a process to keep the flattened record updated.
Avoid flattening if you cannot maintain it. If the flattened list becomes stale, legitimate mail may fail SPF later.
Step-by-Step SPF Flattening Workflow
1) Find the SPF record that is actually evaluated
First, confirm the exact hostname used for sending. Some systems use the root domain, while others use a dedicated envelope-from subdomain.
Make sure you are editing the TXT record for the correct hostname. This avoids the common issue where a team updates SPF but nothing changes because they edited the wrong record.
2) Count your lookup terms (your SPF budget)
Count the SPF mechanisms and modifiers that can trigger DNS queries during evaluation:
- include
- a
- mx
- ptr
- exists
- redirect
Then estimate nested lookups inside included records. A single include can expand into several more lookup-causing terms.
3) Prune unused includes first
This is usually the lowest-risk fix and often the fastest win. Remove providers you no longer use, especially after migrations. Old SPF includes are commonly left behind.
Also remove duplicate includes. It is common for the same vendor to appear more than once due to templates or multiple teams making DNS changes.
In many cases, this step alone brings the SPF record back under the lookup limit with no extra maintenance.
4) Replace lookups with ip4 or ip6 where it is safe
If you control the sending infrastructure or the IP ranges are stable, replace lookup-heavy mechanisms with direct ip4 or ip6 entries.
This avoids extra DNS queries during SPF evaluation and makes the record more predictable for infrastructure you manage directly.
5) Split mail streams across subdomains
If marketing and transactional email share one SPF record, the record can grow quickly. A safer approach is to split streams into separate subdomains, such as:
- Transactional: notify.example.com
- Marketing: news.example.com
This keeps each SPF record smaller and makes failures easier to isolate.
6) Flatten only the worst include chains (partial flattening)
If you are still over the lookup limit, flatten only the include chains causing the biggest SPF expansion. Replace that part with the corresponding ip4 or ip6 ranges, and keep the rest as includes to reduce maintenance.
Document where the flattened IPs came from and how they will be updated. This prevents silent drift later.
After making changes, use the Mailcub docs and run a controlled test send to verify that SPF changes work safely before a full rollout.
Fix Options and Risk Level
| Option | Reduces lookups | Maintenance | Best for | Main risk |
|---|---|---|---|---|
| Remove unused includes | High | Low | Post-migration cleanup | Almost none |
| Replace with ip4/ip6 (stable IPs) | High | Medium | Your own servers or stable ranges | Drift if IPs change |
| Split by subdomain (transactional vs marketing) | High | Low | Multiple sending streams | Requires routing discipline |
| Partial SPF flattening | High | High | When you cannot get under the limit otherwise | Drift and operational overhead |
| Reduce vendor count | High | Medium | Long-term hygiene | Project effort |
Common Mistakes
- Keeping every historical email service provider in SPF “just in case”
- Using redirect plus multiple includes without tracking total lookups
- Flattening everything once and never updating vendor IP ranges
- Editing the wrong hostname (root domain vs envelope-from subdomain)
- Publishing multiple SPF TXT records for the same hostname
Troubleshooting
Problem: Still getting too many DNS lookups
Recount nested includes carefully. One top-level include can expand into several more lookups.
Also check whether you are using mx or a mechanisms where ip4 or ip6 would be safer and simpler for your setup.
Problem: SPF passes sometimes and fails sometimes
This usually happens when one of these is true:
- Different envelope-from domains are used in different email flows
- Some mail is coming from a vendor that is no longer covered in SPF
- A flattened IP list has become stale
Confirm which hostname each stream uses, then test each stream independently so you can isolate the problem.
FAQ
What causes SPF PermError: too many DNS lookups?
It happens when SPF evaluation needs too many DNS queries, usually because of stacked include chains. The receiver stops evaluation and returns a permerror once the lookup limit is exceeded.
Which SPF mechanisms count toward the lookup limit?
Mechanisms such as include, a, mx, ptr, and exists, plus the redirect modifier, can trigger DNS queries and count toward the SPF lookup limit.
Is SPF flattening safe for transactional email?
It can be safe if the flattened IP ranges are kept accurate. The main risk is drift, where a provider changes sending IP ranges and your flattened record is not updated.
What is the best alternative to SPF flattening?
Start by removing unused includes. If you have multiple sending streams, split transactional and marketing traffic across subdomains so each SPF record stays smaller and easier to manage.
Can I publish multiple SPF records on one hostname?
It is strongly discouraged. Multiple SPF TXT records on the same hostname can cause inconsistent evaluation. Use one consolidated SPF policy per hostname.
How do I verify SPF changes did not break sending?
After DNS propagation, run a controlled test send and confirm your logs show successful delivery with no SPF-related failures. Keep a rollback plan for the previous SPF record.
Conclusion
To fix too many DNS lookups errors, start with the lowest-risk changes first: remove unused includes, reduce lookup-heavy mechanisms where possible, and split streams across subdomains. Use SPF flattening only when you can maintain it, because stale IP ranges are the most common long-term failure.
To validate changes end-to-end, use the Mailcub documentation to confirm your DNS setup, test sending through the Transactional Email product, and review the pricing page if you are planning your sending infrastructure.