A service exit is incomplete when the export exists but no one can explain or restore it. Start with the future operator's questions: which domains and senders are approved, what dependencies are live, why do exceptions exist, and which changes were authorized? An export should preserve those answers without transferring secrets or unnecessary personal data into an uncontrolled archive.
Define the export boundary
List domain and sender inventories, DNS and policy configuration, provider-specific generated values, report samples and history, parsing conventions, user and role assignments, exceptions, approvals and change logs. Record the time range, known gaps and export timezone. Keep data dictionaries and identifiers that link a report row to its original file. A screenshot of a graph is useful context but not a substitute for the underlying evidence.
Aggregate-report structure is specified in RFC 9990; dashboards can add their own attribution or normalization. Preserve enough raw content to distinguish standard fields from supplier interpretation. Do not treat a familiar provider label as proof that the business approved a particular sending account.
Separate configuration from credentials
Identify which export elements are safe operational metadata and which are credentials. DKIM public DNS records and selector names are not private signing keys. If moving private keys is both supported and authorized, use a separately approved secret-transfer process; do not place them in this general evidence bundle. When a provider will not export keys, plan new signing identities and a controlled transition rather than promising restoration from a public-key export.
Apply access and retention controls to report data and audit logs. A migration is not a reason to keep everything forever. Have the appropriate owner approve what is retained, who can open it and when it should be deleted. Make a list of unavailable items, including audit history or raw data the current plan cannot export, before the cancellation date.
Verify an export as data
Suppose an authorized export contains a sender inventory, change history and report index. A manifest records each filename, byte count and SHA-256 digest. A later read matching those trusted digests establishes byte consistency for the listed files, not that every required row was exported. An omitted exception file could leave all listed hashes matching while the archive is operationally incomplete.
This is a hypothetical integrity-versus-completeness example, not a generated archive or executed hash check. Require both a manifest check and reconciliation against a dated source inventory. A mismatch needs investigation rather than an automatic replacement of the trusted digest.
For an actual exit, reconcile exported row counts with a dated source inventory and document exclusions. Open the files using the replacement workflow. Confirm that time values, domain names, unique IDs and relationships survive. Test one retrieval task: given an exception ID, can the new operator find its owner, approval, expiry and affected sender? Record the result rather than marking a zip download as success.
Keep the archive useful after access ends
NIST SP 800-34 Rev. 1 describes contingency planning, testing and maintenance. Applying that general guidance here, nominate an archive custodian and test access without relying on the departing service. Store the manifest and an explanation of the export process with the data. Keep an independently controlled copy where the approved retention policy permits.
Before closure, obtain owner sign-off on missing history, replacement monitoring and any dependencies that cannot be restored from export. Preserve the old account only for a defined, authorized purpose and duration. The final exit record should say what was exported, what was verified, what remains unavailable and who accepted the gap. Do not call a verified checksum a complete disaster recovery test.