Customer Offboarding and Deprovisioning (Voluntary)

The customer-lifecycle articles in this KB mostly end badly — Account Enforcement covers the involuntary teardown (AUP breach → pause → suspension → termination), and Pool Recovery covers evicting a tenant who torched a shared pool. This runbook covers the ordinary case: a customer leaving on good terms (contract ended, migrating to another platform, business wound down). The end state is the same — no sending identity, no live IPs, no orphaned DNS, credentials revoked — but the pacing is cooperative, so the goal is an orderly wind-down that protects the customer's own destination reputation, the platform's shared reputation, and the platform's data-protection posture.

This is composition, not new mechanics: each phase sequences a procedure documented in full elsewhere and cross-links to it rather than restating it. Where a voluntary teardown must move faster (a suspected-abuse or non-payment exit), branch to Account Enforcement for the compressed ladder.

Preconditions

Before touching anything, confirm and record:

• Offboarding is genuinely voluntary (not a disguised abuse exit — those follow Account Enforcement).
• The effective cut-off date, and whether the customer needs a read-only grace window for reporting/data export after last send.
• Dedicated vs shared IPs. A customer on the shared pool has no IP to relinquish — skip Phase 3. A customer on dedicated IPs owns a warmed asset the platform must decide how to recover.
• Whether the customer's sending domain is delegated to the platform (CNAME-delegated DKIM, custom MAIL FROM / return-path subdomain, link-branding CNAMEs) — those DNS records live in the customer's zone and must be retired by them, on cue from you.
• Any outstanding data-subject obligations (a pending erasure request changes final-data handling — see Phase 4).

Phase 1 — Stop new sends and drain in-flight mail

1. Close intake first, not the queue. Disable API keys / SMTP credentials for new submissions (see Phase 5) so no new mail enters, but let the MTA finish what is already accepted. Killing the queue mid-flight strands accepted-but-untransmitted mail, produces silent message loss the customer will (rightly) complain about, and can leave recipients with half a send.
2. Let queued and deferred mail drain naturally. Allow the normal retry schedule to run to completion or expiry so temporarily-deferred recipients still get delivered. Set a drain deadline aligned to your MTA's max retry window (commonly ~72h) after which remaining queued mail is bounced/expired rather than held indefinitely.
3. Keep suppression checking live through the drain. In-flight mail must still honor bounce/complaint/unsubscribe suppression right up to the last message — do not disable the suppression layer as part of teardown (Suppression-List Architecture).
4. Confirm the queue is empty before advancing to IP and DNS teardown — retiring authentication or IPs while mail is still draining will make the final messages fail authentication or emit from a reclaimed IP.

Phase 2 — Retire the sending subdomain and DKIM selectors

Authentication teardown is the mirror image of onboarding in Customer Domain Authentication; do it only after the queue is drained (Phase 1), because pulling these records early breaks alignment on the customer's own last legitimate mail.

• Sequence DNS removal after last send, and coordinate who owns each record. Records in the customer's own zone (delegated DKIM CNAMEs, custom MAIL FROM / return-path subdomain, link-branding CNAMEs) must be removed by the customer — give them an explicit list and a "safe to remove after " cue. Records in the platform's zone, you remove.
• Retire DKIM selectors deliberately. Stop signing with the customer's selectors, then remove/retire the selector's public key. Follow the retirement discipline in DKIM Key Rotation: a selector's public key should be left published briefly after you stop signing so that any last in-flight or replayed message still verifies, then withdrawn — do not yank the key the instant sending stops. Never publish an empty p= and leave it dangling as the customer's live selector.
• Do not orphan DNS. A delegated subdomain or link-branding CNAME still pointing at the platform after the customer leaves is both a dangling-DNS takeover risk and a source of future misattributed mail. The offboarding checklist is not complete until every delegated record is confirmed removed on the customer side.
• Warn on DMARC. If the customer's DMARC alignment depended on your delegated subdomain, flag that removing these records will affect their DMARC pass rate on any other mail streams using the same domain — that is theirs to manage, but say so.

Phase 3 — Dedicated IP disposition (dedicated-IP customers only)

A departing dedicated-IP customer leaves behind a warmed IP carrying that customer's accumulated sending reputation. Treat it as a reputation-bearing asset, not free inventory to hand to the next tenant.

• Quarantine before reuse. Do not immediately reassign the IP to another customer. The incoming customer would inherit the departing customer's reputation history — the exact recycled-IP problem catalogued in IP Acquisition Diligence. Cool the IP down (no sending), then treat any reassignment as a recycled IP: run the pre-reuse reputation/blocklist checks and a fresh warm-up as if acquiring it externally.
• Relinquish vs retain. If the IP is leased/transferred space you will return, follow the return path in IP Acquisition Diligence. If you keep it, park it (out of all active pools) until reassigned, and re-warm on reuse.
• Check blocklist status on the way out. Verify the IP is clean before you park or return it — a departing customer's final sends may have earned a listing that you (not they) will otherwise carry into the next assignment. Delisting mechanics: Reputation Monitoring — delisting workflow.
• If the customer was on a shared pool, there is no IP to recover — but do watch the pool's aggregate metrics for a step-change after their volume leaves (a large departing tenant changes the pool's mix). Poisoned-pool handling is Pool Recovery; this is the benign version of the same volume-shift observation.

Phase 4 — Final data handling and the suppression / erasure reconciliation

This is the phase most teardown checklists get wrong, because two obligations pull in opposite directions.

• Offer suppression-list export. The customer should be able to take their suppression list to the next platform (bounces and complaints, with reason and provenance preserved) — the portability mechanics and the abuse cautions on inbound "remove these" jobs are in Suppression-List Architecture — bulk transfer.
• Reconcile retention against erasure. "Delete all this customer's data on exit" collides with "never mail these opted-out/complained addresses again." Deleting the suppression records that guarantee a person is never re-mailed can re-expose those people. This is a legal question, not an operational preference — route it to GDPR and ESP Suppression Lists, which resolves when suppressing/retaining an address keeps the ESP a Data Processor versus turning it into a Data Controller, and why a minimal suppression record (address hash + suppression reason + date, nothing more) can lawfully survive an erasure request as the least-intrusive means of honoring the opt-out. For the objection/erasure-request side, see Right to Object and Erasure.
• Practical rule that falls out of the legal analysis: on offboarding, delete the sendable data (contact lists, campaign content, personal data held to enable sending) per the contract and the customer's instruction, but retain the minimal suppression footprint unless counsel/the controller relationship says otherwise — and document the basis. Do not silently purge suppression as a side effect of "delete the account."
• Honor the contracted retention/return terms for logs, analytics, and PII, and record what was deleted, what was retained, and why.

Phase 5 — Access and credential revocation

Last, once mail has drained (Phase 1) and data handling is settled (Phase 4):

• Revoke all sending credentials: API keys, SMTP users, OAuth tokens, webhook signing secrets. If a read-only grace window was granted for export, scope the surviving credentials to read-only and set them to expire at the grace-window deadline.
• Revoke console/user access for the customer's operators, and remove any SSO / federated identity mapping.
• Disable webhooks and callbacks pointing at the customer's endpoints.
• Tear down the tenant container last — deleting the tenant also deletes its tenant-scoped suppression entries (Suppression-List Architecture), so this must come after the Phase 4 export/retention decision, never before.
• Record the closure: final send date, IP disposition, DNS-removal confirmations, data actions taken. This record is what protects the platform if a question arises months later.

Ordering, in one line

Close intake → drain the queue → retire authentication/DNS → dispose of IPs → settle data (export + suppression/erasure reconciliation) → revoke access and delete the tenant. Each step assumes the previous one finished; reordering them strands mail, breaks alignment on final sends, or purges suppression data you were obligated to keep.

Related

• Account Enforcement — the involuntary teardown ladder for AUP breach; branch here for a fast/hostile exit.
• Pool Recovery — evicting a tenant who damaged a shared pool (the disaster version of Phase 3).
• IP Acquisition Diligence — why a recovered dedicated IP must be treated as recycled before reuse.
• Customer Domain Authentication — the onboarding-side setup this phase reverses.
• DKIM Key Rotation — selector retirement discipline for Phase 2.
• GDPR and ESP Suppression Lists / Right to Object and Erasure — the legal answer to the retention-vs-erasure reconciliation in Phase 4.
• Suppression-List Architecture — export mechanics and tenant-deletion semantics.