An SPF dependency register answers a practical question: if this DNS value changes or this provider disappears, which business mail is affected and who can decide what to do? A copy of the top-level TXT record cannot answer that question on its own. Dependencies may be nested, controlled outside your organisation and reached only for particular inputs.
Model the policy and its consumers
Create one policy entry for each SMTP domain in use, with its exact DNS owner name, current record, capture time, zone owner and change process. Attach the applications and business units that use that identity. Keep visible From domains in separate fields so nobody mistakes them for the SPF lookup identity. A parent domain's SPF record is not automatically inherited by a child. RFC 7208 §2.4, RFC 7208 §4.
Add an edge for each include, redirect and other DNS-dependent term, identifying the target and who controls it. Include and redirect are not interchangeable: an include matches when its recursive check returns pass, while redirect delegates evaluation when the current policy reaches that modifier's conditions. Preserve term order and qualifiers in the snapshot. RFC 7208 §5.2, RFC 7208 §6.1.
Store enough evidence to act
Recommended register fields are: policy domain; business service; business owner; technical owner; provider account reference; dependency target; reason for permission; representative sending IPs; normal and failover envelope domains; snapshot date; evaluated-path result; proposed next review; and retirement condition. Keep credentials and private keys out of the register. Restrict internal account references to appropriate reviewers.
For dynamic macros, record both the expression and representative expanded values. A flattened dependency diagram without the input identity, IP and time is not a complete evaluation trace. SPF's DNS-query-causing term limit applies during evaluation, including recursive checks, so one path can reach a problem that another path avoids. RFC 7208 §4.6.4, RFC 7208 §7.
Make the register useful across teams
Illustrative example: procurement and customer support both depend on _spf.service.example.net through the same organisational policy. Procurement plans to end its contract and requests removal. The dependency register exposes the support service before the shared include is deleted. The decision becomes service retirement or isolation, rather than an unreviewed DNS cleanup.
Assign one technical policy owner to coordinate shared changes, while retaining business accountability for each consumer. Require onboarding to add the owner and test evidence, migrations to update dependencies, and offboarding to resolve remaining consumers. This is an operational recommendation, not an extra SPF protocol requirement.
Review changes rather than chasing a score
Diff snapshots to detect new targets, removed authorisations, enlarged ranges and changed lookup paths. Investigate a change in context: a provider may legitimately rotate infrastructure. Verify high-impact changes using current first-party instructions and received-message evidence. Archive the old state and the decision, then update the register after the DNS change succeeds.
A useful completion test is a tabletop exercise: choose one dependency and identify every affected service, the decision owner, the test route and the rollback path. If the team cannot do that, the register still has a gap even if every current SPF check passes.
Use a concrete decision record
For the shared-provider example, give the dependency two consumer entries, procurement and support, with separate owners and retirement conditions. If procurement exits while support remains, removing the common positive include is not yet justified. Capture the current policy, term qualifier, representative IP/envelope inputs and nested target snapshots before proposing isolation. This example illustrates a decision, not a completed inventory audit.