Find the SPF identity and the reported error
Start with the original headers of a newly delivered test message. In the receiving server's Authentication-Results, find the SPF result and the tested envelope-sender domain, often shown as smtp.mailfrom. SPF does not simply check the visible From address; a null envelope sender uses the HELO identity.
Email Header Analyzer reads supplied headers in your browser. Check that the authentication result came from the receiving system you trust. A copied or forwarded header is not independent proof of the original delivery. Remove addresses, identifiers and private routing details before sharing an export.
A result of permerror has several possible causes. Preserve the exact reason if the receiver supplies one; do not assume it always means too many lookups.
Count DNS-query-causing terms, including nested ones
RFC 7208 section 4.6.4 sets a limit of ten evaluated terms that cause DNS queries: include, a, mx, ptr, exists and redirect. Evaluation beyond that limit returns permerror. Nested policies share the same limit.
ip4, ip6 and all do not consume that term budget. The budget is not a count of characters, TXT chunks or every DNS packet. RFC 7208 also describes separate limits for some mechanism processing and recommends limiting empty DNS answers, often called void lookups.
Inspect the tree and its unresolved branches
Run SPF Checker for the domain used by SPF. Check for multiple SPF records, then expand the include tree and note each provider. Use DNS Lookup to inspect the published TXT records when the observed policy differs from your control panel.
The checker inspects a static DNS tree without a particular sender IP. It cannot expand sender-dependent macros, and repeated include targets may be marked already included rather than expanded again. Its total helps locate a problem; it is not a complete receiver-specific evaluation or a guarantee that every sender stays within the limit. Review branch errors and missing information along with the total.
Review a smaller policy without removing working senders
- Save the current SPF record and inventory every actual sender, including website mail, billing, support and newsletters. Keep each provider's current instructions beside that inventory.
- Ask the owner of an expensive nested include whether it has a supported alternative. Remove a retired service only after confirming that nothing still sends through it.
- Prepare one combined SPF policy and review its syntax and authorization. Publishing a second
v=spf1record is an error, not a way to split the budget. - Review any proposal to replace includes with fixed IP ranges against the provider's maintenance requirements. Provider ranges can change; a copied list needs an accountable update process.
Changing ~all to -all does not reduce lookup cost. Do not remove a working provider or loosen authorization simply to make a displayed count smaller. NosHost does not publish DNS changes for you.
Retest the policy and each real sending route
After a reviewed DNS change, repeat the TXT and SPF checks and send a new message through each sending service to an account you control. Inspect the receiver's new authentication result. An earlier message records an earlier delivery, even when today's DNS is different.
Keep the before-and-after policy, observation times and redacted receiver results. SPF success does not guarantee DMARC alignment, delivery or inbox placement. For the wider setup, follow the email DNS guide.
Sources
Reviewed on 6 November 2026. RFC 7208: SPF identities, one SPF record, DNS lookup limits and include evaluation.