A contact database has one column for a verdict and, usually, none for the moment the verdict was taken. That missing field is why two rows that look identical are not the same fact.
deliverable is not a property. It is the answer a mail server gave to a question, once, at a time. Everything useful you can do with a verified list depends on knowing when.
What a probe actually is
An SMTP probe is a conversation. The server answers about one mailbox as it exists right now: it accepts mail for this address, it refuses, or it declines to give a verdict - which is the honest outcome for catch-all domains and unanswered probes.
Nothing in that exchange is permanent. The moment the answer is written down, it starts becoming history. So the useful unit is not "verified" but verified at.
Why the good databases have no date to give you
A resold database builds rows by copying a snapshot. Its timestamps, when they exist at all, are the date of the purchase or of the copy - identical across every row, and unrelated to any probe, because no probe produced the data. That is the whole difference between a file that has been checked and a file that has been copied.
Three ages hide inside one column
| Figure | What it describes |
|---|---|
| 23% of contacts change jobs annually (ZoomInfo, 2025) | The person moves; the address you hold may be retired |
| 40% of email addresses are dead within two years (NeverBounce) | Time alone kills almost half a file |
| 42% of B2B data goes stale within a year (Harvard Business Review, 2024) | The people are there; the records about them are not |
A list without per-row probe dates is a blend of all three, and no aggregate number can separate the part that is two hours old from the part that is two years old.
What a date lets you do
- Order your sends. Work the freshest contacts first - a decision you cannot make if freshness is not stored.
- Schedule re-checks. Re-probe what is old, leave alone what is current, instead of redoing the whole file on a calendar.
- Publish an honest accuracy number. "99% accurate" without accurate when, over what sample and how obtained is not a measurement.
- Explain a bounce afterwards. A row with a probe date tells you whether the verdict was stale or the address died inside a week. Without it, every post-mortem is a guess.
How to store a verdict
- Keep the state, the time and the source on the same row. A state without provenance cannot be audited or re-ranked.
- Never overwrite a verdict in place without changing its date - it makes an old answer look current.
- Treat
unknownas a first-class state: catch-all domains and unanswered probes are rows that need a decision at send time, not failures. - Probe at the point of send. The only verdict that cannot be stale is the one taken while the message is going out.
TAPAC probes the mailbox inside the search that found the contact and returns the state, the time of the probe and the source page or profile the address came from - so every row is a dated statement rather than a badge. Checked contacts carry a published 2-5% bounce rate against 10-35% for static, resold databases, on pay-per-use pricing of $0.10-0.50 per contact with 100 free searches.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status
# hosted: https://tapacapi.com/mcp
# REST: POST https://tapacapi.com/v1/contacts/search
Top comments (0)