SPF Dependency Graph

Count mechanisms, not characters

RFC 7208 limits an SPF evaluation to ten mechanisms that trigger DNS queries. The include, a, mx, ptr and exists mechanisms all count, and redirect participates in the same budget. Crossing that limit produces PermError, which under most policies means SPF does not pass at all — a stricter outcome than a simple fail.

Because includes nest, the visible record is a poor predictor of the real count. A record with three includes can expand into a dozen queries once each provider’s own policy is resolved. The graph shows the fully expanded tree so the cost of each authorization is attributable to the vendor that introduced it.

• include, a, mx, ptr and exists each consume the lookup budget.
• redirect is evaluated within the same limit.
• PermError is generally worse than a plain fail, because it can invalidate the whole evaluation.

Void lookups are a second, quieter limit

Separately from the ten-mechanism budget, RFC 7208 limits how many DNS queries may return no answer. Two void lookups are enough to produce PermError in a conforming evaluator. Includes pointing at decommissioned vendor domains are the usual source, and they are easy to miss because the record itself still parses correctly.

This is why an SPF record that worked for years can begin failing without anyone changing it. A vendor retires a hostname, the include starts returning nothing, and the void-lookup limit is reached. The analysis reports void results explicitly rather than folding them into a single pass or fail verdict.

Read the SPF lookup pressure guide

Reduce dependencies before flattening them

Flattening replaces provider includes with literal IP ranges. It reduces recursion, but it transfers responsibility for keeping those ranges current from the vendor to you. When the vendor changes infrastructure and the flattened record is not refreshed, legitimate mail begins failing SPF even though the original include would have adapted automatically.

The safer sequence is to inventory every legitimate sender, verify ownership, remove authorizations for services that no longer send, and only then consider flattening what remains. Test the proposed record before publishing it, and leave headroom for growth rather than landing exactly on the limit.

Test a proposed SPF record before publishing · Inventory who is authorized to send

Example: a record that passes inspection but fails evaluation

Known limits

• Static analysis reflects DNS at query time; a vendor can change its published policy at any point.
• Macro expansion and conditional constructs can produce evaluation paths that static resolution does not fully reproduce.
• A passing lookup count does not confirm that a given message used an authorized sending IP.

Common questions