A short record can hide a long dependency path
A customer policy containing only a few includes can depend on many more DNS-causing terms beneath them. Include triggers recursive SPF evaluation; it does not grant a fresh independent allowance to every supplier. The relevant limit applies across the evaluation. Counting the customer’s visible include tokens therefore answers a different question from determining whether a specific sender path stays within the SPF budget.
This article proposes a dependency review before adding a sending service. It does not recommend copying provider records, flattening addresses without maintenance, or changing DNS based on a hypothetical diagram. First identify the actual sending route and the domain used for SPF. A vendor’s marketing brand may contain several products and account-specific configurations. Only the applicable supported instructions and current dependency evidence should enter the proposed policy. RFC 7208, section 4.6.4 and 5.2
Count terms, not packets or unique suppliers
RFC 7208 identifies include, a, mx, ptr, exists and redirect as terms that cause DNS queries during evaluation and imposes a limit of ten. Exceeding that limit must produce permerror. The all, ip4 and ip6 mechanisms and exp modifier are not subject to this particular limit. That does not make every other aspect of a policy unlimited: MX and PTR processing have additional rules, and void responses have separate guidance.
Keep the language precise when explaining cache behavior. A cached DNS answer can reduce network traffic, but it does not erase the evaluated mechanism from the logical budget. Counting unique domain names can also conceal repeated evaluation. Conversely, a static dependency map can include branches never reached for a given sender. A useful review distinguishes the complete discovered graph from each evaluated path through it. RFC 7208, section 4.6.4
Model the return from each include
A child pass makes the include match, with the include’s qualifier determining the parent result. Child fail, softfail and neutral mean that include does not match, so the parent can continue. Child temperror and permerror propagate as errors, and child none maps to permerror. Those mappings determine whether later customer-level services are reached and therefore whether their terms enter the observed path.
Do not assume that a supplier’s terminal -all fails the entire customer policy. It may simply end that child evaluation without a match and return control to the parent. Equally, do not assume a broken child is harmless because another supplier appears later. An error can terminate the path before that later supplier is considered. Show both the child result and the enclosing decision beside each dependency edge. RFC 7208, section 5.2
Build a route-specific dependency worksheet
Start with a route inventory: business owner, application, product, envelope domain, connecting-address family and supported configuration source. Then create a node for each evaluated policy and an ordered edge for each include or redirect. Preserve exact TXT boundaries and collection times. A diagram without the underlying policy text is not enough to explain why a particular edge exists or why its order matters.
For each representative sender, record the step number, current domain, mechanism, expanded target, cumulative term count, child result and next step. Identify branches excluded by an earlier match. Keep timeout and void information in separate columns. Distinguish an actually observed trace from a static possibility. Neither should be mislabeled as a complete enumeration of every receiver’s behavior.
Add a proposed-change column showing where the new service would enter. Evaluate the business reason for placement and any impact on existing paths. Reordering can change which terms are reached but is not a substitute for eliminating obsolete dependencies or obtaining a supported provider configuration. Preserve a rollback owner and evidence plan before seeking authorization to edit DNS.
Fictional diagnosis: a late transactional route
A fictional customer policy checks supplier A before supplier B. For a hypothetical transactional sender, A does not authorize the address. Assume A’s evaluated branch consumes four counted terms in addition to the customer’s include of A. Evaluation then reaches the customer’s include of B, bringing the running total to six. Assume B requires five further counted terms before it can establish a match. The proposed path would attempt an eleventh counted term and exceed the ten-term limit.
These numbers are an invented teaching example, not measurements of named suppliers. The important point is the shared running total. A dashboard that reports “two customer includes” would miss the problem, while a diagram that sums every possible branch might exaggerate the path for another sender that matches early inside A. Both views need labels and context.
A proposed repair is not automatically to move B first. That might help this route while moving A’s legitimate traffic onto a longer path. The defensible next step is to identify unused dependencies, obtain provider-confirmed alternatives where available, and compare the affected routes under the proposed design. No replacement record or successful reevaluation is claimed here.
Plan for change without promising permanent headroom
Supplier-managed records can change after a review. Record the snapshot time and ownership boundary rather than declaring that a dependency count is permanently safe. Where a documented change process exists, track the responsible supplier and the customer route owner. A monitoring proposal should define what changes matter, who reviews them and when a rollback decision is needed, without pretending monitoring is already deployed.
Avoid simplistic flattening advice. Replacing a maintained dependency with a copied list of addresses changes who is responsible for keeping authorization current. Stale addresses can break legitimate mail or preserve authorization longer than intended. Any alternative needs a supported maintenance design, actual route evidence and review of its security consequences. A smaller visible record is not automatically a safer policy.
Acceptance should cover at least the routes affected by the change and the meaningful nonmatching paths that reach later mechanisms. Document unsupported routes as unresolved. The aim is not to manufacture a green score; it is to show why the proposed policy authorizes the intended senders within the applicable evaluation constraints.
Evidence and release status
This manuscript contains no executed resolver queries, provider account changes or sent messages. Its dependency example is fictional. The required original evidence is an annotated path showing each counted term and the exact failing branch, and that remains open. No actual provider has confirmed a replacement configuration for this article.
Before operational publication, a qualified reviewer should verify the current source applicability, route inventory, transcript completeness and proposed change scope. Original evidence, human review, production routes, visual accessibility and owner release remain open alongside source applicability. Treat the worksheet as preparation for an authorized investigation, not proof that any real customer is over budget.