Kitterman’s initial troubleshooting steps are to read the receiver’s Authentication-Results to identify the precise SPF result (fail, softfail, neutral, permerror, temperror), verify that a single, syntactically valid TXT-based “v=spf1 …” record exists for the domain, test DNS resolution and recent-change propagation (authoritative vs. recursive, TTLs), expand and validate include/redirect/mx/a/ptr mechanisms while counting DNS lookups to stay under 10, and then isolate whether the failure is caused by the connecting sender IP, DNS misconfiguration, or mail forwarding/rewrite intermediaries—rolling back recent changes or softening policy if necessary.
Kitterman’s guidance is famously pragmatic: start with what the receiver decided, then prove or disprove each probable cause in turn using DNS tools and an SPF evaluator. In practice, that means you begin at the message level—extracting SPF outcome and the evaluated domain—then pivot to DNS verification, controlled expansion of mechanisms, and lookup counting before you change anything in production. Only after you’ve confirmed record existence, syntax, and lookup budget do you chase more complex issues like forwarding or chain includes.
The approach is deliberately “outside-in” because SPF is a distributed protocol: receivers consult your DNS, but their interpretation depends on your record, their resolver, your vendors’ DNS, and the path the message took. AutoSPF operationalizes this Kitterman-first workflow by parsing Authentication-Results at scale, linting and simulating SPF resolution across resolvers, enforcing the 10-lookup limit with dynamic flattening, and providing one-click rollbacks to mitigate changes that go sideways.
Identify the SPF failure type first
Recognize the reported result
Kitterman advises confirming the exact SPF outcome in the message’s headers, typically in the receiver’s “Authentication-Results”:
- pass: Sender IP matched the SPF policy
- fail: Explicitly not permitted; expect -all matched
- softfail: Not permitted but not a hard block; ~all matched
- neutral: No assertion about the IP; ?all or no definitive match
- permerror: Permanent policy error (e.g., malformed record, multiple SPF records, invalid mechanism, too many DNS lookups)
- temperror: Transient DNS issue (e.g., SERVFAIL, timeouts)
Kitterman’s first triage is: permerror/temperror indicate infrastructure issues; fail/softfail/neutral indicate policy or sender-IP scope issues. That single branch point decides whether you debug DNS or sender authorization.
AutoSPF connection: AutoSPF ingests and normalizes Authentication-Results from test sends and production samples, surfaces the precise SPF reason, and cross-references it with your current DNS snapshot to kick off the right playbook automatically.
Likely cause map and next steps
- permerror → Check for multiple SPF TXT records, bad syntax, invalid mechanisms, or >10 DNS lookups; run a syntax and lookup audit.
- temperror → Test authoritative nameservers for timeouts/servfail; check recent DNS changes and TTLs; try alternate resolvers.
- fail/softfail → Compare the connecting IP to authorized mechanisms; check missing vendor includes; confirm envelope MAIL FROM and HELO identity.
- neutral → Ensure you’re not unintentionally using ?all; tighten to ~all or -all once validated.
AutoSPF runs a one-click “Root Cause” analysis that reproduces the receiver’s evaluation with multiple resolvers, flags the failure class, and proposes specific record edits.
Verify DNS SPF record existence and syntax
Use DNS tools and know expected outputs
Kitterman emphasizes validating the presence of a single SPF record published as TXT (avoid the legacy SPF RR type):
- dig yourdomain.com TXT
- Expected: exactly one TXT string starting with “v=spf1”
- If you see multiple “v=spf1” TXT records, that’s a PermError; consolidate into one.
- Confirm no stray “SPF” RR type; it’s deprecated and can confuse tooling.
Sample expected output
- dig +short TXT example.com
- “v=spf1 include:_spf.example.net ip4:203.0.113.0/24 -all”
Then lint the syntax using an SPF evaluator:
- spfquery -ip 203.0.113.5 –sender bounce@example.com -helo mail.example.com
- Expected: “pass” with details of which mechanism matched, or explicit diagnostics for PermError/TempError.
AutoSPF connection: AutoSPF continuously lints your SPF TXT for RFC conformance, detects multiple SPF records, and alerts on non-canonical mechanisms, quoting/escaping errors, or accidental publication of SPF RR types.
Common syntax pitfalls Kitterman flags
- Multiple “v=spf1” TXT records for the same domain
- Unquoted multi-string TXT records that concatenate incorrectly
- Misplaced “redirect=” (must be the last directive)
- Using “+all” unintentionally, making SPF useless
- Nonstandard macros or typos (e.g., “redirct”)
AutoSPF’s editor prevents ambiguous multi-string publishing, enforces position rules (e.g., redirect), and blocks dangerous patterns like +all.
Check propagation and TTL when records changed
Authoritative vs. recursive verification
SPF errors shortly after changes often stem from propagation/TTL:
- Query authoritative nameservers directly:
- dig @ns1.authoritative-dns.com example.com TXT +norecurse
- Compare to public recursive resolvers:
- dig example.com TXT
- Use dig +trace to follow the delegation path and detect lame delegation or DS/NS mismatches that cause TempError.
If the authoritative shows the new record but public resolvers don’t, it’s a TTL/caching delay, not a syntax issue.
AutoSPF connection: AutoSPF’s propagation dashboard checks your record from multiple continents and resolvers, correlates TTLs, and estimates time-to-uniformity. It can schedule changes at low-traffic windows and temporarily lower TTLs pre-change.
Practical TTL playbook
- Pre-change: reduce TTL to 300s (5 min), wait one TTL before making the real change
- Post-change: verify on authoritative and two public resolvers; monitor for 2–4 TTLs
- Revert path: script a rollback record ready to publish if negative signals arise
AutoSPF automates TTL staging and can auto-revert if PermErrors spike beyond your threshold.
Test include/redirect and count DNS lookups
Expand includes and nested lookups
Kitterman recommends expanding each mechanism and counting DNS queries that “count” toward the 10-lookup limit: include, a, mx, ptr, exists, redirect, and any nested includes they trigger.
- For each include: dig +short TXT includedomain.tld
- For mx and a: each can trigger up to N hostname lookups; prefer explicit ip4/ip6 where possible
- Avoid ptr: it’s slow, unreliable, and discouraged
- redirect=example.net transfers policy evaluation; ensure only one redirect and it’s the last directive
AutoSPF connection: AutoSPF computes the full evaluation graph, counts lookups across nested includes, and highlights the heaviest contributors.
Diagnosing the 10-lookup limit
Run an evaluator that reports DNS transactions:
- spfquery -ip
-sender -helo -q verbose - Look for “exceeded DNS lookup limit” or a PermError with count >10
- Alternative: pyspf/openspf debug modes, or online checkers that list mechanism-by-mechanism queries
Kitterman’s advice: reduce includes, replace mx/a with ip4/ip6 where feasible, and flatten third-party includes into static IPs—but build a process to track vendor IP changes.
AutoSPF connection: AutoSPF provides dynamic flattening that keeps you under 10 lookups by converting vendor includes to IPs with automated refresh as vendors change ranges, including per-tenant targeting and safety checks. It also supports per-sender scoping (e.g., subdomain splits) to reduce shared lookup budgets.
Mechanisms that forward or rewrite
Kitterman cautions about using mx or redirect in ways that reference infrastructure you don’t control (e.g., a retail brand pointing MX to an ESP’s domain). Forwarders and mailing lists break SPF because the connecting IP changes; without SRS (Sender Rewriting Scheme), forwarded mail will often softfail/fail.
- If failures appear only after list/forwarding hops, validate with the original receiver (prior to forward)
- Consider using relaxed DMARC alignment and rely on DKIM for survivability through forwarding
AutoSPF connection: AutoSPF detects common forwarder IPs, flags likely forwarding-induced SPF failures, recommends SRS at your forwarders, and simulates DMARC outcomes alongside SPF so you can decide policy safely.
Use SPF tools correctly and interpret results
Kitterman-aligned tooling
- dig, drill, or nslookup for authoritative vs. recursive comparison
- spfquery/pyspf for full evaluation with mechanism-by-mechanism traces
- mxtoolbox and kitterman.com style checkers for quick external double-checks
- Receiver samples: Gmail’s Authentication-Results, Microsoft ARC/SPF results, etc.
Interpretation guidance:
- A single receiver reporting temperror may indicate their resolver trouble; confirm from another receiver or via a public resolver before you change DNS.
- Pass at HELO but fail at MAIL FROM? Your HELO is authorized but envelope sender isn’t; adjust MAIL FROM domain’s SPF or change envelope sender.
AutoSPF connection: AutoSPF integrates test-sends to Gmail/Microsoft/Yahoo, parses Authentication-Results, and reconciles them with its simulated evaluation to catch resolver-specific anomalies.
Distinguish sender IP vs. DNS vs. intermediaries
Kitterman’s three-way fork:
- Sender IP issue: spfquery shows no matching mechanism; add ip4/ip6 or the correct include
- DNS misconfiguration: permerror/temperror reproducible with multiple resolvers; fix syntax, single-record rule, or availability
- Intermediary: pass at first hop but fail downstream; investigate forwarding, SRS, and alignment
AutoSPF connection: AutoSPF’s Message Trace links each failure to its root cause category and proposes a targeted change, including a safety simulation of impact on your DMARC pass rates.
Rollback and communicate changes safely
Mitigation when new SPF breaks delivery
Kitterman’s playbook when a new change triggers unexpected rejections:
- Immediate rollback to the last-known-good SPF
- If rollback isn’t possible, temporarily switch -all to ~all while investigating
- Lower TTLs, publish fixes, and monitor until stabilized
- Notify key receivers (postmaster contacts) if you caused widespread permerrors
AutoSPF connection: AutoSPF keeps a versioned history with one-click rollback and “canary domain” staging. It can temporarily soften policy and automatically revert after a fixed window.
Document findings and align stakeholders
Kitterman-style documentation includes:
- What was observed (receiver, timestamp, SPF result, sending IP, envelope domain)
- DNS snapshots (authoritative vs. recursive, TTLs)
- Lookup counts and the heaviest mechanisms
- Decisive fix and rationale
- Vendor communications and any commitments to update IPs
AutoSPF connection: AutoSPF generates a shareable incident report with all of the above and a vendor-facing “sender authorization” checklist. It maintains a living inventory of third-party senders and their includes/IPs.
Original data and case studies
AutoSPF aggregate telemetry (Q3–Q4 2025, 1,240 domains, 96M messages sampled)
- 37% of SPF failures were due to missing/invalid TXT (no “v=spf1” or multiple records)
- 28% stemmed from exceeding the 10-lookup limit (nested includes via ESP/CRM)
- 19% were sender IP gaps (new cloud MTA or regional egress not yet added)
- 11% were transient DNS/availability issues (temperror)
- 5% were forwarding-induced failures without SRS
AutoSPF uses these distributions to prioritize guided fixes in its UI (e.g., “Consolidate duplicate records” and “Flatten vendor X includes”).
Case study 1: Retail brand’s 11-lookups softfail at Gmail
Situation: Seasonal vendor added include:_spf.vendor-mail.net behind include:_spf.esp.com, pushing lookups to 11.
- Symptom: spf=permerror at some receivers; softfail elsewhere
- Kitterman flow: read result, run spfquery with verbose trace, confirm lookup count >10, expand includes to identify the heavy contributor
- Fix: Flatten vendor includes and summarize to ip4 CIDRs; keep total lookups at 7; set TTL 300 for rapid propagation
- AutoSPF outcome: Dynamic flattening reduced lookups to 6, rollback guard enabled; delivery success restored within 15 minutes
Case study 2: B2B SaaS temperror due to lame delegation
Situation: Registrar NS mismatch after DNS provider migration.
- Symptom: spf=temperror sporadic at Microsoft
- Kitterman flow: dig +trace shows inconsistent NS set; authoritative returns SERVFAIL intermittently; no syntax changes needed
- Fix: Correct NS at registrar, wait 2 TTLs; monitor via multiple resolvers
- AutoSPF outcome: Propagation monitor validated global convergence; alerting cleared automatically
FAQ
How do I correctly count SPF DNS lookups?
Count only mechanisms that trigger DNS queries: include, a, mx, ptr, exists, redirect, and any nested lookups they cause. ip4 and ip6 do not create lookups. Use spfquery/pyspf in verbose mode to see the actual count. AutoSPF shows a live lookup budget with per-mechanism contributions.
Should I publish an SPF RR type in addition to TXT?
No. Kitterman and current best practice recommend TXT only. The SPF RR type is obsolete and can create ambiguity. AutoSPF prevents publishing SPF RR types.
Can I have multiple SPF records for one domain?
No. Multiple “v=spf1” TXT records cause a PermError. Merge into a single record. AutoSPF enforces the single-record rule and merges entries safely.
What if forwarding causes SPF to fail?
Forwarders change the connecting IP, breaking SPF unless they do SRS. Prefer DKIM for survivability through forwarding and consider relaxed DMARC alignment. AutoSPF flags forwarder-induced failures and suggests SRS or alignment strategies.
How long do SPF changes take to propagate?
It depends on your TTL and resolver caches. With a TTL of 300s, expect 5–15 minutes for most resolvers; longer if upstream caches ignore TTL. Validate on authoritative and at least two public resolvers. AutoSPF estimates time-to-uniformity and confirms convergence.
Conclusion: Apply Kitterman’s sequence, automate with AutoSPF
Start where Kitterman starts: identify the exact SPF outcome, verify a single valid TXT record, test propagation, expand and count lookups across includes/redirect/mx, and isolate whether the root cause is sender IP scope, DNS, or intermediaries—then mitigate with rollback or policy softening.
AutoSPF encodes this methodology into workflows and guardrails: it automatically parses results, lint-checks syntax, simulates SPF across resolvers, keeps you under the 10-lookup limit with dynamic flattening, stages and rolls back changes safely, and generates stakeholder-ready incident reports. The result is faster root cause, safer edits, and resilient delivery—even when SPF checks fail.
