DEV Community: Mogley1011

SPF "too many DNS lookups" (permerror): why it happens and how to fix it

Mogley1011 — Thu, 22 Oct 2026 07:10:03 +0000

If a DMARC report or a checker says spf=permerror or "SPF exceeded 10 DNS lookups", your SPF record is being ignored by receivers, even though it looks fine when you read it. Here is what is actually counted and how to get back under the limit.

What the limit is

RFC 7208 allows at most 10 DNS-querying terms while evaluating one SPF record. These count: include, a, mx, ptr, exists and redirect. These do not: ip4, ip6 and all. The count is recursive, so each include: also adds whatever lookups sit inside the record it points to.

That is how a short record blows the budget. include:_spf.google.com is one lookup that expands to several more. Add a marketing platform, a helpdesk, a CRM, and Microsoft 365, and you are over 10 without trying.

There is a second, quieter limit: more than 2 "void" lookups (names that return nothing) also produces a permerror.

1. Count it properly

Do not count the include: entries by eye. Resolve each one and count the terms inside it. Write the tree out on paper: top-level record, then each include, then each include inside those.

2. Remove what you no longer use

In almost every audit the fastest win is dead weight: the tool you cancelled in 2022, the old hosting provider, a duplicate include. Each one removed frees one or more lookups. Check against your real senders, not against what the record says.

3. Replace lookups with fixed addresses where the provider's IPs are stable

An a: or mx: term costs a lookup. If your own server's IP never changes, ip4:203.0.113.5 costs none. Only do this for addresses you control. Never hard-code a big provider's ranges, because they change and you will silently break your own mail.

4. Split by sending subdomain

Give each sender its own subdomain (for example news.example.com for the newsletter platform) with its own SPF record and its own 10-lookup budget. Your main domain's record then stays small, and a problem with one tool cannot take down the others. DKIM and DMARC alignment need to be set up for each subdomain, so plan that at the same time.

5. Flattening, with care

Flattening replaces includes with the IPs they resolve to. It fixes the count, but provider ranges change, so a static flattened record goes stale and starts rejecting real mail. If you flatten, it has to be kept up to date automatically, and you need a way to notice when it drifts.

6. Verify

After the change, re-resolve the whole tree and confirm you are at 10 or under, with no more than 2 void lookups. Then send a test to a Gmail and an Outlook address and check Authentication-Results for spf=pass.

The part most people skip

The record is only correct today. Every new SaaS tool someone adds to the stack can quietly push you back over the limit, and you find out when mail starts failing. I now treat the lookup count as something to watch continuously, the same way you would watch certificate expiry, rather than something to fix once.

If you want a quick look at where your own domain stands, Email Fix Pack has a free checker that reads your live SPF, DKIM and DMARC (disclosure: I made it).

Gmail 550 5.7.26 "unauthenticated sender": what it means and how to fix it

Mogley1011 — Tue, 20 Oct 2026 18:30:37 +0000

If Gmail bounced your message with 550 5.7.26 This message does not have authentication information or fails to pass authentication checks, it is not a content problem. Gmail is telling you it could not verify who sent the mail. Here is how to find which check failed and fix it, in the order I would do it.

1. Read the bounce, then the headers

The bounce text names the failing mechanism. Look for "SPF", "DKIM" or "DMARC" in it. If you can get a delivered copy (send to a Gmail address you control that is not blocked), open "Show original" and read the Authentication-Results line:

spf=pass  dkim=pass  dmarc=pass

You need SPF or DKIM to pass, and for bulk senders both, and DMARC to pass with alignment. Anything else is what to fix.

2. SPF: one record, under 10 lookups

Check what you publish:

dig +short TXT yourdomain.com | grep spf1

Common faults:

Two SPF records. There must be exactly one v=spf1 TXT record. Merge them into one.
More than 10 DNS lookups. Every include:, a, mx and redirect counts. Over 10 gives permerror, which Gmail treats as a fail. Remove providers you no longer use.
Sending service missing. If your newsletter or invoicing tool sends as your domain, its include: must be in the record.
Ending in +all or nothing. Use ~all while you test and -all once you are sure.

3. DKIM: sign with your own domain

Gmail wants DKIM signed with a domain that matches your From address. Enable DKIM in your mail provider and publish the CNAME or TXT record it gives you, then confirm the selector resolves:

dig +short TXT selector1._domainkey.yourdomain.com

A signature from the sender's own domain (for example a shared d=sendgrid.net) passes DKIM but will not align with your From domain, so DMARC still fails.

4. DMARC: publish it and make it align

Add a TXT record at _dmarc.yourdomain.com. Start in monitoring mode:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Read the aggregate reports for a couple of weeks, fix any legitimate sender that fails, then move to p=quarantine and later p=reject. Google's bulk-sender rules (more than 5,000 messages a day to Gmail) require DMARC, and it is the right baseline for everyone.

5. Test after DNS settles

DNS changes can take up to an hour to be seen everywhere. Send a test to a Gmail address and check Authentication-Results again. If dmarc=pass and the bounce is gone, you are done.

If you do not want to work through this by hand

I built a free checker that reads your domain's live SPF, DKIM and DMARC and lists what is wrong. A paid fix pack generates the exact records for your mail provider and DNS host. Both are on Email Fix Pack (disclosure: I made it). The error is covered in more detail on this page.