SMTP email verification, and what it does not promise
An SMTP verification is a conversation with the receiving mail server: the client introduces itself, states a sender, asks about a specific recipient with RCPT TO, and reads the answer. That is all it is. Everything the category claims rests on how you interpret the reply — and on when you run it.
The four answers you actually get
| Server reply | Meaning | What to do |
|---|---|---|
250 on RCPT TO | The mailbox is accepted by the server right now | Safe to send |
550 / 551 | The mailbox does not exist (or is refused) | Drop it — this is a hard bounce waiting to happen |
450 / 451 | Temporary failure: greylisting, rate limit, server busy | Retry later; do not treat as invalid |
| Catch-all domain | The server accepts anything, so the reply proves nothing about the individual mailbox | Treat as unverified and rank accordingly |
Any tool that reports a binary "valid / invalid" without telling you which of these four cases it hit is hiding the part that matters.
Why the timing matters more than the method
- 40% of email addresses go dead within two years (NeverBounce).
- 23% of business contacts change jobs each year (ZoomInfo, 2025) — and the mailbox usually follows the person.
- Stored lists verified at import time typically bounce 10–35%; addresses checked over SMTP at the moment of use bounce 2–5%.
- Freshly sourced data outperforms stale stored records by 42% (Harvard Business Review, 2024).
A verification result is a timestamp, not a property. The only way to keep it true is to run it close to the send — which is why TAPAC folds the handshake into POST /v1/contacts/search rather than selling a separate verification pass.
The limits, stated plainly
- SMTP verification proves the mailbox exists now. It cannot prove the person will reply — outreach quality is a different problem.
- Catch-all and greylisting servers refuse to give a clean answer; no method fixes that, it can only be labelled.
- Some providers rate-limit verification traffic, so a check may return "unknown" rather than "invalid". An "unknown" is not a "send anyway".
Run it
curl -X POST https://tapacapi.com/v1/contacts/verify \\
-H "Authorization: Bearer ***" \\
-H "Content-Type: application/json" \\
-d '{"emails":["alex@example.com","sam@example.com"]}'
Or let the search do it for you — every contact returned by POST /v1/contacts/search already carries its verification status. Agents can call the same thing through MCP: npx -y @tapacapi/mcp. Pricing is one number: 100 free searches, then $0.10–0.50 per verified contact.
Where to go next
- Install the TAPAC MCP server — npx, uvx or hosted endpoint, with the JSON block for Claude, Cursor, Codex and Windsurf.
- TAPAC as an MCP server for Claude · lead generation MCP server · REST API quickstart
- Email verification API · Verify email before sending · Get a free API key
- Compare TAPAC with Apollo, ZoomInfo, Hunter and Lusha · contact database alternative