SPF PermError: What It Means and How to Fix It

What a PermError actually is

SPF (Sender Policy Framework) is a TXT record in your DNS that lists who is allowed to send email using your domain. When a receiving server like Gmail or Microsoft gets your message, it reads that record and evaluates it.

A PermError (permanent error) means the evaluation could not be completed because the record is invalid. This is different from a fail. A fail means "this sender is not authorised." A PermError means "this record is unusable."

The consequence is the same either way: your message loses its SPF pass. And under the 2026 Gmail and Microsoft sender rules, mail that authenticates with neither SPF nor DKIM can be rejected outright, not just filtered to spam.

The cruel part is that nothing on your side looks broken. Your sending tool still reports the message as sent. You only find out when replies stop coming.

Cause 1: More than one SPF record

A domain is allowed exactly one SPF record. If two exist, the receiver does not pick the better one or merge them. It returns PermError and ignores both.

This usually happens when a second tool is added later. Someone sets up Google Workspace, and months afterwards a marketing platform's setup guide says "add this TXT record" - so a second SPF record gets published alongside the first.

Here is a real example from a domain we scanned, with the identifying parts removed:

Record 1:  v=spf1 include:amazonses.com ~all
Record 2:  v=spf1 include:_spf.google.com ~all

Both records are individually valid. Together they are a PermError.

The fix: merge them into a single record.

v=spf1 include:_spf.google.com include:amazonses.com ~all

One v=spf1 at the start, one all mechanism at the end, every sender's include in between. Then delete the other record entirely.

Cause 2: More than 10 DNS lookups

This is the cause most people have never heard of, and it is the one that breaks silently as a company grows.

RFC 7208 limits an SPF evaluation to 10 DNS lookups. Every include:, a, mx, ptr, exists and redirect mechanism costs a lookup - and includes are recursive, so one include: can cost several. Once the count goes past 10, the receiver stops and returns PermError.

You do not add these all at once. You add Google Workspace. Then a CRM. Then a support desk. Then a marketing platform. Each vendor's guide says "add our include," and none of them mention the budget you are spending.

A real record from our scans, with identifying includes removed, that reached 18 lookups:

v=spf1 ip4:13.127.134.11 ip4:54.240.85.29 ip4:54.240.85.30
  include:amazonses.com include:_include1.<redacted>.com
  include:_include2.<redacted>.com include:_spf.salesforce.com
  include:_spf.google.com include:servers.mcsv.net
  include:email.onedirect.in include:email-messaging.com -all

That domain's SPF was completely non-functional. Every message it sent was evaluated as if no SPF existed.

The fix, in order of preference:

1. Remove includes you no longer use. Most domains carry at least one vendor they stopped using years ago. This is free and it is usually enough.
2. Replace an include with the IP addresses it resolves to. ip4: and ip6: mechanisms cost zero lookups. This is the highest-leverage change, but you must track it - if the vendor changes IPs, your mail breaks. Only do this for senders with stable, published IP ranges.
3. Consolidate senders. If three tools all send on your behalf, routing them through one relay collapses three includes into one.

SPF flattening, where a service expands your includes into raw IPs and keeps them updated, is a last resort. It works, but it makes your SPF dependent on that service staying current.

Important: the limit is 10, and exactly 10 is still valid. But a record sitting at exactly 10 is one vendor away from breaking, and it will break on the day someone adds a tool without telling you.

Cause 3: Syntax errors

A malformed record fails to parse and returns PermError. The common ones we see:

• An unknown mechanism - a stray +, a typo, or a character that does not belong. One real example from our scans: unknown SPF mechanism '+'.
• An include that does not resolve to an SPF record - you included a hostname that has no SPF TXT record at all. The lookup is spent and the evaluation errors.
• An include cycle - record A includes B, which includes A. The evaluator detects the loop and stops.
• More than one all mechanism, or mechanisms placed after all (anything after all is never evaluated).

The fix: correct the syntax and re-check. A single character is often the whole problem.

What we found across 175 real domains

We scanned 175 distinct external domains between April and July 2026. These were not customers - they were ordinary business domains, mostly agencies and B2B companies actively sending email. That list of domains is fixed and kept on file, so every number here can be re-checked against exactly the same set.

Roughly one in seven domains had SPF that was broken or absent. Every one of those businesses was sending email believing their authentication was in place.

The four domains sitting at exactly 10 lookups are worth their own mention. Their SPF works today. It will stop working the moment someone adds one more tool, and nobody will connect the two events.

How to check your own domain

Our free audit parses your full SPF include tree, counts every DNS lookup, and reports the exact problem and the exact record to publish. It also checks DKIM, DMARC, MTA-STS and blacklist status at the same time.

No signup, no email required: audit.humerly.com

If you would rather check by hand, query your TXT records directly:

dig +short TXT yourdomain.com | grep spf1

If that returns more than one line beginning v=spf1, you have the multiple-record PermError. Counting lookups by hand is harder, because you have to follow every include: recursively - that is what the tool is for.

Frequently asked questions

Does a PermError send my email to spam?

Not directly. A PermError means SPF cannot be evaluated, so your message loses its SPF pass. Whether it lands in spam then depends on your other signals, mainly DKIM and domain reputation. Under the 2026 Gmail and Microsoft rules, a message that passes neither SPF nor DKIM can be rejected at the door rather than filtered.

Can I just have two SPF records, one for each sender?

No. The specification allows exactly one. Two records is a PermError, and the receiver ignores both. Merge every sender's include into a single record.

Do ip4: and ip6: mechanisms count toward the 10-lookup limit?

No. Only mechanisms that require a DNS query count: include, a, mx, ptr, exists and redirect. Listing raw IPs costs nothing, which is why replacing an include with its IP ranges is the most effective fix - as long as you keep those IPs current.

Is exactly 10 lookups safe?

It is valid, but it is not safe. You have no headroom. The next tool anyone adds pushes you into PermError, and the failure will not be obvious.

How long does a DNS fix take to apply?

Usually minutes to a few hours, depending on your TTL. Re-check after your TTL has elapsed rather than immediately.

Does SPF alone get me into the inbox?

No. SPF is one signal. DKIM, DMARC alignment, domain reputation, list quality and engagement all matter. SPF being broken is a reliable way to stay out of the inbox, but SPF being correct is not a guarantee of getting in. Nobody can honestly promise inbox placement.