Customer Offboarding and Deprovisioning (Voluntary)

When a customer leaves on good terms, you still have to wind down their sending, their IP addresses and their data. The customer may have reached the end of a contract, be moving to another platform, or be closing their business. For accounts you close for a breach of the acceptable use policy (AUP), which move from a pause to suspension and then termination, see Account Enforcement. For removing a tenant who damaged a shared pool, see Pool Recovery.

The end state is the same in every case: no sending identity, no live IP addresses, no orphaned DNS records, and revoked credentials. When the customer is leaving voluntarily, the pace is cooperative. The goal is an orderly wind-down that protects the customer's reputation at their next platform, the platform's shared reputation, and the platform's data protection obligations.

This runbook adds no new mechanics. Each phase puts in order a procedure that is documented in full elsewhere and links to it. If a voluntary exit has to move faster, because abuse is suspected or the customer has not paid, switch to the shorter ladder in Account Enforcement.

Preconditions

Before you change anything, confirm and record:

• That the offboarding is genuinely voluntary. An abuse exit presented as a voluntary one follows Account Enforcement.
• The effective cut-off date, and whether the customer needs a read-only grace period after the last send, for reporting or data export.
• Whether the IP addresses are dedicated or shared. A customer on the shared pool has no IP address to give up, so skip Phase 3. A customer on dedicated IP addresses leaves a warmed asset, and the platform must decide how to recover it.
• Whether the customer's sending domain is delegated to the platform: DKIM delegated by CNAME, a custom MAIL FROM or return-path subdomain, or CNAME records for link branding. Those DNS records live in the customer's zone, so the customer must remove them when you tell them to.
• Any outstanding obligations to data subjects. A pending erasure request changes how the final data is handled (see Phase 4).

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

1. Close intake first, not the queue. Disable API keys and SMTP credentials for new submissions (see Phase 5) so that no new mail comes in, but let the mail transfer agent (MTA) finish what it has already accepted. Killing the queue while mail is in flight strands messages that were accepted but not transmitted. The loss is silent, the customer will rightly complain about it, and some recipients may receive only part of a send.
2. Let queued and deferred mail drain naturally. Let the normal retry schedule run until each message is delivered or expires, so that recipients whose mail was temporarily deferred still receive it. Set a drain deadline that matches your MTA's maximum retry window (commonly ~72h). After it, bounce or expire the mail still in the queue rather than holding it indefinitely.
3. Keep suppression checks running during the drain. Mail in flight must still respect bounce, complaint and unsubscribe suppression up to the last message. Do not switch off the suppression layer as part of the teardown (Suppression-List Architecture).
4. Confirm the queue is empty before you move on to IP and DNS teardown. If you retire authentication or IP addresses while mail is still draining, the final messages will fail authentication or leave from an IP address you have already taken back.

Phase 2: Retire the sending subdomain and DKIM selectors

Removing authentication reverses the onboarding steps in Customer Domain Authentication. Do it only after the queue has drained (Phase 1), because removing these records early breaks alignment on the customer's own last legitimate mail.

• Remove DNS records after the last send, and agree who owns each record. The customer must remove the records in their own zone: delegated DKIM CNAME records, the custom MAIL FROM or return-path subdomain, and link-branding CNAME records. Give them an explicit list and a date after which removal is safe. You remove the records in the platform's zone.
• Retire DKIM selectors deliberately. Stop signing with the customer's selectors, then remove or retire each selector's public key. Follow the retirement practice in DKIM Key Rotation. Leave a selector's public key published for a short time after you stop signing, so that any last message in flight or replayed still verifies, and then withdraw it. Do not remove the key the moment sending stops. Never publish an empty p= and leave it as the customer's live selector.
• Do not leave orphaned DNS records. A delegated subdomain or link-branding CNAME that still points at the platform after the customer leaves is a risk of takeover through a dangling record, and a source of mail wrongly attributed in future. The offboarding checklist is not complete until the customer confirms that every delegated record is removed.
• Warn the customer about DMARC. If the customer's DMARC alignment depended on your delegated subdomain, tell them that removing these records will affect their DMARC pass rate on any other mail streams that use the same domain. Managing that is their job, but tell them.

Phase 3: What to do with dedicated IP addresses (dedicated IP customers only)

A customer leaving a dedicated IP address leaves behind a warmed IP address that carries the reputation built by their sending. Treat it as an asset with a reputation, not as free inventory to give to the next tenant.

• Quarantine the IP address before reusing it. Do not reassign it to another customer immediately. The new customer would inherit the departing customer's reputation history, which is the recycled IP problem described in IP Acquisition Diligence. Let the IP address cool down, with no sending. Then treat any reassignment as a recycled IP address: run the reputation and blocklist checks before reuse, and warm it up again, as if you had acquired it from outside.
• Give it up or keep it. If the IP address is leased or transferred space that you will return, follow the return process in IP Acquisition Diligence. If you keep it, take it out of all active pools until it is reassigned, and warm it up again when you reuse it.
• Check its blocklist status as the customer leaves. Confirm the IP address is clean before you set it aside or return it. The departing customer's final sends may have earned a listing that you, not they, will otherwise carry into the next assignment. For delisting, see Reputation Monitoring, the delisting workflow.
• If the customer was on a shared pool, there is no IP address to recover. Do watch the pool's aggregate metrics for a sudden change once their volume leaves, because the departure of a large tenant changes the pool's mix. Pool Recovery covers a poisoned pool; this is the harmless version of the same shift in volume.

Phase 4: Final data handling, and reconciling suppression with erasure

Most teardown checklists get this phase wrong, because two obligations pull in opposite directions.

• Offer an export of the suppression list. The customer should be able to take their suppression list to their next platform, with bounces and complaints and the reason and origin of each entry. The export mechanics, and the cautions about incoming bulk jobs that remove entries, are in Suppression-List Architecture, bulk transfer.
• Reconcile retention with erasure. "Delete all this customer's data when they leave" conflicts with "never mail these addresses again", for people who opted out or complained. Deleting the suppression records that guarantee a person is never mailed again can expose those people to mail once more. This is a legal question, not an operational preference. GDPR and ESP Suppression Lists explains when suppressing or keeping an address keeps the ESP a Data Processor and when it turns it into a Data Controller. It also explains why a minimal suppression record (a hash of the address, the reason for suppression and the date, nothing more) can lawfully survive an erasure request, as the least intrusive way to honor the opt-out. For requests to object or to erase, see Right to Object and Erasure.
• The practical rule that follows from the legal analysis. When a customer leaves, delete the data used for sending (contact lists, campaign content, and personal data held to make sending possible), as the contract and the customer's instructions require. Keep the minimal suppression record unless your lawyers or the controller relationship say otherwise, and document the basis for the decision. Do not purge suppression data silently as a side effect of deleting the account.
• Honor the retention and return terms in the contract for logs, analytics and personal data, and record what was deleted, what was kept, and why.

Phase 5: Revoke access and credentials

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

• Revoke all sending credentials: API keys, SMTP users, OAuth tokens and webhook signing secrets. If you granted a read-only grace period for export, limit the remaining credentials to read-only access and make them expire at the end of the grace period.
• Revoke console access for the customer's staff, and remove any single sign-on (SSO) or federated identity mapping.
• Disable webhooks and callbacks that point at the customer's endpoints.
• Delete the tenant container last. Deleting the tenant also deletes the suppression entries scoped to it (Suppression-List Architecture), so this must come after the export and retention decision in Phase 4, never before.
• Record the closure: the final send date, what happened to the IP addresses, confirmations that DNS records were removed, and the data actions taken. This record protects the platform if a question comes up months later.

Ordering, in one line

Close intake, drain the queue, retire authentication and DNS, dispose of the IP addresses, settle the data (export, then reconcile suppression with erasure), and finally revoke access and delete the tenant. Each step assumes the one before it is finished. Changing the order strands mail, breaks alignment on the final sends, or purges suppression data you were required to keep.

Related articles

• Account Enforcement, for an involuntary or hostile exit
• Pool Recovery, on removing a tenant who damaged a shared pool (the severe version of Phase 3)
• IP Acquisition Diligence, on why a recovered dedicated IP address must be treated as recycled
• Customer Domain Authentication
• DKIM Key Rotation, on retiring selectors in Phase 2
• GDPR and ESP Suppression Lists, the legal answer for Phase 4
• Right to Object and Erasure
• Suppression-List Architecture