Every list-cleaning workflow I have seen works the same way. You upload a CSV, the tool probes every address, the dead rows come back marked, you delete them, and you are left with a smaller file and a feeling of hygiene. The file is genuinely better than it was. It is also already expiring.
What the pass actually removed
A cleaning pass removes four kinds of rows, and it is worth being precise about which ones, because they do not fail for the same reason:
| Removed | Why it was dead | Does the cause come back? |
|---|---|---|
| Hard bounce | The mailbox was deleted | Yes — new mailboxes close every month |
| Syntax / domain error | Typo, dead domain | No — a fixed row stays fixed |
| Duplicate | Same person imported three times | No |
| Role account (optional) |
info@ is not a person |
No |
Only the first row is a moving target, and it is the one that dominates the file. The published decay numbers are blunt:
- 23% of business contacts change jobs every year (ZoomInfo, 2025)
- 40% of email addresses are dead within two years (NeverBounce)
- Freshly sourced data outperforms stored records by 42% (Harvard Business Review, 2024)
None of those figures describe a bad supplier. They describe time passing, which is not something a cleaning job can bill for.
The rows cleaning will never resolve
There is a category of address that survives every pass unchanged: catch-all, or accept-all, domains. These servers accept mail for any local part, so a probe returns the same answer for a real person and for a string you invented. A verifier can run that probe a hundred times and learn nothing new, because the reply describes the server's policy rather than the mailbox.
The correct output for those rows is unknown. The common output is valid, written down because the server accepted the message. That single mislabeling is enough to turn a "98% clean" file into a campaign that lands somewhere between the two published bounce bands — 2-5% when addresses are verified as they are used, 10-35% for stored lists.
Cleaning is a snapshot, sending is continuous
This is the structural part. A cleaned list is a photograph taken on the day the report was generated. Sending happens afterwards, over weeks, from copies of that photograph. You can schedule the next cleaning, and the schedule will never be tighter than the decay rate, because the decay does not care about your sprint boundaries.
The alternative is not "better cleaning". It is removing the file from the middle of the process. If the address is resolved at the moment it is used, there is no interval for it to go stale in:
curl -s -X POST https://tapacapi.com/v1/contacts/search \
-H "Authorization: Bearer ***" \
-H "Content-Type: application/json" \
-d '{"industry":"logistics","job_titles":["head of operations"],"company_size":"51-200","limit":40}'
The response carries the person, the company, the title, the source the address was found in, and the verification state of that mailbox — produced by an SMTP probe inside the same request. Nothing is stored between calls, which is the reason there is no file to clean next quarter.
An existing list is not wasted. Addresses can be checked on their own with POST /v1/contacts/verify, which is the honest version of a cleaning pass: the verdict comes with the time it was taken. And through an agent the whole thing is one tool call — npx -y @tapacapi/mcp, or the hosted endpoint at https://tapacapi.com/mcp, exposing tapac_find_contacts and tapac_status. Without a key the server returns onboarding instead of an error.
What this does not fix
- A catch-all mailbox stays unknowable;
unknownis the accurate answer, not a limitation to work around. - SMTP probing is rate-limited per domain, so high volume needs pacing — the server handles that, not the caller.
- A verified address is not an interested person. Deliverability and interest are separate problems, and this only removes the first one.
Clean the file you already own, once, if it is large. Then stop maintaining it and start resolving addresses when you need them — 100 searches free, then $0.10-0.50 per verified contact, pay-per-use.
TAPAC is an MCP server and REST API that searches B2B contacts by industry, title, size and location and verifies each mailbox over SMTP at the moment of use. Sources for every number above: AGENTS.md.
Top comments (0)