An SPF permerror means your SPF record is broken, not that a single message simply failed the check. Receivers often treat that permanent error much like a fail, especially when DMARC is involved. The usual causes are two separate SPF TXT records, bad syntax, or more than ten DNS lookups in the evaluation path.
You can confirm what the public DNS actually publishes with a simple query:
dig +short example.com TXTCount every string that begins with v=spf1. Exactly one is correct. Two is the classic permerror, and a control-panel wizard that appended a second record is a common source. Merge the mechanisms into one string with a single trailing all mechanism. Other TXT records such as DKIM keys, domain verification tokens, or DMARC at _dmarc are separate and do not make a second SPF record valid.
DNS lookups and void results
Each include:, a, mx, and nested include counts toward the SPF limit of ten lookups. Nested includes still count against that budget. A void lookup, such as an include that points at a hostname with no usable data, also consumes budget and can produce a permerror on its own. Flattening includes down to raw IP addresses can dodge the cap for a while, but those addresses change over time and the record drifts. Prefer a design that stays under ten lookups, and count the nested ones when you review the chain.
Syntax problems are another frequent cause. Missing spaces, a stray v=spf1 in the middle of the string, or registrar quoting that concatenates into garbage will break evaluation. Dig shows what receivers see, not only what the panel form appeared to save.
How receivers treat permerror
Under DMARC, permerror is not a soft “try DKIM and move on” outcome at every provider. Many sites treat it closer to fail. Delivery can look inconsistent: one mailbox provider may still accept mail on the strength of DKIM, while another rejects or flags it. That uneven behavior is usually a broken TXT record, not random policy.
Confirm the fix
After you merge, dig should show a single SPF string for the domain. Send a test message and read the Authentication-Results header. You want spf=pass, or a deliberate fail if that is what you configured—not permerror. Then review DKIM as well. A clean SPF record with no DKIM still leaves a weak DMARC story. If a registrar’s TXT editor splits one value into quoted chunks, that can still be one record when the pieces concatenate correctly. Two separate TXT resource records that each start with v=spf1 are not one record, no matter how they appear in a form.
LogicWeb shared hosting includes cPanel with AutoSSL, and you can edit DNS TXT records from the same account tools you already use for the domain. After DNS settles, recheck with dig and a real outbound test so you know receivers no longer see a permanent SPF error.
Tagged
Was this article helpful?
Be the first to rate this article.
