Removing a vendor's SPF include is not always the same as revoking that vendor's ability to pass SPF. Another mechanism may authorise the same source addresses. Conversely, one include may support several business services, so deleting it can disrupt a service that is still in use.
A safe retirement combines ownership review, policy dependency analysis and message tests. The output should explain what permission disappeared, what remains and why.
Establish the retirement scope
Identify the exact envelope domains affected and the business functions the vendor supports. Check invoices, scheduled reports, account notifications and seasonal campaigns, not just the most recent bulk send. Obtain service-owner confirmation that the sender is retired or that its replacement is ready.
Preserve the current SPF value, DNS TTL and provider configuration references. Record the mechanism proposed for removal and its purpose. A brand name inside an include can be a clue, but it is not proof that only one application depends on it.
Trace direct and indirect authorisation
Inspect nested includes and redirects using a standards-aware evaluator. Determine whether the vendor is reachable through another included policy, a broad ip4 or ip6 range, an a or mx mechanism, or a shared redirect target. Record these alternative paths before claiming revocation.
Also identify other domains that depend on any shared policy target you intend to edit. Under RFC 7208 §5.2 and RFC 7208 §6.1, removing a mechanism from a central _spf policy can affect many sending identities. The change scope is the dependency set, not simply the hostname visible in the DNS editor.
Do not treat a current include expansion as a permanent list of vendor addresses. Managed policies can change. Use the provider's supported information and your current architecture to understand what the mechanism is intended to authorise.
Work through an overlap example
Synthetic policy: v=spf1 ip4:192.0.2.0/24 include:_spf.vendor.example -all. Suppose the illustrative include also authorises 192.0.2.10. Removing the include does not stop 192.0.2.10 from passing, because the explicit /24 range already matches it under RFC 7208 §5.6 and RFC 7208 §4.6.2. Assume valid syntax, one selected record and no earlier error.
The opposite problem occurs when two applications use the same vendor include. Removing it because one application migrated can break the other. These examples use documentation-only values and assumed include behaviour; they are reasoning fixtures, not observed provider configurations.
Prepare tests and a recovery decision
Before editing, list the services expected to continue passing, the retired path expected to lose authorisation and any overlap that will deliberately remain. Test through controlled accounts and recipients. If you cannot exercise a retired service, document that limitation and use configuration evidence rather than inventing a successful negative test.
Approve the exact DNS change and recovery condition. If the vendor is suspected of compromise, blindly restoring its include may recreate the exposure. Agree an alternative route or explicit risk decision rather than treating rollback as automatically safe.
Where TTL reduction is useful, plan ahead: lowering it does not shorten the lifetime of answers already cached under the previous TTL. Under RFC 8767 §4, qualifying serve-stale behavior may retain and serve older data beyond TTL expiration, so TTL is not a global revocation deadline. After the change, inspect authoritative DNS and representative recursive answers, then validate remaining legitimate senders.
Separate SPF cleanup from full offboarding
SPF is only one permission surface. Vendor credentials, domain-verification tokens, delegated DNS, DKIM keys, application integrations and user accounts may require separate retirement. Removing an SPF include does not revoke those assets. Coordinate their owners and approvals without claiming the SPF change alone completes vendor offboarding.
For the SPF task, retain the exact before-and-after policies, dependency findings, expected results and actual test evidence. Watch relevant sending cycles long enough to cover the organisation's known jobs; do not select a universal observation period and assume it suits every service.
Close with precise language
If an overlapping mechanism remains, say that the named include was removed while some source authorisation still exists. If tests only cover active senders, say so. A useful closure statement describes the permission change and evidence boundaries, giving the next administrator enough context to avoid reintroducing the retired dependency.
Record the decision and its limits
For the overlap example, write the closure as “the include was removed; 192.0.2.10 remains authorised by ip4:192.0.2.0/24.” If the goal is full source revocation, identify and review that range rather than claiming success from the text deletion. Record unavailable tests as unavailable, and separate a proposed recovery option from an approved or executed restoration.