You paid for the list, ran it through a verifier, and got a report back saying 96% deliverable. Two days into the sequence your bounce rate is sitting at eight percent, your sending platform has throttled the account, and the replies you were getting last week have stopped.
Nobody lied to you. The verifier answered the question it was asked, and the question was narrower than the one you had in your head. Catch-all domains are usually where the missing four points went, and no amount of paying more per row will get rid of them.
What a verifier actually asks
An email verification tool opens a conversation with the mail server that handles a domain and asks whether it will accept mail for one specific address. It is the first half of a delivery, stopped before anything is sent.
The server can answer three ways. Yes, this mailbox exists. No, it doesn't. Or a third answer that gets translated into English badly by almost every tool on the market: I will accept mail for anything you send here, and I am not telling you what happens next.
Answer three is a catch-all. Some tools call it accept-all, some call it unknown, and the difference in wording is the whole problem.
Why so many company domains do this
A catch-all configuration accepts mail addressed to every possible mailbox at the domain, then sorts it out internally. Plenty of legitimate reasons exist for running one:
- Typos in a customer's address still reach somebody instead of vanishing.
- Old addresses keep working after people leave, so nothing important is lost mid-handover.
- The domain refuses to confirm which mailboxes exist, which is a standard defence against exactly the kind of probing a verifier does.
That last one matters more every year. A mail server that answers "no such user" is handing an attacker a free list of real employees, and security teams have been closing that off deliberately. The side effect is that verification gets less useful on precisely the well-run companies you most want to sell to.
So the share of your list that comes back accept-all is not random. It skews toward larger, better-defended organisations, which is often the top of your target list rather than the tail.
The bit that makes it expensive
Here is where a pattern-generated address turns into a bounce.
Most B2B lists are built at least partly by guessing address shapes. Somebody knows the company uses first.last@, so a name and a domain become an address. Run that guessed address against an ordinary domain and the server tells you plainly that it does not exist, and the row gets dropped.
Run it against a catch-all domain and you get a yes. A confident, clean, green yes, for a person who left in 2023, or for a name spelled wrong in the source, or for a shape the company stopped using two reorganisations ago. Your verifier did its job. It just could not see anything.
Then the message arrives, the internal routing finds nothing to route to, and it bounces after acceptance. Which is worse than a rejection at the door, because it happened on your reputation rather than in your report.
Read the status column, not the summary
Providers score the accept-all bucket differently, and some fold it into the headline number they show you. Two verifiers can process the same list and disagree by a wide margin without either being wrong, because one is reporting "not confirmed bad" and the other is reporting "confirmed good".
Open the per-row export. Count the statuses yourself. You want three piles:
- Valid. Confirmed by the receiving server.
- Invalid. Delete these. Not later, now.
- Accept-all, unknown, risky. Whatever your tool names it. This is the pile the argument is about.
That third number is your real uncertainty, and it is the one worth writing down before every campaign. If a supplier's headline percentage is meaningfully higher than your own count of pile one, you know what they folded in.
What to do with the pile you can't verify
Deleting it is the safe answer and usually the wrong one, because it throws away the accounts you were targeting on purpose. The workable answer is to stop treating those rows like the rest of the list.
Send to them separately. Their own sending mailbox, their own domain, their own volume ramp. If the bucket turns out to be full of dead addresses, the damage is contained to a sender you can afford to burn, and the domain carrying your good traffic never sees it.
Confirm the pattern somewhere else. You cannot verify the mailbox, but you can often verify the shape. One confirmed address at that company, from a signature, a press page or a reply you already have, tells you whether they use first.last@ or finitial@. A guessed address that matches a confirmed pattern at the same domain is a much better bet than one that doesn't.
Check the person before the address. Confirm the human still works there, then worry about the mailbox. Job changes are the single largest source of rot in a B2B list, and they are visible in public without touching a mail server at all.
Watch the bucket as a signal about the supplier. If accept-all rows from one source bounce far harder than rows from another, that source is guessing more than it admits. That is a fact about where to buy next quarter, not just about this campaign.
Re-verify close to the send. A list verified in March is not a verified list in August. We re-run verification before a sequence starts rather than when the list is delivered, because the gap between those two dates is where the decay happens.
The reputation maths nobody runs
The instinct is to count the wasted rows. Four hundred bad addresses out of eight thousand, a few pounds of verification credit, annoying but survivable.
Wrong pile. Mailbox providers watch how often mail from your domain is addressed to recipients who do not exist, and they use it as a proxy for whether you are sending to a list you built or a list you scraped. Cross their threshold and the filtering tightens on everything, including the 7,600 addresses that were fine. You do not get a warning that says so. You get a quiet drop in replies and a theory about your subject lines.
Your sending platform publishes its own limit for this. Find that number, treat it as a ceiling rather than a target, and pause the send when you approach it. A campaign stopped at four percent can be fixed. A domain with a month of bad history behind it takes far longer to bring back, and in the meantime every good message you send is paying for the bad ones.
Where to start this week
Export the last verification run and count the accept-all rows as a percentage of the file. That number is the honest size of what you do not know, and most people have never looked at it.
Then split it out of the main send. That single change does more for the health of your sending domain than any rewrite of the first line, and it costs an afternoon of setup. It is the same discipline that makes a bought contact list worth its price: know which rows are observed and which are inferred, and never let the two travel together.
When we build outbound lists, the accept-all count goes in the handover document next to the verified count, because a client who knows both numbers can read a bad week correctly. One who only sees the headline will go and rewrite the copy, which was never the thing that broke.
