DEV Community

Axel Freeman
Axel Freeman

Posted on Originally published at tapacapi.com

Verify on entry or verify at send time? The log decides which one you actually have

#marketing #email #api #productivity

Every verification policy answers the same SMTP question at a different moment. That moment is the whole product decision, because a mailbox does not have a permanent state: 23% of contacts change jobs every year (ZoomInfo, 2025) and 40% of addresses are dead within two years (NeverBounce).

Two policies, neither a superset

Policy What it proves What it misses
Check on entry (when the list is built) The mailbox accepted a handshake on that date Everything since. The list ages on a schedule nobody sees
Check at send time The state at the only moment a bounce is decided Nothing about reachability - and nothing about whether the address belongs to the person you name

A list checked on entry with no re-check is a snapshot with a date on it. A send-time check whose result is discarded is an address nobody can audit.

The failure is arithmetic, not opinion

Verified lists bounce 2-5%. Static, resold databases bounce 10-35%. Both numbers are observed at send time, not at purchase. On a 5,000-contact list that ages a quarter, the gap between those regimes is several hundred sends spent on mailboxes that no longer exist - paid for at the same price as the messages that land.

That is also why "we verified it once" is not a statement about your bounce rate. It is a statement about a Tuesday.

The bit most pipelines get wrong

A send-time check that is not written down is indistinguishable from a send-time check that never ran. Six months later nobody can say whether 240 of 5,000 addresses were dropped for cause or skipped by accident.

What a useful record has, per contact:

  1. the full address and its domain
  2. the state returned - deliverable, undeliverable, or unknown for a catch-all
  3. the timestamp of the check
  4. the source page or profile the address was found on

Field 4 is the one that turns a CSV into evidence. Hand the record to someone who was not involved; if they can rebuild your delivered-list numbers, it is a log. If they need you to explain it, it is a spreadsheet.

Keep unknown in its own column

A catch-all domain accepts every address without confirming whether a particular mailbox exists. It is not a yes. Counting it as usable is the single most common way a 2-5% list silently becomes a 10-35% one - the row looks complete, the number looks better, the bounces arrive anyway.

Four rules that hold under both policies

  1. Check where the address is found. Find and verify in the same request, so nothing dead enters the list - and there is no second verifier invoice or export to reconcile.
  2. Re-check against the send, not against the file. The check closest to the message is the one that describes reality.
  3. Write the answer down with its source. Timestamp plus source, or the number is an opinion.
  4. Never promote a catch-all. Give unknown its own column and its own send policy.

Where TAPAC sits

One request finds the address and checks it over SMTP in the same call, and returns the state as of that moment next to the source page or profile it came from - so the entry-side check and the audit trail are the same artifact rather than two subscriptions. Catch-alls come back as unknown.

npx -y @tapacapi/mcp        # tools: tapac_find_contacts, tapac_status
# hosted:  https://tapacapi.com/mcp
# REST:    POST https://tapacapi.com/v1/contacts/search
Enter fullscreen mode Exit fullscreen mode

100 free searches, then $0.10-0.50 per verified contact, pay-per-use. No seat to renew in a month you do not send.

Published from tapacapi.com — TAPAC is an MCP server and REST API for verified B2B contacts.

Top comments (0)