You Inherited a Purchased Email List. Now What?
Bought lists fail for reasons cleaning cannot fix. If one landed on your desk through an acquisition or a predecessor, here is how to assess the damage and what the defensible options actually are.
Two situations bring people to this question. Either someone is considering buying a list and wants to know whether verification makes it workable, or a list arrived through an acquisition, a departing colleague or a predecessor's enthusiasm, and now it is on your desk.
For the first group the answer is short: no, and the rest of this post explains why the failure is structural rather than a data-quality issue you can clean your way out of. For the second group, this is a triage guide.
01Why bought lists fail, in order of severity
Nobody agreed to hear from you. This is the one that cannot be repaired. Under GDPR, the UK GDPR and India's DPDP Act you need a lawful basis to process each address, and "a vendor sold it to me" is not one. Under CAN-SPAM the position in the US is more permissive for B2B, but permissive is not the same as free. Verification does not touch this problem in any way. A verified address you have no basis to mail is still an address you have no basis to mail.
Complaint rates on cold bought lists are catastrophic. This is the practical failure and it arrives fast. People who did not sign up do not unsubscribe, they report spam, because it is one click and it feels justified. Under the current bulk sender requirements Gmail enforces a hard ceiling of 0.30%, which on a 50,000-message send allows 150 complaints total. A cold bought list can produce that in the first few thousand messages. One campaign can put your sending domain in a hole that takes months to climb out of.
Bought lists are trap-dense. Spam traps are seeded deliberately into scraped and resold data, because that is precisely what they are for. They are ordinary mailboxes that accept mail, so they look identical to real addresses at the protocol level. No verification service detects them reliably, including this one. Hitting them repeatedly is how domains end up on Spamhaus.
The data is usually old. Lists get resold repeatedly, and each resale is further from the original collection date. B2B addresses decay quickly because people change jobs constantly. A list assembled three years ago has lost a large share of its addresses to ordinary churn, as our post on list decay sets out.
Your reputation is shared. If you send through a shared-IP ESP, the damage is not confined to you. This is why Mailchimp, Klaviyo, ActiveCampaign and most others prohibit purchased lists in their terms and will suspend accounts over it. Read your ESP's acceptable-use policy before you send anything, because getting suspended mid-campaign is worse than not sending.
02If the list is already yours: triage
You did not choose this and the list exists. Here is the order I would work in.
1. Establish provenance before you touch anything
Find out, in writing if possible, where the addresses came from. Not "a vendor," but which vendor, when, and on what basis they were collected. If there is a contract, read what it warrants.
This determines everything downstream. Three outcomes:
- Genuine opt-in with records. Rare for purchased data, but it happens with legitimate co-registration and event lists. If the records exist you may have something workable.
- Scraped or compiled from public sources. Common. No lawful basis for marketing under GDPR. Possibly defensible for B2B in some US contexts, and worth a legal opinion rather than my guess.
- Nobody knows. Also common, and the honest answer is that you have a liability rather than an asset.
If the answer is the third one, stop here. The remaining steps are about salvaging value from a list you can defend, and you cannot defend one whose origin nobody can describe.
2. Verify, but understand what you are learning
Run the list. This is worth doing even if you never send to it, because the results tell you what you actually have.
What you learn from the split:
- A high undeliverable rate confirms the list is old. Over 25% and you are looking at data assembled years ago.
- A high proportion of catch-all domains means large parts of the list are unverifiable in principle, because those servers accept everything.
- Heavy role-based addresses (
info@,sales@,admin@) suggests scraping rather than collection, because humans do not sign up with the shared inbox.
What you do not learn: whether anyone consented, and whether traps are present. Verification is silent on both.
A 500-address random sample on the free plan is enough to characterise a large list. You do not need to verify the whole thing to find out it is 30% dead.
3. Decide, and the honest options are narrow
Delete it. Genuinely the right answer more often than people want to hear, and it is the only option with no downside. If provenance is unknown, this is the choice that ends the problem rather than deferring it.
Permission pass, if you can defend the single send. Send one message asking people to opt in, and mail only those who do. The uncomfortable part is that this send is itself unsolicited email to people who did not consent, so it does not escape the basis problem, it concentrates it into one message. Under GDPR that is difficult to justify. In more permissive B2B jurisdictions it is sometimes done. Expect single-digit opt-in rates, and treat everyone who does not respond as permanently off the list.
Use it as research rather than as a mailing list. Company names and roles can inform targeting without you ever mailing the addresses. This is often where the only real value is.
Mail it as-is. Do not. This is the path that produces the blocklist listing and the ESP suspension.
4. Isolate anything you do send
If you have decided you can defend a send, do not put it anywhere near your main sending domain or IP. Use a separate subdomain and separate infrastructure, so that when the complaint rate comes in high it does not contaminate the reputation of the list you built properly.
Start small enough to abort. A few hundred messages, then read the complaint rate before deciding whether to continue. If it is above 0.10% you have your answer.
03The distinction that matters
There is a real difference between a purchased list and a rented one, and it gets blurred.
Purchased means you receive the addresses and mail them yourself. That is the situation described above.
Rented means a publisher mails their own list on your behalf. You never receive the addresses. Their subscribers consented to hear from them, the publisher owns the reputation risk, and if it goes badly it goes badly for them. This is ordinary advertising and it is fine.
If someone is offering you a list and the distinction is unclear, that is worth clarifying before money moves.
04What we ask of our own customers
Our terms require, in section 3.1, that addresses submitted for verification "were obtained lawfully and have not been derived from a data-breach corpus, scraped from a website in violation of that website's terms, or purchased from a third-party lead vendor of unknown provenance," and section 4 says we may ask you to evidence that basis.
That is not decoration. Verification services get used as a laundering step: take data of dubious origin, run it through a tool, and treat the clean output as legitimate. It does not work that way, and we would rather say so plainly than take the money and let you find out from a regulator.
05The short version
Cleaning a bought list makes it a clean bought list. The three things that make it dangerous, the missing lawful basis, the complaint rate, and the trap density, are all untouched by verification and two of them are undetectable by it.
If the list is already yours, establish where it came from first, sample it to find out what you have, and be genuinely willing to delete it. That is usually the cheapest outcome available, and it is always the only one with no tail risk.
Sample a list for free if you need to know what you inherited.
Start with 500 free validation credits. No card.
Both Free and Pro run the same scan engine, full SMTP probe, MX lookup, typo, disposable, domain checks, and the evidence chain on every verdict. The difference is the monthly credit pool (Free=500, Pro=10,000, Max=75,000) plus Pro's API and MCP access.