ZeroBounce

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the list verification I actually need instead of ZeroBounce — and know which check you cannot do yourself.

**Spam traps.** An address that exists only to catch senders who did not get permission, hitting one is what puts a domain on a blocklist, and the lists of them are private by necessity. No amount of code finds them. That is the honest gap.

Everything else is a DNS lookup and a careful conversation.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3 for results and cache
- **A machine that is not your sending server**, on an address that is not your sending address
- Caddy in front, on a private network

WHY THE SEPARATE MACHINE MATTERS
- Verification means connecting to a lot of mail servers and asking about a lot of addresses. That pattern is indistinguishable from a directory-harvest attack, which is what it technically is
- Do it from your sending address and you can find that address blocked by exactly the providers you need to reach. Do it from a machine you do not care about

THE CHECKS, IN ORDER OF COST
- **Syntax**, properly: the local part rules are stranger than most implementations assume, and a regular expression that rejects a valid address is worse than one that accepts a bad one
- **Domain**: does it resolve, and does it have MX records. A domain with no MX cannot receive mail and that is a definitive answer for free
- **Disposable**: match the domain against a maintained list of throwaway providers. The lists are open and good
- **Role accounts**: info@, sales@, support@ — not invalid, but a different thing, and a marketing list full of them is a complaint rate waiting to happen
- **SMTP**: connect, say hello, declare a sender, ask about the recipient, and **stop before sending anything**. Never send a message to verify one
- **Catch-all**: ask about an address that certainly does not exist. If the server accepts it, it accepts everything, and every verification for that domain means nothing. A large share of company domains are like this, and reporting them as valid is the most common way this category flatters itself

BEING HONEST ABOUT THE RESULT
- Four outcomes, not two: valid, invalid, unknown, and accepts-everything. **Unknown is a real answer** — a greylisting server, a timeout, a provider that refuses to say — and forcing it into valid or invalid is where the harm is
- The large providers deliberately do not answer this question truthfully any more. Say so beside the result rather than pretending the check is definitive
- Cache by address with an expiry. An address verified last year is not verified

BEING POLITE, WHICH IS ALSO SELF-INTEREST
- One connection per domain at a time, spaced out, with a proper hello and a real reverse DNS name
- Honour a temporary failure as temporary and back off
- Never verify an entire list in one burst

AND THE THING THAT MATTERS MORE THAN ANY OF IT
- Verification treats a symptom. A list that needs verifying is usually a list that was bought, scraped or left to rot — and the fix is not verification, it is not acquiring addresses that way
- **Suppress hard bounces immediately, complaints permanently, and anybody who has not opened anything in a very long time.** That hygiene keeps a reputation intact without verifying anything, and it is free

WHAT MATTERS MOST
Catch-all detection and reporting unknown as unknown. Those two are the difference between a verification result you can act on and a number that makes a bad list look clean.