You add one more email tool, generate its SPF snippet, and paste it into your existing record. Mail starts bouncing a week later, or worse, starts landing in spam with no warning. You check your SPF record and it looks fine syntactically. The real problem is invisible until you count something nobody counts by hand: how many DNS lookups your SPF record triggers.
An SPF PermError is a permanent error a receiving mail server returns when your domain's SPF record needs more than 10 DNS lookups to evaluate. RFC 7208, the SPF specification, sets that limit deliberately, and once you cross it, most receiving servers stop trusting your authentication entirely rather than trying to figure out which part still works. The frustrating part is that the record can look completely correct in a text editor — no typo, no missing quote — and still fail purely on lookup count, which is why this cause gets missed long after the more obvious syntax errors have been ruled out.
What Is an SPF PermError?
An SPF PermError is the result code a receiving mail server returns when it cannot finish evaluating your SPF record because the record is malformed or exceeds the processing limits defined in RFC 7208. The most common trigger is the 10 DNS lookup ceiling, not a typo or a missing quote.
Unlike SPF Fail, which means the sending server is not authorized, PermError means the receiving server gave up on evaluation altogether. Some mail providers treat PermError as equivalent to Fail. Others quarantine the message. Very few treat it as harmless, because from the receiver's side a record it cannot finish checking is indistinguishable from a record hiding something.
RFC 7208 also caps a second, smaller total inside the same evaluation: void lookups, meaning DNS queries that return no answer at all, are capped at 2. A record can sit under 10 total lookups and still fail from dead-end queries left behind by a decommissioned vendor or subdomain.
Why Does SPF Have a 10 DNS Lookup Limit?
The 10 lookup limit exists to stop SPF checks from becoming a denial-of-service vector. Every incoming message triggers an SPF evaluation, and if a malicious or careless record chained hundreds of DNS lookups, a receiving mail server would burn CPU and network time on every single message it processes.
Not every SPF mechanism counts against the limit. Mechanisms that require a DNS query to resolve count; mechanisms that are already a static value do not.
| Mechanism | Counts as a lookup? | Common source |
|---|---|---|
| include: | Yes | Third-party senders (Google Workspace, SendGrid, HubSpot) |
| a | Yes | Domain name resolution |
| mx | Yes | Mail server resolution |
| ptr | Yes, and deprecated | Reverse DNS checks; RFC 7208 advises against it |
| exists: | Yes | Conditional macro-based checks |
| redirect= | Yes | Delegates the rest of evaluation to another record |
| ip4: / ip6: | No | Static IP addresses, no query needed |
| all | No | Catch-all qualifier at the end of the record |
Each include: also inherits the lookups of the record it points to. A single third-party include can silently cost two or three lookups on its own, which is how a record with five visible entries ends up needing twelve.
How Do You Know Your SPF Record Is Close to the Limit?
Most teams find out from a symptom, not a count: a vendor reports bounced mail, or a customer says your email landed in spam. By the time that happens, the record has usually been over the limit for a while, because SPF failures are silent to the sender. Your outgoing mail server never sees the receiving side's evaluation.
Manually counting lookups means walking every include: chain by hand with a DNS tool, adding up each mechanism, and repeating the walk every time a vendor changes their own SPF record upstream, since their changes affect your total without you touching your own DNS. This is the part of SPF hygiene that gets skipped, because it has to be repeated on a schedule to catch drift rather than done once.
EmailControl checks the resolved lookup chain behind your SPF record on the schedule your plan runs, not just the syntax, and flags a record that is at or past the 10 lookup ceiling before a receiving server starts rejecting your mail. See how the check works on the FAQ page if you are not sure where your own record stands right now.
How Do You Fix an SPF Record That Exceeds the Limit?
Fixing an over-limit record is a matter of reducing lookups, not rewriting your whole authentication setup. Work through it in this order:
- List every mechanism in your current record and mark which ones consume a lookup, using the table above.
- Remove any
include:for a vendor you no longer use — old marketing tools and abandoned trial accounts are the most common dead weight. - Replace a stable vendor's
include:with the vendor's published static IP ranges asip4:orip6:entries, if the vendor documents them, since static IPs cost nothing against the limit. - Consolidate multiple sending sources under a single subdomain SPF record and reference it once with
redirect=, instead of stacking separate includes at the root. - Republish the record and re-run the lookup count to confirm you are under 10, including the lookups nested inside any remaining includes.
- Re-check on a schedule going forward, since a vendor can add lookups to their own record without notifying you, pushing your total back over the limit months later.
Flattening — replacing an include: with the vendor's current IPs — works, but it goes stale. If the vendor rotates their sending IPs and you never update the static list, mail from their new IPs starts failing SPF even though your lookup count looks fine. Flatten only vendors whose ranges rarely change, and recheck flattened entries periodically rather than treating them as permanent.
Order matters here for another reason: fixing the highest-cost mechanism first, usually the largest third-party include, gets you back under the limit fastest, while cleanup of smaller unused entries can happen on a normal maintenance schedule instead of under pressure. Treat the first pass as damage control and the second pass as routine hygiene.
What Should You Do If You Are Not Sure Where to Start?
Some teams read this and assume manual DNS queries are good enough, since SPF changes are infrequent. That is true right up until a new vendor is added, or an existing vendor quietly expands their own include chain — at which point the record breaks with no alert, and the first sign is a support ticket about missing email. A one-time manual count catches the problem on the day you run it and misses every day after.
Automated, scheduled checking closes that gap without adding operational overhead: instead of remembering to re-walk your SPF chain every time you touch a DNS record, the check runs on its own and tells you the moment a total crosses 10.
This applies just as much if you manage more than one domain. Each domain has its own SPF record and its own lookup count, so a fix made on one domain last quarter does not protect the others, and a vendor change that pushes one domain over the limit can leave a second, unrelated domain untouched. Tracking that by hand across several domains is where manual checking stops scaling.
Start free monitoring on a domain and see your current SPF, DKIM, and DMARC status, including the resolved lookup count, in the first check. It takes a couple of minutes to add a domain and see where you stand.