Check a domain
How it works
Every include costs one
include:, a, mx, ptr, exists: and redirect= each consume one lookup. ip4: and ip6: cost nothing.
Includes nest
Your include pulls in a vendor record that has its own includes. Those count against your budget too.
Ten is a hard cap
RFC 7208 stops evaluation at ten. Receivers return permerror, and most treat that as SPF failure.
Flatten carefully
Replacing includes with ip4: ranges works, but flattened records go stale silently when the vendor changes IPs.
Why this limit exists and why it bites
SPF evaluation is recursive. Every include: in your record makes the receiving server fetch another record, which may contain more includes. Without a ceiling, a malicious record could force receivers into enormous lookup chains. RFC 7208 caps evaluation at ten DNS-querying mechanisms.
What makes this so damaging in practice is the failure mode. Going over the limit does not degrade gracefully — it does not mean the eleventh sender fails while the first ten keep working. Evaluation aborts and returns permerror. Most receivers treat permerror as an SPF failure, so every message from the domain loses SPF, including mail from the very first include in the list.
Worse, it is a delayed fault. You publish a record with eight lookups and everything works. Six months later a vendor adds an include to their own record and you are silently at eleven, with no change on your side and no notification.
Getting back under the limit
Remove stale includes first. Every audit turns up vendors that stopped being used years ago. This is free and carries no risk.
Drop ptr entirely. It is deprecated, costs a lookup, and many receivers ignore or penalise records that use it.
Then consider flattening. Resolving an include down to its ip4: ranges removes the lookup cost. The trade-off is real: those ranges are now frozen in your record, and when the vendor rotates IPs your mail starts failing SPF with no warning. If you flatten, put a recurring reminder in your calendar to re-resolve it.
For cold email specifically, this problem is usually self-inflicted. A sending domain should send through exactly one provider, which means one include and one lookup. If your sending domains are anywhere near the limit, the record was almost certainly copied from your main corporate domain.
What counts toward the limit and what does not
| Mechanism | Counts? | Notes |
|---|---|---|
| include: | Yes — 1 each | And they nest. One vendor include can consume three or four on its own. |
| a | Yes — 1 | Resolves the domain's A record. |
| mx | Yes — 1+ | One for the MX set, plus resolution of each host returned. |
| redirect= | Yes — 1 | Replaces the record entirely with another domain's. |
| exists: | Yes — 1 | Rare outside complex setups. |
| ptr | Yes — many | Deprecated. Remove it wherever you find it. |
| ip4: / ip6: | No | Free. This is why flattening works. |
| all | No | The final catch-all term. |
The two limits people confuse
There are actually two ceilings in the specification. The famous one is ten DNS-querying mechanisms. The second is two void lookups — queries that return NXDOMAIN or an empty answer. Exceed either and evaluation returns permerror.
The void limit catches people whose record includes a vendor domain that no longer exists. The record looks short and healthy, sits at four lookups, and still fails everywhere because two of those four resolve to nothing.
Cutting a record down
| Step | Typical saving | Risk |
|---|---|---|
| Remove vendors you no longer use | 1–4 lookups | None, if you genuinely stopped using them |
Remove ptr | 1+ | None. It is deprecated |
Drop a and mx if nothing sends from those hosts | 1–3 | Low. Confirm your web server does not send mail first |
| Move a vendor to a subdomain sender | 1 per vendor | Low, but the subdomain needs its own record |
Flatten includes to ip4: ranges | As many as you like | High without monitoring — see below |
The honest case against flattening
Flattening turns a live reference into a snapshot. Your record stops asking the vendor who their senders are and starts asserting it on their behalf. The day they add sending infrastructure, your record is wrong — and nothing tells you. Mail from that vendor quietly starts failing SPF.
If you flatten, it needs automated re-resolution on a schedule, not a note to check occasionally. For a cold email sending domain the question rarely arises: one sending provider means one include and one lookup, and any domain near the limit almost certainly inherited a record copied from the corporate domain.
Frequently asked questions
Do ip4 and ip6 mechanisms count toward the limit?
No. Only mechanisms that require a DNS query count: include, a, mx, ptr, exists and the redirect modifier. You can list as many ip4: and ip6: ranges as you like, which is exactly why flattening works as a fix.
What is a void lookup?
A lookup that returns no records or NXDOMAIN — usually an include pointing at a vendor domain that no longer exists. RFC 7208 allows at most two before returning permerror, so a couple of dead includes can break SPF even when your total count is under ten.
Is SPF flattening safe?
It works, but it converts a maintained reference into a frozen snapshot. The vendor no longer controls which IPs are authorised for your domain — you do, using whatever their IPs were on the day you flattened. If you do it, automate a periodic re-resolve or diary a manual review.
My record is 8 lookups. Is that fine?
It is under the limit today, but it leaves almost no headroom. Vendors expand their own records without telling customers. Eight is the point at which I would start removing stale includes rather than waiting for the record to break on its own.
What is the SPF 10 DNS lookup limit?
SPF evaluation is recursive, so the specification caps it at ten mechanisms that require a DNS query — include:, a, mx, redirect=, exists: and ptr. Past ten, evaluation aborts with permerror rather than degrading, so SPF fails for every message from the domain, including mail from the first include in the list.
How do I fix too many DNS lookups in SPF?
Start by removing includes for vendors you no longer use — free, risk-free, and usually enough on its own. Then drop ptr if present, and a or mx if nothing actually sends from those hosts. Flattening includes into literal IP ranges is the last resort, because it freezes vendor infrastructure into your record.
Do ip4 and ip6 mechanisms count toward the SPF limit?
No. Literal address mechanisms require no DNS resolution, so you can list as many as you like without touching the ten-lookup budget. That is exactly why flattening works — and the reason the length of a record tells you nothing about whether it is near the limit.
What is a void lookup in SPF?
A DNS query during SPF evaluation that returns NXDOMAIN or an empty answer, usually because an include points at a domain that no longer exists. The specification allows only two, and exceeding that produces permerror independently of the ten-lookup limit — which is why a short, apparently healthy record can still fail everywhere.
Is SPF flattening safe?
It is safe on the day you do it and progressively less safe after that. Flattening replaces a live reference to a vendor's record with the IPs it resolves to right now, so when the vendor changes infrastructure your record silently stops authorising them. Use it only with automated re-resolution, and prefer pruning unused includes first.
How many lookups should a cold email sending domain use?
One or two. A sending domain should send through exactly one provider, which is a single include. If a sending domain is anywhere near ten, the record was almost certainly copied from your main corporate domain along with every vendor that domain accumulated — none of which have any business authorising your outbound.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.