Leaving a supplier that hosts SPF logic or DKIM DNS records changes a live trust dependency. It is not just a subscription cancellation. Inventory the exact DNS names and signing routes first, then replace the dependency while you still have the access and authority to recover. Keep reporting-only changes out of the same change window unless the plan genuinely requires them.
Identify what the supplier controls
For SPF, record the actual published policy and every include or redirect relationship. An include is evaluated as an SPF mechanism; redirect supplies another policy when applicable. Neither is merely a cosmetic alias. Evaluate the resulting policy against the DNS lookup limits in RFC 7208, including nested dependencies. Copying today's expanded IP addresses can become stale and does not preserve a supplier's future updates.
For DKIM, record each active selector, its exact DNS owner name, any CNAME or zone delegation and the signing service using the corresponding private key. RFC 6376 separates signing from public-key retrieval. Moving a public record does not give the replacement service the old private key, and changing an alias does not cause existing messages to be signed with the new selector.
Build the replacement before removing the old path
Establish the new sender authorization or signing route using values generated for the intended account. Verify authoritative DNS and test received messages through each critical application. If DNS or provider constraints prevent coexistence, record that constraint and use a controlled cutover with a tested recovery route. Do not assume two different TXT policies at the same SPF owner name create redundancy.
Preserve old DKIM public-key availability for the approved delayed-mail window after old signing stops. The appropriate interval depends on queue behavior, signature validity constraints, operational risk and provider retention. There is no universal TTL-length waiting rule: DNS caching and delayed delivery are different clocks. A compromised key can require revocation despite delayed-mail failures, which is an incident decision rather than routine migration housekeeping.
Distinguish new signing from delayed verification
Suppose an old queued message carries selector old and a newly generated message carries selector new. Each signature was valid when generated, and the messages remain unmodified. If the old public record is removed before a receiver retrieves it, that receiver may be unable to verify the old signature even while the new signature verifies with its own key. A cached usable key or another valid signature can change the observed result, so this is not a universal delivery prediction.
This hypothetical dependency example performs no signing, DNS query or verification. Restoring the correct public record may restore that lookup path, but cannot repair an expired signature, changed message or compromised signing key. Before cancellation, separately verify the new sending route, the approved old-key retention or revocation decision, and actual recovery access. A public-record export cannot restore private signing capability.
Make the exit reversible where appropriate
The change record should identify the old dependency, replacement, approval, expected DNS answers, authentication test, delayed-mail decision and rollback trigger. Keep the service active until its required replacement tests pass. If recovery requires an expired account or a domain relationship you no longer control, it is not an executable rollback.
After the agreed observation window, remove obsolete SPF authorization, selector delegations and access through the approved process. Recheck the actual authoritative answers and representative receiver results. Retain the exact before and after records and unresolved exceptions. Successful dashboard cancellation is the commercial end of the service, not evidence that the technical exit was safe.