- Select accounts before contacts, then add people, so every row has a reason to be on the list.
- Run each row through explicit gates for fit, duplicates, syntax, mailbox verification and risk, and track how many rows each gate rejects.
- Never append purchased or scraped rows to a list of engaged contacts, because one spam trap can taint everything near it.
Most lead lists are big, not clean, and the way to build a lead list that holds up starts before anyone exports a row. A list of twenty thousand rows bought cheaply often costs more than two thousand carefully chosen rows, because the extra eighteen thousand bring bounces, spam traps, people who left their jobs two years ago, and recipients who were never a fit to begin with. The cost doesn’t show up when you buy the list. It shows up three weeks later, when your domain’s bounce rate climbs and your reply rate falls below what the copy would earn.
The counter-intuitive truth is that the best list is usually the one you send to less. A tight list has fewer rows, but each row has a reason to be there and a reason to respond. This guide covers how to build that kind of list: start from accounts, source contacts from places that can be checked, pass every row through explicit gates, and keep the list clean once it’s in use. A worked example runs through the process so you can see where rows are lost and why.
How to build a lead list from accounts, not a database
The most common mistake is to start from a people database and filter downward. You search for “VP of Operations” in a region, export thousands of contacts, and then try to work out which companies are worth emailing. This produces lists that are full of people who match a title but not a situation.
Start instead from the account. Decide which companies are a fit for the offer, using firmographic filters that you can justify: company size, industry, geography, and the business model that makes the problem expensive. Then add trigger signals that suggest the problem is active right now. A hiring post for a role that usually signals a particular bottleneck, a funding announcement, a new product line, or a change in how a company describes its operations are all examples. Only after you have a short list of accounts should you look for people.
Here is a worked example. Imagine a company that sells invoicing software to mid-sized construction contractors. Its ideal account is a North American contractor with between 50 and 300 employees, doing commercial work, where billing is still partly manual. The first filter pulls contractors in that size band from business registries and industry directories, which produces a few thousand companies. The second filter removes firms that already run a major construction accounting platform, which you can often detect from public job descriptions or integration pages. The third filter adds signal: companies that have posted for an accounts receivable clerk or a controller in the last six months, which suggests billing is a pain they’re trying to solve with headcount.
The result, after those three filters, might be a few hundred accounts. That’s a list you can work with, and every account on it has a reason. Only then do you go looking for the people who own the billing process.
Where the rows come from
Sources differ in how accurate they are, how current, and how easy they are to check. The table below sets out the common options and their typical failure modes.
| Source | Strength | Failure mode | Best used for |
|---|---|---|---|
| Business registries | Accurate legal entity names and status | Often lacks contacts entirely | Confirming accounts are real and active |
| Job postings | Strong intent signal, dated | Stale after the role is filled | Trigger signals on accounts |
| Company websites and team pages | Current roles, first-party | Sparse for small firms | Confirming who owns a function |
| Association and member directories | Clear industry fit | Often years out of date | Building the initial account list |
| Data providers | Volume and fields | Duplicates, stale rows, uneven quality | Filling gaps, after a verification pass |
Treat every source as a claim to be checked, not a fact. A data provider’s row is a hypothesis about a person’s employer and role. A job posting is evidence that a role existed on a particular date. Registries confirm that a company exists, but not who runs it now. Combining them gives you a stronger row than any one source alone, and it also lets you spot contradictions, such as a provider listing a person at a company that its own team page no longer mentions.
The strongest lists we see are built from two or three sources that are cross-checked against each other, rather than from one large export. The cross-check is cheap compared with the cost of a bounce wave.
The gates every row should pass
A lead list should be built through a sequence of gates. Each gate has a clear rule and a clear reason for rejecting a row. A gate that rejects nothing is either badly designed or sitting on a list that was already filtered elsewhere.
Gate 1: fit. Each row must match the ICP rules you set for accounts and, where relevant, for roles. This is where you remove a company that falls outside the size band, a person whose role doesn’t own the problem, or an account with a conflicting tool. Track the rejection rate here. If this gate rejects most of your source data, your sourcing is wrong, not your filter.
Gate 2: duplicates and suppressions. Remove duplicates at the person level and at the domain level, because one company may appear under several spellings. Remove existing customers, active opportunities already in the CRM, and anyone who has opted out or unsubscribed. Duplicates inflate your volume and cause the same person to receive two sequences, which is one of the fastest ways to earn a complaint.
Gate 3: syntax and domain. Check that each address is well-formed and that its domain has mail servers. A missing MX record means mail to that domain can’t be delivered at all, so the row is pure cost. This check is fast and cheap, and it catches a surprising number of typos and dead domains.
Gate 4: mailbox verification. Run an SMTP-level check where possible, which asks the receiving server whether the mailbox exists without sending a message. Also flag disposable domains and role addresses. Verification returns three broad results: valid, invalid, and uncertain. Invalid rows go. Uncertain rows need a decision, which we’ll get to.
Gate 5: risk review. This is the gate most teams skip. It asks whether the row carries a risk that verification can’t see. Addresses that were last confirmed years ago, addresses sourced from scrapes or from sources with no engagement history, and addresses that look like traps belong here. Rows that fail this gate can be kept for a low-volume, carefully handled segment, or dropped.
Catch-all domains: the uncertain bucket
Catch-all domains deserve their own attention. A catch-all server accepts mail for any address at the domain, real or invented. A verification check against such a server returns “accepted” for everyone, so it can’t tell you whether a particular person exists. The result is an uncertain row that looks valid.
The honest response is to treat catch-all addresses as lower-confidence rows. You can send to them, but at a lower volume, in a separate segment, and with the expectation that some will bounce. The worst response is to assume a catch-all address is verified and send it into the main sequence. The bounce doesn’t come back until after the send, and by then the damage to your reputation is already counted.
The same caution applies to role addresses such as info@, sales@ and support@. They rarely belong to a decision-maker, they reply less often, and some of them are monitored by operators who watch for unsolicited mail. They’re not always wrong to keep, but they belong in their own segment with honest expectations.
Old data and spam traps
List decay is real. People change jobs, companies are acquired, and domains are retired. Commonly cited estimates put job change at a significant share of B2B contacts in a typical year, and that decay compounds on any list that isn’t refreshed. A list that was accurate eighteen months ago may now have a meaningful number of dead or reassigned addresses.
Spam traps make the problem sharper. A recycled trap is an old address that was abandoned and then reactivated to catch senders who keep mailing dormant lists. A pristine trap is an address that was never used by a person and was planted where scrapers would find it. Hitting either signals that the list was built or maintained carelessly, and it can damage placement well beyond the single address. You can’t see traps directly in your data, which is why the best defense is a sunset rule. Remove addresses that haven’t engaged within a set window, and treat any row older than your verification cycle as unverified until it’s checked again.
Our practice is to re-verify active lists on a regular cycle, typically every few months for lists in use, and to sunset anything that has been silent through several sends. Silence is not proof of a trap, but it’s the signal that tells you where to stop.
Compliance belongs in the build, not in a footnote
A list built from scraped or purchased data raises compliance questions, and those questions depend on where the recipients are. In the EU and UK, the GDPR and related rules govern how you can process personal data and send electronic mail, and the usual basis for B2B outreach is legitimate interest, which needs a documented assessment rather than an assumption. In the US, CAN-SPAM doesn’t require opt-in for B2B mail, but it does require an honest sender identity, a physical address, and a working opt-out honored promptly.
The practical step is to record where each row came from, when it was collected, and what basis you’re relying on. A list you can explain is a list you can defend. A list nobody can trace is a liability the first time someone asks where a row came from, and that is when you find out whether your sources were legitimate. This is general information rather than legal advice, and the details depend on your jurisdiction and your data.
A checklist for the build
Put the whole process into a short checklist and run it every time you build a lead list. Define the ICP rules for accounts before sourcing anything. Source from at least two places and cross-check. Pass every row through the five gates in order and record the count that each gate removes. Flag catch-all, role, and uncertain addresses into their own segment. Record the source and basis for every row. Set a sunset rule before the first send, not after the first bounce.
The number to watch is the rejection count per gate. If fit rejects most of the rows, sourcing is too broad. If dedupe rejects a lot, your sources overlap badly and you’re paying for the same people twice. If verification rejects a big share, your sources are stale. Each of those numbers points at a different fix.
Measure rejections, not just totals: a list report that says "2,000 rows" hides where those rows came from. Tracking how many rows each gate removes, by source, is the cheapest way to find which provider is padding your list with rows you'll never send to.
What to do after the first send
A clean list stays clean only if you maintain it. Remove hard bounces immediately, not in a batch at the end of a campaign. Keep a suppression list of anyone who has unsubscribed, replied with a refusal, or asked to be removed, and make sure every sending tool reads from it. Reconcile the list against your CRM regularly, so a person who became a customer doesn’t receive a cold sequence. Watch the hard bounce rate, which most teams try to keep under 2 percent, and treat a rise as a list problem before you treat it as a copy problem.
Keep purchased rows apart: never append a bought or scraped list to the contacts you're already emailing. One spam trap in the bought rows can damage the reputation of the whole sending domain, including sequences to people who were engaged. Verify and segment purchased data on its own before it goes anywhere near your working list.
Finding the people is only half the job. Verifying the rows and keeping them clean is the part that protects your reputation, and it’s the part most often skipped. For how those rows then reach the inbox, our deliverability checklist covers the sending side, and our piece on avoiding spam folder placement covers what happens when the list is weaker than it should be.
Wrap-up
When you build a lead list this way, it ends up smaller than most people expect and more defensible than they think. Start from accounts that fit the offer and show a live problem. Source from checkable places and cross-check them. Pass every row through explicit gates for fit, duplicates, syntax, mailbox verification and risk, and count what each gate removes. Keep the list clean after the first send, and never let unverified rows touch the contacts that are already engaged.
OutboundLeadPro includes a lead finder with a free Smart check on every email, so verification happens at the point where you need it, before the send. You can see how the lead finder fits into the workflow on the homepage, and the rest of the workflow is covered on the features page.