Clean, Suppress or Restart an Inherited List

If you have inherited a list of around a million contacts, the choice is rarely between three equal options. Clean it when you can prove where most addresses came from and a meaningful share has opened, clicked or ordered in the last twelve months. Run a fresh permission pass when consent provenance is missing or the file is mostly dormant, and plan on keeping two to eight percent of it. Suppression is not a third road, it is the mechanism you use to carry out whichever of the two you pick.

Key takeaways

Two numbers decide it: the share of the list with documented consent provenance, and the share with any engagement event in the last twelve months. Below roughly ten percent on the second one, remediation is theatre.
A re-permission campaign is still a campaign. Sending it to the whole inherited file is the single most common way operators destroy a domain while trying to save a list.
Suppress, do not delete. Deleting a profile deletes the evidence that someone opted out, and the next CSV import silently mails them again.
Send in recency cohorts, ascending risk, with a hard stop rule per cohort. Order of sending matters more than the size of the file.
Judge the outcome on delivered rate and spam rate per mailbox provider, not on list size or on aggregate open rate.

What each option commits you to

Cleaning means you keep the file, remove the addresses that cannot be mailed safely, and rebuild sending volume from the healthiest cohort outward. It commits you to four to eight weeks of restricted volume and to defending the decision if a spam trap surfaces later. A fresh permission pass means you treat the inherited file as a prospect pool, send a small, tightly scoped opt-in request to the most plausible subset, and start over with whoever confirms. It commits you to a much smaller list and to explaining a revenue dip to whoever expects the list to perform on day one.

The third word in the title, suppress, is what you actually do to the addresses you drop under either plan. Suppression keeps the address on record in a do-not-send state so future imports cannot resurrect it. In Klaviyo, suppressed profiles are excluded from sending and do not count toward your active profile billing, which removes the usual finance argument for deleting them (Klaviyo, understanding suppressed profiles).

The audit to run before you send anything

Before you send a single message, answer five questions about the file, because the answers change the recommendation more than the size does.

Where did each address come from? Look for a source or signup method field on every profile. If more than a third of the file has no source, you are working with an unknown-provenance list regardless of what the previous owner told you.
When did each address arrive? Pull the created date distribution by month. A file where sixty percent of profiles predate the last two years behaves very differently from one that grew steadily.
When did each address last do anything? Last open, last click, last order, last site event. Take the most recent of the four per profile.
What is the mailbox provider mix? Split by domain. Gmail plus Google Workspace, Microsoft (outlook.com, hotmail.com, live.com and hosted business domains), Yahoo and Apple typically cover most of a US consumer file. Your exposure is concentrated wherever your largest bucket is.
What is the sending history? Ask for the last twelve months of send volume, complaint rate and bounce rate from the previous platform. If nobody has mailed this file in over a year, treat every address as unverified regardless of how it was collected.

Do this in a warehouse or a spreadsheet export, not in the sending platform UI. You want the distribution, not a count.

The two numbers that decide it

Two figures from that audit carry the decision. Call them consent_documented_pct (profiles with an identifiable, plausible signup source) and engaged_12m_pct (profiles with any open, click, order or site event in the last twelve months).

Consent documented	Engaged in 12 months	Recommendation
Above 70%	Above 25%	Clean and resume. Standard hygiene plus a staged volume ramp.
Above 70%	10% to 25%	Clean, but mail only the engaged core for the first eight weeks and re-permission the dormant tail separately.
Below 70%	Above 25%	Clean the engaged portion, suppress everything with no source and no engagement. Do not re-permission unknown-source addresses.
Any	Below 10%	Fresh permission pass on the most recent cohort only. Suppress the rest.

The engagement threshold is not arbitrary. Gmail asks bulk senders (anyone sending more than 5,000 messages a day to Gmail) to keep the reported spam rate below 0.3 percent and states that senders should aim to stay well under 0.1 percent (Google, email sender guidelines). At a million addresses, a single send to the full file at even a 0.5 percent complaint rate produces five thousand complaints in one day. There is no recovery narrative that survives that. Below ten percent twelve-month engagement, you cannot assemble a first send large enough to matter without including addresses that will complain or hit a recycled trap.

If your business has a long natural repurchase cycle, twelve months may be the wrong denominator. Derive the window from your own repurchase curve rather than adopting it as a default, the same way you would size an engagement window by repurchase interval.

How to clean a list you decided to keep

Cleaning is three passes, run in this order, and only the third one involves sending.

Pass one, structural. Remove syntactically invalid addresses, role accounts (info@, sales@, support@, abuse@, postmaster@), duplicate profiles resolved to the same person, and anything already marked as a hard bounce or unsubscribe in the source platform. Role accounts are overrepresented in old ecommerce files and are a common complaint source.

Pass two, verification. Run the remainder through SMTP verification to catch mailboxes that no longer exist. Set expectations before you buy: verification tells you a domain accepts mail for an address, which is a weaker claim than it sounds on catch-all domains, and it says nothing at all about whether the person wants your email. If you are doing this at a million-address scale, the economics and the accuracy ceiling of running verification in-house are worth understanding, as are the limits of verification on catch-all domains.

Pass three, staged sending. Split the survivors into recency cohorts and send in ascending risk order: 0 to 90 days, 91 to 180, 181 to 365, then anything older that survived passes one and two. Start with the smallest healthy cohort and hold each stage for at least two sends before adding the next. M3AAWG's sender best practice documents describe this ramp pattern and the reputation logic behind it (M3AAWG published documents). Set a stop rule in writing before you begin: if any cohort produces a complaint rate above 0.1 percent or a bounce rate above 2 percent, you stop, you do not add the next cohort, and you suppress the offending cohort.

If the inherited file also comes with new sending infrastructure, the ramp and the domain warm-up are the same project, so warm the domain deliberately rather than assuming the list is your only variable.

How to run a permission pass without burning the domain

A re-permission campaign fails when operators treat it as exempt from deliverability physics. It is not. The message goes through the same authentication, the same filters and the same complaint counters as a promotion, and it goes to your least engaged people, which is the worst possible audience composition for a first send.

Scope it hard. Send the opt-in request only to addresses with a documented source and some signal of past activity, ordered by recency, in batches you can stop. For a million-address file, that often means a first batch of ten to thirty thousand, not a hundred thousand. Send from a subdomain you are willing to abandon, keep the transactional and confirmed-list sending on separate infrastructure, and do not put the re-permission traffic anywhere near a shared IP pool you depend on. Whether you are on shared or dedicated sending IPs changes the blast radius, which is one of the practical reasons the dedicated versus shared IP decision matters at this volume.

Make opting out trivially easy in the same message. Include a functioning List-Unsubscribe header with one-click support as specified in RFC 8058 (RFC 8058, one-click unsubscribe), which Gmail and Yahoo both expect from bulk senders. A visible unsubscribe link that costs you an address is cheaper than a spam complaint that costs you the domain.

Expect a confirmation rate between two and eight percent on a genuinely dormant file. Plan the business case around that number before you send, because everyone involved will be surprised by it afterwards otherwise.

Suppress or delete, and why it matters

Suppress. Deleting a profile removes the record that the person unsubscribed or complained, and the next data import, integration resync or CSV upload from a well-meaning colleague will re-add them as a fresh subscriber. That is the most common way a store mails someone who unsubscribed eighteen months earlier, and it is a compliance problem as much as a deliverability one. CAN-SPAM requires you to honour an opt-out within ten business days and to keep honouring it, which is impossible if you destroyed the record (FTC, CAN-SPAM compliance guide).

Two operational details. First, export the full suppression list from the previous platform before you migrate anything, and import it into the new one before you import a single subscriber. Migrations that import subscribers first and suppressions second mail the suppressed population in the gap. Second, keep a distinct reason code per suppressed address (unsubscribe, complaint, hard bounce, manual, inactive). When you later want to reconsider the inactive group, you need to be able to isolate it from the group you can never mail again.

How to tell within thirty days whether the call was right

Measure per mailbox provider, not in aggregate, because an inherited file almost always degrades unevenly. Enrol your sending domains in Google Postmaster Tools before the first send and watch domain reputation, spam rate and the authentication panels daily for the first month (Google, Postmaster Tools help). Microsoft publishes its own postmaster policies and sender support pathways for outlook.com and hosted Microsoft domains (Outlook.com postmaster policies), and Microsoft traffic frequently deteriorates before Gmail does on an old file.

The signals worth tracking, in order of how early they move:

Delivered rate by domain. A drop confined to one provider is a reputation problem with that provider, not a list problem.
Spam rate in Postmaster. Sustained above 0.1 percent means stop adding cohorts. Above 0.3 percent means stop sending to anything outside the engaged core.
Bounce rate per cohort. The older cohorts will bounce harder. If a cohort exceeds 2 percent, suppress the whole cohort rather than the bounced addresses only, because the bounce rate is telling you about the addresses that have not bounced yet.
Revenue per thousand delivered. This is the number that settles the argument with whoever wanted to keep the whole file. A cleaned list of eighty thousand that produces more revenue than the million-address file did is the outcome you are aiming for.

If the complaint numbers your platform reports and the numbers Postmaster reports disagree, that gap is itself diagnostic and worth investigating on its own terms. And if reputation slips once you are mailing again, find the specific segment causing it rather than cutting volume across the board, using the approach in finding the segment that is burning your domain.

Trade-offs and what I would do

The honest trade-off is between recoverable revenue and recoverable reputation, and they are not symmetric. A list you cleaned too aggressively can be rebuilt through acquisition over two quarters. A domain that Gmail has decided is a spam source takes longer, costs more, and puts your transactional mail at risk while you fix it. When the two are in tension, protect the domain.

The argument for cleaning rather than restarting is almost always financial and almost always made by someone who paid for the list or acquired the company that built it. It is a legitimate argument when provenance is documented. It becomes wishful thinking when nobody can say where the addresses came from, because unknown provenance at a million-address scale reliably means purchased data, scraped data, or a co-registration deal somewhere in the history, and all three carry spam traps.

What I would do, given the file described in this queue item: run the audit, take the twelve-month engaged cohort and mail it as if it were the entire list, suppress everything with no source and no engagement immediately and permanently, and run a single scoped permission pass at the middle group (documented source, dormant) in batches of twenty thousand with a hard stop rule. I would not re-permission unknown-source addresses at all, because the cost of being wrong about them is paid by the addresses I do trust. I would tell the stakeholder the list is now eighty thousand people and set the revenue expectation against that number in week one, not week six. The uncomfortable conversation early is cheaper than the deliverability recovery project later, and if the domain does start slipping, the diagnostic path is the same one you would follow for any store whose email lands in spam.