InboxRatio
Check your domain

SPF permerror: the result that means your record is broken, and the five ways it breaks

Every other SPF result is a verdict on a message. Permerror is a verdict on you. Pass, fail, softfail and neutral all mean the receiver read your SPF record and applied it; permerror means the record could not be correctly interpreted, so no message can be evaluated against it, in RFC 7208's terms an error condition that "requires DNS operator intervention to be resolved." Your intervention. Until it happens, every receiver that checks SPF gets the same unusable answer, on every message you send.

That makes permerror simultaneously the worst SPF result and the best one to be handed, because unlike reputation problems it is fully mechanical: a defect in a TXT record you control, findable in minutes and usually fixed in one DNS edit. Here are the five causes, ordered by how often they turn out to be the culprit.

Cause one: more than one SPF record

The specification is blunt: a domain must publish at most one SPF record, and a receiver finding several is directed to return permerror. It happens innocently. One record was created years ago for Google Workspace; a new platform's setup wizard says "add this TXT record" and whoever follows it adds a second instead of merging into the first:

example.com  TXT  "v=spf1 include:_spf.google.com ~all"
example.com  TXT  "v=spf1 include:_spf.espmail.net ~all"

Each record is individually valid, which is why this slips past eye checks. The fix is a merge into a single record listing every legitimate source:

example.com  TXT  "v=spf1 include:_spf.google.com include:_spf.espmail.net ~all"

Delete the extras. The SPF checker flags the multiple-record condition explicitly, and a broader email DNS check will show you every TXT record on the host so nothing hides.

Cause two: too many DNS lookups

RFC 7208 caps the DNS-querying terms in an SPF evaluation at ten, and directs receivers to return permerror when the limit is exceeded. Because every include: pulls in its target's includes recursively, records cross the line invisibly, one added vendor at a time, and this cause has a uniquely nasty property: a record can be legal today and permerror next month because a vendor you include restructured its own SPF. The mechanics, the counting rules and the flattening trade-offs get a full guide in SPF too many DNS lookups; the short version is prune dead includes first and delegate subdomains second.

Cause three: syntax errors

A typo anywhere makes the whole record uninterpretable: v=spf1 misspelled, a stray comma between mechanisms (the separator is a space), ip4: written as ip:, an unclosed macro, a duplicated all term, or invisible characters smuggled in by a word processor during copy-paste. DNS accepts any of it happily, because to DNS it's just text; only SPF parsers object, and they object with permerror. A syntax-checking pass with the SPF checker catches these immediately, and composing with the SPF generator instead of hand-editing avoids the class entirely.

Cause four: an include pointing at nothing useful

include: means "go evaluate that domain's SPF record too," so an include whose target domain publishes no SPF record yields permerror for your record, per the specification. This is how a vendor you dropped years ago, or a vendor that renamed its include host, breaks you retroactively. Related and stricter: RFC 7208 permits receivers to permerror after more than two "void lookups," queries that return no data at all, so a record dragging around dead references fails even where each individual mechanism looks plausible. The audit is simple: for every include in your record, confirm the target still resolves and still publishes SPF, and remove any that don't.

Cause five: the exotic tail

Rarer producers of the same result: a record longer than DNS string-handling allows without proper multi-string splitting, redirect= pointing at a domain without a record, ptr: mechanisms misbehaving (deprecated in RFC 7208 for good reasons), and malformed macros. If the four common causes come back clean, this tail is where checker tools earn their keep, since each one reports the exact failing term rather than a general failure.

Why permerror matters more than it used to

Two escalations changed its weight. First, DMARC sits on top of SPF now: permerror means SPF cannot contribute a pass, so your DMARC verdict rides entirely on DKIM, and any DKIM wobble becomes a full DMARC failure with whatever consequences your policy invites. Second, the mailbox providers' 2024-era sender rules, collected on our Gmail, Yahoo and Outlook requirement pages, made working authentication an entry condition for bulk senders. A permerror domain isn't a domain with weak authentication; on the SPF side it is a domain with none, and it will show up in your DMARC aggregate reports as exactly that.

Filtering-wise, permerror is one negative input among the many ranked in why emails go to spam, and established senders often keep inboxing on DKIM alone for a while. That grace period is the trap. The failure is silent, costs nothing on day one, and surfaces as a placement problem weeks later when it compounds with something else.

The repair sequence

  1. Fetch what receivers fetch. Run the domain through the SPF checker. Note whether the error names a specific term.
  2. Count your records. More than one TXT starting v=spf1 on the same host: merge and delete.
  3. Check the lookup budget. Over ten, or near it: prune, then restructure per the lookup-limit guide.
  4. Audit every include for targets that no longer publish SPF.
  5. Re-verify from the receiving side. After DNS propagates, send to a mailbox you control and read the Authentication-Results header with the email header analyzer: you want spf=pass, and dmarc=pass beside it.

Then put the record under change control: one owner, edits made via a checker, and a re-check whenever any sending service is added or removed. The email authentication checker makes the periodic sweep a one-minute habit, and the deliverability checklist gives that habit a schedule.

Related guides

About this guide

Written by InboxRatio Editorial. Permerror conditions are drawn from RFC 7208 directly, including the multiple-record rule, the ten-lookup limit and void-lookup handling; provider enforcement context comes from the providers' published documentation. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on the SPF specification rather than our measurements; the testing protocol is documented in how we test and our source rules in sources.

Last updated

11 September 2026. Specification references reviewed quarterly.

Frequently asked questions

What does SPF permerror mean? The receiver could not interpret your SPF record at all: a permanent evaluation error, per RFC 7208, caused by the record rather than the message. Common triggers are multiple SPF records on one domain, more than ten DNS lookups, syntax errors and includes pointing at domains without SPF records.

Is permerror worse than softfail or fail? Different in kind. Fail and softfail are working verdicts on individual messages; permerror means no verdict is possible for any message until the record is repaired. For DMARC purposes it contributes nothing, leaving DKIM as your only path to a pass.

Does SPF permerror fail DMARC? Not by itself: DMARC passes if either aligned SPF or aligned DKIM passes, so intact DKIM keeps DMARC passing. But permerror removes SPF from the equation entirely, so any DKIM problem immediately becomes a full DMARC failure.

What causes permerror when the record looks fine? Usually one of the invisible causes: a second SPF TXT record you forgot existed, the recursive lookup count crossing ten after a vendor changed its own record, or an include whose target went dark. Checker tools that evaluate recursively expose all three.

How do I fix SPF permerror? Run the record through the SPF checker, merge duplicate records into one, get under the ten-lookup limit, remove dead includes, fix syntax, then confirm spf=pass in the headers of a really delivered message.

Can permerror come and go? Yes, and that pattern almost always points at the lookup limit or a flaky include target: your record sits at the edge, and changes inside vendors' records push the evaluation over and back. Fixing it means restructuring, not waiting.

Permerror is the one deliverability problem with no mystery in it: the record is broken, the tools name the break, DNS carries the fix. Spend the ten minutes, starting with the SPF checker.