A bad list does not cost you a campaign. It costs you the domain the campaign was sent from, and the domain is the expensive part.
That is the case for spending an hour on a spreadsheet before anybody presses send. Seven passes, in order, each one answering a question that gets much more expensive to answer later. Only one of them, verification, needs a tool you may have to pay for.
The short version, for anyone who wants the rule before the reasoning: if the file cannot tell you where it came from, how many unique companies are in it, and when the addresses were last verified, it is not ready to send to, whatever it cost.
Pass one: ask where the file came from
Do this before you open it, because the answer predicts most of what you are about to find.
Lists bought cheaply from a freelancer are the worst offenders. They come back looking complete, and the damage shows up on the send as low open rates and a bounce rate that gets your sending domain flagged in week one. The economics are simple enough. Nobody builds a genuinely researched list of ten thousand decision-makers for a few hundred euros, so what you receive is a scrape with the gaps filled by guessing.
A purchased database has the opposite problem. The data was real when it was collected, and some of it was collected in 2022.
A platform export is usually accurate and usually too broad, because the filters were set by whoever was in a hurry.
An in-house build is the only one where you can interrogate the decisions, which is why the list build procedure is worth owning yourself.
If you commissioned the file, ask the supplier three questions: what source the records came from, what was verified and when, and what percentage of rows they filled in by pattern rather than by finding. An honest answer to the third question is the one that separates a real builder from a reseller. The same questions work well when you are choosing who to buy outbound from.
Pass two: count things, do not read them
Open the file and measure it before you look at any individual person.
Row count. Unique company domains, which is the number that actually matters, because two thousand rows across four hundred companies is a much smaller campaign than it looks. Duplicate email addresses. Duplicate people appearing under two spellings of the same company.
Then count role addresses: info@, sales@, contact@, office@. A file where more than a few percent of rows are role addresses was built to look full.
Count blank cells in the fields your sequence relies on. If your first line needs a first name and a company name, every row missing either one is a render error waiting to happen in somebody's inbox.
Pass three: read the job titles as a frequency table
Do not scroll the rows. Group by job title and look at the list of distinct values with counts next to them.
Two minutes of work, and nothing else shows you so quickly what you actually bought. Generic titles turn up in bulk: Assistant, Associate, Manager, Coordinator, Specialist. Those get excluded deliberately. They cannot sign anything and they cannot start anything, which is the only test this pass applies.
What you want is the shape of the table. If the top five titles by count include one that cannot buy from you, and it accounts for a quarter of the file, the file was filtered for the wrong thing. Trimming will not fix a wrong filter.
Pass four: check what was verified, and what a catch-all means
Run the whole file through verification, and let only what comes back clean into the main send. This is neither optional nor expensive.
My team works to under 0.5% bounces, far inside the usual 2% guideline.
Catch-all domains are the part people get wrong. A catch-all accepts everything, so verification cannot confirm or deny the address. That is not a pass. Segment them, send to them separately and in small volume, and watch what comes back before you let them anywhere near your main sending.
If the file came back with a very high verified rate and almost no catch-alls, be more suspicious, not less. That result is rarer than suppliers suggest.
Pass five: be honest about coverage
No single data source finds everybody, and even stacked providers leave gaps. The vendors selling multi-source enrichment say so themselves, loudly. So when a file arrives looking complete, ask what happened to the rows that should have been hard to find.
Missing rows are an inconvenience. Invented rows are a bounce.
Pass six: write ten first lines
Pick ten rows at random, spread across the file, and write the opening sentence of the email for each one by hand.
Not the whole email. One sentence, the one that says why you are writing to this specific person.
You will get through three or four comfortably, then hit one where you have nothing to say, and that is the finding. If you cannot write an honest first line for a row, the sequence cannot either, and the reader will feel exactly that. Ten rows is enough to tell you whether the file is full of people or full of addresses.
This is also the check that tells you whether the problem is data quality or targeting. Clean data on the wrong people passes every technical test in this post.
Pass seven: suppress before you send, not after
Remove your current customers. Remove anyone in live pipeline. Remove people who already told you no in the last twelve months, and competitors, and anyone a colleague is already talking to.
Cold-emailing an existing customer is the single most embarrassing failure in outbound and it happens constantly, because the suppression list lives in a CRM that nobody cross-referenced against a file that came from somewhere else.
The rule at the end
Three verdicts, and the honest one is usually the middle.
Send it if provenance is clear, verification is current, the title table looks like buyers, and you could write ten first lines without straining.
Fix it if the shape is right and the data is stale. Re-verify, cut the role addresses and the blanks, segment the catch-alls, and accept that the file is smaller than you were told.
Bin it if you cannot establish where it came from, or if the ten-line test fails on half the rows. A failed list does not get a smaller send as a compromise. A smaller send from a bad file is the same mistake at a slower speed, and it damages the same domain.
None of this replaces the argument about why the list matters more than the message. It is what you do on the Tuesday morning after you accept it.