Canceling a vendor contract does not necessarily remove its ability to send authenticated mail for your domain. Offboarding must cover the service account, credentials, DNS relationships and operational dependencies that remain. The objective is to remove unnecessary authority while preserving the legitimate applications that may share it.
Establish the retirement boundary
Identify the exact vendor account, service purpose, owner and final authorized sending time. List scheduled jobs, retries, queued messages, inbound replies, bounce processing and integrations. Confirm whether the service is stopping completely or only losing one domain. Preserve the configuration and relevant evidence before access disappears, subject to retention and privacy requirements.
Inventory SPF mechanisms, DKIM keys or selector delegations, custom return paths, delegated zones, API credentials, connectors and report destinations used by that service. These are different dependencies with different revocation steps. DKIM key publication and verification are specified in RFC 6376; deleting a key too early can affect verification of already-signed messages. DKIM specification. Do not assume contract termination has changed DNS or revoked an API token.
Find shared authority before removal
For every proposed deletion, identify other applications that depend on the same object. A provider include in SPF may support several approved accounts. Removing it can harm legitimate mail; retaining it may leave a wider authorization path than intended. Determine whether the dependency can be split or the retired service can be disabled at its account boundary. Review the provider-specific behavior rather than treating an SPF record as a per-user permission list. RFC 7208.
Document a stop sequence, a verification sequence and recovery limits. A rollback that restores a compromised credential is not equivalent to one that restores an accidentally removed DNS record. If compromise is suspected, coordinate the response before re-enabling old authority. Normal offboarding and emergency containment may need different timing, but both need an accountable decision and evidence.
Avoid letting one successful check close every dependency
Consider a hypothetical retired billing account and a surviving payroll account at the same provider. Their selectors differ, but their SPF include is shared. Removing the retired selector does not establish that its API credential is revoked, and deleting the shared include could affect payroll. First map each object to the account boundary and surviving uses, then approve the specific stop sequence.
Suppose a later authorized DNS observation confirms the retired selector is absent while no provider-account revocation evidence is available. Record DNS retirement as observed and credential revocation as pending. Do not perform an unauthorized send to fill that gap; use the provider’s supported administrative evidence or an explicitly approved safe test. These are hypothetical decisions, not actual DNS or credential operations.
A retained public key for queued legitimate mail has a different purpose from an active credential that permits new sending. Balance verification continuity with any suspected compromise through the incident owner; do not adopt a universal retention delay or restore a compromised secret automatically.
Verify both removal and continuity
Test that the retired route no longer has the intended authority through an approved, safe method. Separately test the legitimate services that share infrastructure, including low-volume transactional paths. Check receiver authentication and business delivery outcomes rather than relying only on DNS publication. DMARC results describe domain alignment and handling, not proof that your inventory is complete. RFC 9989.
Close the offboarding record with removed dependencies, deliberately retained objects, reasons, owners and review dates. Preserve registration or receiving dependencies where the business still needs them. Monitor for later observations associated with the retired service and investigate their source rather than assuming every delayed report means revocation failed. The case is complete when the approved authority boundary and the evidence agree.
Close each authority independently
Keep account disablement, credential revocation, DNS retirement and surviving-flow checks as separate outcomes. Mark a missing provider postcheck pending even if all DNS checks pass. Name the owner and safe verification method for every retained dependency.