An email verification SLA is three promises, not one
A verification provider cannot promise you a bounce rate, because the bounce is decided by the mailbox at the moment you send - not by the check that ran weeks earlier. What a provider can promise is narrower and more useful: what is checked, how the answers are labelled, and whether the result can be reproduced later. Those three are what belongs in an agreement.
Promise 1 - the check happens at call time
The result has to describe the mailbox when the request is made, not a row taken from a database assembled last year. That distinction has a known cost: 40% of addresses are dead within two years (NeverBounce) and 23% of contacts change jobs every year (ZoomInfo, 2025). An SLA that promises "verified contacts" without saying verified when is promising the state of a snapshot, which is exactly what enrichment from a stored base delivers.
Promise 2 - the answer is labelled honestly
| State | What the SLA must say it means | What it must not be used for |
|---|---|---|
| deliverable | The mailbox accepted the SMTP handshake at that moment | - |
| undeliverable | The server rejected the address | Nothing - it is a definitive no |
| unknown (catch-all) | The domain accepts every address without confirming one; a decision is required | Being counted as usable. Promoting it is how a 2-5% list turns into a 10-35% one |
The third row is where most agreements quietly fail. Verified lists bounce 2-5% versus 10-35% for static resold databases (TAPAC) - that gap only holds if catch-alls are reported as catch-alls instead of being rounded up into a nicer number.
Promise 3 - the record is reproducible
Every result should carry the full address, the state, the timestamp and the source the address was found on. Hand the record to someone who was not involved and they should be able to rebuild your delivered-list numbers. Without the source field the numbers are an opinion; with it they are evidence. This is the same requirement that makes a verification log worth keeping at all.
What no verification provider can promise
- A fixed bounce percentage on your send. Deliverability depends on your list quality, your sending domain and your copy. What a provider controls is whether a dead address enters the list.
- That a deliverable address will be read. 3.2x higher open rates for personalised mail (HubSpot, 2025) is an argument about the copy, not about the mailbox.
- That a check is valid forever. Mailboxes do not have a permanent state. Re-check against the send rather than trusting a date on a file.
- Coverage of every domain. Catch-all servers refuse to confirm mailboxes by design - which is why the honest answer for them is
unknown, not "verified".
What TAPAC publishes instead of a bounce guarantee
Find and verify in one request, with the state as of that call and the source page or profile attached to every contact; catch-alls returned as unknown and never folded into the usable count; pay-per-use at $0.10-0.50 per verified contact after 100 free searches, with no seat to renew in a month you do not send.
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
Related: checking on entry versus checking at send time, what a verification costs per contact, and what bulk verification does and does not prove.
← Back to TAPAC