Prove what the include represents

Start with the exact SPF record and referenced domain. Trace the include to provider documentation, internal configuration, representative received messages, and an accountable owner. Similar vendor names are not enough: organizations can have multiple accounts or resellers with different return paths.

Expand the referenced policy with a bounded tool and record its dependencies. This creates a before-state for the lookup budget and helps identify whether another active service relies on the same include.

Establish that the sender is idle

Check application configuration, provider event history, credential use, recent trusted Authentication-Results, and authorized aggregate authentication data over a period that covers normal and seasonal traffic. Ask product, support, finance, and marketing owners about low-frequency workflows. A service that sends annual notices will look idle in a seven-day window.

Confirm that replacement messages use a different approved path and that suppression, bounce, and audit data have been retained according to policy. Revoke or disable sending credentials before relying on DNS removal as the only control when that is operationally safe.

Plan the DNS change

Write the complete current record and complete candidate record. Do not edit only a substring in a ticket. Validate that the candidate still has one SPF version, a deliberate order and ending, and acceptable processing limits. Record TTL, scheduled time, owner approval, expected change, monitoring window, and exact rollback value.

Remove and observe

Publish the candidate through the normal change process. Query authoritative DNS and relevant recursive resolvers. Send fresh tests through every remaining legitimate service and inspect the SPF identity and result at trusted receivers.

Monitor for unexpected SPF failures, provider events, bounces, and owner reports. If a legitimate forgotten stream appears, use the documented rollback while deciding whether to reauthorize or migrate it; do not improvise a broad +all or unrelated include.

Close the retirement

After the observation window, update the sender inventory, credential register, and DNS dependency notes. The successful outcome is smaller authorized scope and lower operational complexity with no unexplained legitimate failures. Removing an include is a security and governance improvement only when the organization also removed or accounted for the system behind it.