What an email verification log has to record to be worth keeping

A verification result is a statement about a mailbox at a moment in time. That is all it is. The moment it is treated as a permanent property of the address, the list starts drifting away from reality - and 23% of contacts change jobs every year (ZoomInfo, 2025) while 40% of addresses die within two years (NeverBounce).

Three questions a log has to answer

  1. Which mailbox, exactly. The full address and the domain - not a normalised fragment. Two people at the same company on the same domain can have different states.
  2. Checked when, and with what answer. A timestamp and the state returned at that time: deliverable, undeliverable, or unknown for a catch-all domain that accepts everything without confirming anything.
  3. Found where. The source page or profile the address came from. This is the field that turns a CSV into something a human who was not involved can audit.

Rows missing any one of the three are not logs. They are unverifiable claims, and they are what makes a campaign's numbers impossible to explain a quarter later.

The states, and why the third one must not be promoted

StateWhat the server saidWhat it means for a send
deliverableThe mailbox accepted the SMTP handshakeSend - this is a yes from the server
undeliverableThe server rejected the addressNever send - and count it as data you should not have paid for
unknown / catch-allThe domain accepts every address without confirmingA decision, not a yes - keep it in its own column and its own send policy

Promoting unknown into the usable count is the most common way an audit trail becomes fiction: the row looks full, the number looks better, and the bounces arrive anyway. Verified lists bounce 2-5% against 10-35% for static databases (TAPAC) - that gap only survives if catch-alls are honestly labelled.

What a log should not contain

An audit trail needs states and timestamps, not a growing archive of personal mailboxes. Storing fewer fields reduces both the exposure if the file leaks and the number of stale records that will be mistaken for current ones later. Live results are a measurement; a stored copy is a liability that ages on a known schedule.

The useful test of a log is simple: hand it to someone who was not there and ask them to reproduce your delivered-list numbers. If they can, it is a log. If they need you to explain it, it is a spreadsheet.

Where the log comes from with TAPAC

There is no separate verification step to log, because checking happens inside the search: each contact is returned with the address, the source page or profile it was found on, and its SMTP state as of that call. Write that response where you keep records and the audit trail exists without any additional tooling.

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. Related: how long verification data should be kept, piping results into your own system, and what verification costs per contact.

← Back to TAPAC