Finding an address and proving it are two different jobs

An email finder and an email verifier are sold in the same category and they do not answer the same question. One proposes a string. The other asks a mail server whether that string is a mailbox. Almost every bounce rate problem lives in the gap between the two answers.

What each tool actually returns

	Email finder	Email verifier
Input	A name, a domain, a title	An address you already have
Output	A string matching the domain's pattern	valid, invalid or unknown
Can it be wrong invisibly?	Yes — every guess looks like an address	No — a bad row is visible
Billing unit	Per result returned	Per address checked

The finder's failure mode is silent by design. [e-mail] is a plausible string, a valid-looking address and possibly a mailbox that was never issued. Nothing in the response separates it from a real one.

Where the handoff leaks

Run the two steps as separate purchases and the file crosses three gaps:

• Two bills, one outcome. You pay to find the row and again to learn the row is unusable. The finder is never charged for the addresses that turn out to be dead.
• Time between the calls. The decay statistics live in that window: 40% of email addresses are dead within two years (NeverBounce) and 23% of business contacts change jobs annually (ZoomInfo, 2025).
• The unknown rows get sent anyway. A catch-all domain accepts a probe for every address, including invented ones. Tools that read an accepted probe as a pass report valid there — which is how a list gets billed as verified and still bounces at 10-35% instead of the 2-5% range that contacts confirmed at the moment of use show.

unknown is not a defect in your list. It is a property of the domain configuration, and it is the correct answer for a catch-all mailbox. Re-checking does not lower it; it only re-bills it.

The question that separates honest vendors

Ask the finder how it reports an address it could not confirm, and ask the verifier how it reports a catch-all domain. If neither has an "unconfirmed" state, you are buying a file that is described as cleaner than it is.

Doing both in one request

TAPAC returns the contact and the mailbox state from the same call, so there is no handoff to schedule:

curl -s -X POST https://tapacapi.com/v1/contacts/search \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"industry":"saas","job_titles":["vp marketing"],"company_size":"51-200","location":"france","source":"website","limit":25}'

Every row carries the person, the company, the title, the source the address was published in and the SMTP state of the mailbox. Single addresses already in a CRM go through POST /v1/contacts/verify. From an agent it is one tool call — npx -y @tapacapi/mcp, or the hosted endpoint at https://tapacapi.com/mcp, exposing tapac_find_contacts and tapac_status; without a key the server returns onboarding instead of an error.

Pricing is per verified contact — $0.10-0.50, 100 free searches, no seat licence and no separate re-check line — so the denominator is contacts you can send to, not rows you submitted.

What verification still does not fix

• A catch-all domain stays unknown. There is no setting that changes that.
• A verified mailbox can be abandoned tomorrow. Verification covers the send you are about to make.
• If the list was built from pattern guesses against a source that never published the address, verification tells you which guesses were rejected — it does not tell you which accepted ones belong to the person you meant.

Buy the finder for reach and the verifier for the truth about what you are holding. On a per-verified-contact price the second one is not an extra line, it is the unit you are actually buying.