Choosing an SPF operating model is a decision about who maintains sending authority. “Hosted” and “dynamic” are not substitutes for an architecture diagram. Before comparing costs, ask what remains in your DNS, what another organisation can change, and how a failed update or unavailable dependency affects your mail.
Describe the models in concrete terms
In a manually managed model, your team edits the policy and reviews dependencies. You may still rely on provider-controlled includes, so manual editing does not mean every input is under your control. In a hosted model, another service may manage a referenced policy, generate a proposed record, or publish changes through an integration. Those arrangements grant different powers.
“Dynamic SPF” can describe automated updates or a managed policy service. It is not a separate version marker or a guarantee about freshness. Ask the supplier to draw the exact lookup and update paths, naming the DNS zones, editor accounts and monitoring systems involved. Avoid assuming a feature merely because it appears in a marketing category.
Separate protocol rules from service promises
RFC 7208 governs SPF evaluation regardless of the management model. A managed service does not grant a larger evaluated-term budget. Its generated or hosted output must still behave correctly for your sending identities.
Ask for evidence about the candidate record, not only a dashboard score. Require representative positive and negative evaluations, the dependency tree, supported policy constructs and handling of failed upstream reads. For any flattened output, use the flattening assessment to examine semantics and freshness.
Build a responsibility comparison
For each option, name the person or supplier responsible for approving a sender, maintaining its address scope, publishing DNS, noticing failed updates and restoring service. Mark a responsibility unresolved when neither side owns it. An apparently inexpensive option may depend on an administrator doing unbudgeted daily work.
Use this illustrative comparison exercise. Your payroll service needs a new envelope domain. Under one proposal, the supplier emails instructions and your DNS team implements them. Under another, a management service can change the referenced authorisation without another local edit. Neither model is inherently the winner. The second requires stronger attention to the supplier's change controls; the first requires a reliable internal response process.
Ask who can remove a departing vendor and how you will prove removal happened. A system that makes onboarding simple but leaves decommissioning unclear is incomplete.
Assess availability and change visibility
List the dependencies a receiver must reach and those used only by a background updater. A live policy dependency can affect evaluation when it is unavailable. A failed background updater can instead leave an older published policy in place. Both matter, but their symptoms and recovery procedures differ.
Request an export of the active configuration, change history and the original provider mappings. Confirm whether alerts reach a monitored destination when a subscription expires, a credential stops working or a significant range change occurs. Evaluate access controls separately from convenience: avoid granting broad DNS access when a narrower supported integration would suffice.
Rehearse an exit before committing
Write down how to replace the managed dependency, who can edit the authoritative zone and which sending tests will validate the replacement. Check contract and cancellation details directly when purchasing; this guide does not assert any supplier's terms. Preserve the last working configuration but do not assume it will remain current indefinitely after leaving the service.
Make the decision using ongoing labour, supported semantics, observable updates, incident response and exit readiness. Keep the sender inventory outside any one vendor dashboard so responsibility remains understandable after a personnel or supplier change.
Put the decision in writing
For a hypothetical managed option, record whether it edits your DNS, controls an include target or only generates a proposal. Assign the sender approver, publisher, upstream-change monitor and recovery owner. If the supplier owns the live target but no one owns outage escalation, the operating model has a gap. If it only generates text, DNS publication and stale-output handling still need an owner. No supplier capability or pricing is assumed.