SPF Exceeds the 10 DNS-Lookup Limit: What It Means and How to Fix It

What SPF is, and the limit nobody mentions

SPF is a small DNS record that lists which mail servers are allowed to send email as your domain. When a message arrives claiming to be from you, the receiving server reads your SPF record to decide whether the sender is one you authorized. It is one of the three email-authentication records, alongside DKIM and DMARC, and you can read all three at once with our SPF and DMARC checker.

Here is the part that trips people up. SPF records almost never list mail servers directly. Instead they include: other records: one for Google Workspace or Microsoft 365, one for your email marketing tool, one for your CRM, one for your invoicing software, and so on. Every include: forces the receiving server to do a DNS lookup to resolve it, and those includes often contain their own includes, which cost more lookups. RFC 7208, the SPF standard, caps the total at ten DNS lookups (RFC 7208). Go over ten, and the rules change completely.

What a PermError actually does to you

When your record needs an eleventh lookup, the receiving server stops with a PermError, a permanent error, and does something worse than you would expect: it throws out your entire SPF record. It does not just ignore the one extra sender. It stops honoring SPF for your domain altogether, as though you had never published a record at all.

That has three consequences, and none of them are visible from your DNS panel. First, your anti-spoofing protection is effectively off: the record looks like it is guarding you, but no receiver is actually using it, so someone can send mail that looks like it came from your domain. Second, your own legitimate email can start failing SPF checks and landing in spam or bouncing. Third, if you also use DMARC, it leans on SPF to work, so a broken SPF quietly undercuts your DMARC enforcement too. If your DMARC is also sitting at p=none, the two problems compound, and it is worth reading is your business email spoofable and how to move DMARC off p=none alongside this.

Why it happens, and why it is not a hack

This is almost always config debt, not an attack. When you first set up email you had one or two senders. Then over the years you added a marketing platform, a help desk, a payment processor, a booking tool, a new hosting provider, each of which told you to add an include: to your SPF record. Nobody was watching the running total, and one day a nested include pushed you past ten. The record still looks reasonable at a glance, which is exactly why the problem hides.

It is worth saying plainly: a PermError does not mean your site or mailbox was compromised. It means a DNS record grew past a technical limit and stopped working. That is a good-news framing, because a limit you crossed is a limit you can uncross.

How to see where you stand

You cannot eyeball this reliably, because the lookups hide inside nested includes. The fastest way to check is to run a free scan: BadgerScan reads your SPF record the way a receiving mail server does, follows the whole include chain, counts the lookups, and tells you in plain English whether you are over the limit. Our SPF and DMARC checker shows the same detail if you want to inspect the record yourself.

Once you can see the chain, the fix is usually obvious, because most over-limit records are carrying one or two senders they no longer use, each dragging in several lookups.

How to fix it, in order

Work through these in order, because the early steps are free and often enough on their own. First, audit the record and remove any include: for a service you no longer send mail through. An old newsletter tool or a retired CRM can easily account for three or four lookups, and dropping it can put you back under ten without touching anything else.

Second, consolidate where you can. Some providers offer a single combined include, and some let you send through one platform instead of several. Fewer senders means fewer lookups. Third, if you are still over after cleaning up, flatten the record: replace include: mechanisms with the actual IP addresses they resolve to, since a list of IPs needs no DNS lookups at all. The catch with flattening is that providers change their IP ranges without warning, so a record you flatten by hand can silently break weeks later. That is why most people who flatten use a managed SPF-flattening service that keeps those IPs current for them.

A sensible order of operations, then, is: remove stale includes, consolidate senders, and only flatten what is left if you still need to, ideally with a service that maintains it. After any change, rescan to confirm you are back under the limit and that your legitimate mail still passes.

How serious is it, really

We grade this as a medium-severity finding, and that is the honest level. It is a genuine problem, because your email authentication is effectively down and your domain is easier to spoof while it lasts. But it is a DNS edit to fix, not a breach, and nothing on your website itself is compromised. Most businesses can resolve it in an afternoon by trimming a couple of unused senders.

The reason it matters more than its obscure wording suggests is that it fails silently. A missing record is easy to notice. A record that is present, looks correct, and is quietly being ignored by every receiver is the kind of gap that sits open for years. If you would rather our Hamilton and Burlington team sort out your SPF, DKIM, and DMARC and get you to a genuinely protected state without breaking your real mail, that is exactly the kind of thing we do.