How to test SPF records and fix common SPF errors

SPF problems announce themselves in three places: the Authentication-Results headers of delivered mail, the aggregate reports DMARC sends you, and validator tools you run on demand. This entry covers the result vocabulary those sources speak, the testing workflow for changes, and the short list of misconfigurations behind nearly every SPF failure in the wild.

The seven results and what to do about each

SPF result vocabulary

Feature	Meaning	Action for the sender
pass	Connecting IP is authorized	None; verify alignment for DMARC
fail	IP explicitly not authorized (-all matched)	Authorize the source or stop it sending as you
softfail	IP suspect but not condemned (~all matched)	Same as fail: fix the record or the source
neutral	Record asserts nothing (?all matched)	Publish a real policy
none	No SPF record found at the domain	Publish a record; every domain needs one
temperror	DNS lookup failed transiently	Investigate DNS availability if persistent
permerror	Record is invalid or over the lookup limit	Fix immediately; the record is void everywhere

Two results deserve special attention. permerror means the record itself is broken, malformed syntax, duplicate records, or the 10-lookup limit exceeded, and it fails identically at every receiver until fixed. temperror is transient DNS trouble; occasional instances are background noise, while a sustained pattern points at your DNS provider's availability, not your record.

The testing workflow

Validating a record, before and after publishing

1
Read the record as resolvers see it
Query from outside your network and check for exactly one v=spf1 record, intact quoting, and no truncation.
dig TXT example.com +short
2
Run a validator
The dmarcian SPF Surveyor, MxToolbox SPF check, and similar tools parse the record, expand every include, count lookups, and flag syntax issues in one pass.
3
Send real test mail
Mail a Gmail account from each sending service, open "Show original", and confirm SPF PASS with the expected domain. Header reading beats assumptions.
4
Watch DMARC reports after changes
Aggregate reports over the following days confirm every legitimate source still passes with alignment across real traffic, including the streams you forgot exist.

The usual suspects

Two SPF records

A vendor onboarding guide says add this TXT record, someone does, and the domain now has two v=spf1 records and a permerror. Merge all mechanisms into one record. This single mistake accounts for a remarkable share of all SPF breakage.

The unlisted sender

Mail from a legitimate service softfails or fails because nobody added its include when the tool was adopted. The symptom surfaces in DMARC reports as a failing source with recognizable reverse DNS. The fix is the missing include, and the prevention is making SPF updates part of every new tool's onboarding checklist.

Console mangling

DNS provider consoles add quotes, strip quotes, split strings at odd points, or truncate long values, producing a published record that differs from what was typed. Always verify with dig after saving, from an external resolver, and compare character by character when something looks off.

Stale literals after infrastructure changes

ip4 ranges pointing at servers you renumbered, includes for ESPs you left, manually flattened IP lists that drifted from the vendor's reality: records rot at the speed of infrastructure change. A quarterly review against DMARC report data, removing what no longer sends and adding what does, keeps the record truthful.

Failures that are actually forwarding

A steady trickle of SPF failures from university domains, mailbox forwards, and mailing lists is not a configuration problem; it is forwarding doing what forwarding does. Recognize the pattern in reports (small volumes, respectable forwarding hosts, DKIM usually still passing) and resist fixing what is not broken. The mechanics are covered in the alignment entry.

Reading SPF in headers

Authentication-Results, the three tells

1spf=pass ... smtp.mailfrom=bounce@mail.example.com
2  -> healthy: pass, and the domain is yours (aligned)
3
4spf=pass ... smtp.mailfrom=b-42@esp-platform.com
5  -> pass for the wrong domain: configure a custom bounce domain
6
7spf=permerror ... smtp.mailfrom=bounce@example.com
8  -> record broken: check for duplicates, syntax, lookup count

Frequently asked questions

How long do SPF changes take to be visible?

As long as the record's DNS TTL: resolvers serve the cached version until it expires. Lower the TTL before planned changes and verify with external queries after publishing.

Can I test a record before publishing it?

Validators that accept pasted record text check syntax and count lookups without DNS. For end-to-end behaviour, publish on a test subdomain first and send real mail from the intended source.

Why does the same mail pass SPF at Gmail and softfail elsewhere?

Different receivers saw different delivery paths, most often direct versus forwarded copies, or evaluated at different times across a DNS change. Compare the smtp.mailfrom domain and connecting IP in each receiver's headers before blaming the record.

What should monitoring alert on for SPF?

Any spf=permerror in DMARC aggregate reports, effective lookup counts above 8, changes to the published record text, and new failing sources with meaningful volume. All four are cheap checks that catch problems before placement suffers.

Key takeaways

Learn the seven results; permerror is the emergency because it voids the record at every receiver simultaneously
Validate every change twice: a parser tool before, real mail with header inspection after, and DMARC reports over the following days
The classic breakages: duplicate records, unlisted senders, console mangling, and stale mechanisms after infrastructure changes
Records do not inherit, so every envelope sender domain gets tested individually
A background rate of SPF failures from forwarders is normal; diagnose against alignment before rewriting the record