Why Do Purchased Leads Bounce?

The pattern shows up in the same story, over and over

I've read a lot of threads from people who bought lead lists, and the story barely changes between them. Someone buys a list. They load it into their sender. Within the first few hundred sends, a meaningful share of it bounces, not one or two stray addresses but enough to be alarming on its own.

"I recently bought about 3000 leads from a website... and every single one of those emails bounced. It was extremely frustrating," one person wrote on r/DigitalMarketing after describing exactly this. The rougher version of the same complaint shows up wherever buyers compare notes: a large share of a bought list turns out to be dead addresses, and every one of them lands on the sender domain of whoever paid for the rows.

The complaint barely changes from telling to telling, and nobody has that much bad luck. The failure is structural, a property of how purchased lists get built and sold, and once you see how these lists come together, the bounces stop being surprising.

Reason one: the data was already stale when it was sold

A business's contact info starts decaying the moment it's collected. People change jobs. Companies close, merge, or rebrand. A generic inbox gets abandoned when the person who set it up leaves. None of that shows up in a database until someone re-checks it, and re-checking costs money the list seller doesn't want to spend before the sale.

Most list products are built once and sold many times. The gap between "when this row was collected" and "when you actually send to it" can run months, sometimes longer, and every month in that gap is another chance for the email to have gone dead.

The seller never feels any of that decay. You do, at send time.

Reason two: nothing gets tested before it's counted as a "lead"

Most sellers never confirm the mailbox at all. They confirm the row exists, sometimes not even that carefully. A guessed email pattern (first initial + last name @ company domain) gets counted the same as a confirmed one, and neither the seller nor the buyer finds out which is which until the send bounces.

That's the gap between validation and verification. Validation checks that an address is formatted correctly. Verification checks the mailbox itself against the mail server, the same kind of SMTP-level check Google and other major providers expect senders to run before large sends (see Google's own bulk sender guidelines). A list that's only been validated, not verified, looks clean on a spreadsheet and still bounces on send. The two checks even show up as separate line items on a lot of scraper pricing pages.

Reason three: the same rows get resold, again and again

A list broker's inventory doesn't disappear after one sale. The same database, or a close variant of it, gets repackaged and sold to the next buyer, and the next. Every resale compounds the staleness problem from reason one, because nobody in the resale chain is refreshing the underlying data.

A list that was deliverability-tested before the sale behaves differently at send time than one that was never checked at all.

There's a related labor cost that doesn't show up in the bounce-rate complaints directly but sits right underneath them: the list-building and cleanup routinely take longer than the outreach they feed. That's the resale problem's second-order effect. Once you know a list might be stale or resold, you can't trust it without checking it yourself, and checking it yourself is the exact manual work a lot of buyers were trying to skip by purchasing in the first place.

What actually fixes this

None of the three reasons above are things a buyer can inspect from a spreadsheet. Stale data looks identical to fresh data until you send to it. A guessed email looks identical to a confirmed one. A resold list looks identical to a first-sale list. The only way to know which you have is to test it, and testing after you've already paid means you've already eaten the cost either way. The mechanical junk is the one exception: a browser-based cleanup pass catches duplicates and malformed rows for free, but whether an address accepts mail only shows up when it's tested against the mailbox.

That asymmetry is why I built Nose for Leads to test before the charge, not after. It sources and deliverability-tests every email before it counts toward your bill. A lead that fails verification gets cut and you're never charged for it, along with a receipt showing what got cut and why. If you're weighing this against a scraper-plus-manual-cleanup workflow, how to clean a scraped lead list before cold email walks the DIY version of the same problem. Or run your exact niche and city through the pay-per-validated pricing and see what a pre-verified list actually looks like before you build around one.

This post covers list-source bounces specifically, purchased and resold data. If your list came from your own scraping or an existing CRM and you're still seeing high bounce rates, the causes run wider than a bad broker. [Why does my cold email list have so many bounces(/blog/why-does-my-cold-email-list-have-so-many-bounces) covers the fuller diagnostic, including warmup and sending infrastructure issues that get tangled up with list quality. And if bounces are climbing on a domain you're sending from right now, that post's triage section covers what to do about the damage itself, not just the list underneath it.

Curious what your own list looks like verified first? Run 25 free validated leads at signup and compare the pass rate against what's sitting in your CRM now.