Check on entry, or check before the send?
Both policies check the mailbox over SMTP. They differ in the moment they do it, and that moment decides what the answer is worth. The same address can be deliverable in January, dead in April, and nobody will notice until the bounces land - because 23% of contacts change jobs every year (ZoomInfo, 2025) and 40% of addresses are dead within two years (NeverBounce).
What each policy actually proves
| Policy | What the check proves | What it misses |
|---|---|---|
| Check on entry (when the list is built) | The mailbox accepted a handshake on that date - the list contains no addresses that were already dead when it was assembled | Everything that happened since. The list ages on a known schedule, and the send pays for it |
| Check at send time | The state of the mailbox at the moment the message goes out, which is the only moment a bounce can happen | Nothing about reachability - but it says nothing about whether the address belongs to the person you are addressing |
Neither is a superset of the other. A list checked on entry with no re-check is a snapshot with a date on it; a send-time check with no source field is an address nobody can audit.
Where check-on-entry fails quietly
The failure is arithmetic. Verified lists bounce 2-5% and static resold databases bounce 10-35% (TAPAC) - both numbers are measured at the send, not at the purchase. A list that was clean on the day it was assembled does not stay clean while it sits: on a 5,000-contact list that ages a quarter, the difference between those two regimes is several hundred sends spent on mailboxes that no longer exist. Those sends are paid for at the same price as the ones that land.
Where check-at-send fails quietly
Checking at the moment of use proves the mailbox exists - not that the person is the right one. It also fails on its own if the answer is not recorded: a send-time check whose result is discarded leaves no way to explain later why 240 of 5,000 addresses were dropped, or to prove that they were dropped rather than skipped. Fresh data outperforms stored databases by 42% (Harvard Business Review, 2024) precisely because it is measured at the point of use - but "fresh" without a log is only a feeling.
The policy that survives both
- Check where the address is found. Finds and checks happen in the same request, so nothing dead enters the list in the first place - no second verifier invoice, no reconciliation between two exports.
- Re-check against the send, not against the file. The check that matters is the one that ran closest to the message. Treat any stored state as evidence of what was true then, never as a property of the address.
- Write the answer down with its source. Address, state, timestamp, and the page or profile it was found on. That is the difference between a list that can be audited by someone else and a CSV that only makes sense to its author.
- Keep
unknownin its own column. A catch-all domain accepts every address without confirming one, so it is a decision rather than a yes. Folding it into the usable count is how an auditable list turns back into a 10-35% bounce list.
How TAPAC implements it
One request finds the address and checks it over SMTP in the same call, and returns the source page or profile next to the state as of that moment - so the entry-side check and the audit trail are the same artifact. Catch-all domains come back as unknown and are never promoted into the usable count.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status # or hosted: https://tapacapi.com/mcp # or REST: POST https://tapacapi.com/v1/contacts/search
100 free searches to start, then $0.10-0.50 per verified contact, pay-per-use. See also what a verification log has to record and why a result is a snapshot, not a property.
← Back to TAPAC