An email verification API is a service you call in real time, the moment a user types an address into your signup form or before you send a bulk campaign, to decide whether that address is worth sending to. Under the hood it runs a chain of checks: syntax parsing, DNS/MX lookups, disposable and role-account detection, and a live SMTP conversation with the receiving mail server. Get this right and your bounce rates fall, your sender reputation holds, and your messages keep landing in the inbox. This guide explains exactly how each check works, why it matters for deliverability, how to integrate one cleanly, and where MailBounce fits in honestly.
What an email verification API actually does
An email verification API takes a single address (or a batch) and returns a structured verdict about whether mail sent to it is likely to be delivered. It is not a guarantee that a human reads the inbox, and any vendor that promises 100% accuracy is overselling. What a good API gives you is a defensible probability built from layered signals, each of which rules out a class of bad addresses.
The checks run roughly in order of cost. Cheap, deterministic checks come first (syntax, DNS) so that obviously invalid input is rejected before you spend effort on the expensive network steps. The most expensive and most informative step, the live SMTP probe, runs last and only when it can add value.
The typical signal set, from cheapest to most expensive, is: syntax and normalization; domain and MX record resolution; disposable-domain detection; role-account detection (info@, support@, sales@); free-provider flagging (gmail.com, outlook.com); typo / did-you-mean correction; and finally a live SMTP mailbox check that asks the receiving server whether the specific mailbox exists.
Step 1: Syntax and normalization
Before any network call, the address is parsed against the relevant standards (RFC 5321/5322). This catches the obvious failures: missing @, illegal characters, a local part that is too long, or a malformed domain. Naive regex validation famously rejects valid addresses and accepts invalid ones, so a proper parser is worth more than a clever one-liner.
Normalization happens here too. Leading and trailing whitespace is stripped, the domain is lowercased, and some providers apply provider-specific rules (for example, Gmail ignores dots in the local part). Returning the normalized form lets you store a canonical address and deduplicate your list, which matters more than people expect when the same human signs up three slightly different ways.
Step 2: Domain and MX records (does mail even have a destination?)
A syntactically valid address is useless if its domain cannot receive mail. The verification API resolves the domain's MX (mail exchanger) records via DNS to find the servers responsible for accepting its email. No MX records (and no fallback A record acting as an implicit mail host) means there is nowhere to deliver, so the address is invalid regardless of how well-formed it looks.
MailBounce performs these lookups over DNS-over-HTTPS (DoH). Running DNS over HTTPS from an edge environment gives consistent, encrypted resolution that is not at the mercy of a single recursive resolver's cache, which keeps MX results fast and reliable across regions.
This step is also where typo correction earns its keep. If the domain is gmial.com or yhaoo.com, a did-you-mean suggestion (gmail.com, yahoo.com) lets your signup form prompt the user to fix a fat-fingered address instead of silently losing them, the single highest-ROI moment in the whole verification flow.
Step 3: Disposable, role, and free-provider classification
Not every deliverable address is a good address. A disposable or throwaway domain (the kind handed out by temporary-inbox services) will accept your confirmation email and then evaporate, so flagging it lets you block fake signups or require a real address. This is maintained as a continuously updated domain list, since new disposable providers appear constantly.
Role accounts (info@, admin@, support@, sales@, no-reply@) are addresses that route to a function rather than a person. They are technically valid and often deliverable, but they correlate with spam complaints and low engagement, and many mailbox providers weigh complaints from role accounts heavily. You usually want to flag them rather than hard-reject, and let your own policy decide.
Free-provider flagging (gmail.com, outlook.com, proton.me) is informational. A free address is perfectly valid, but for B2B products knowing that a lead used a personal address rather than a corporate one is useful context for routing and scoring. The API's job is to surface the flag; the business decision stays with you.
Step 4: The live SMTP mailbox check (RCPT TO)
This is the step that separates a real email verification API from a glorified regex. The verifier opens an SMTP connection to the domain's highest-priority MX host and begins the delivery handshake — HELO/EHLO, then MAIL FROM, then RCPT TO with the target address — but stops before issuing DATA. It never sends an actual message. The receiving server's response to RCPT TO reveals whether that specific mailbox exists: a 250 typically means accepted, while a 550 means no such user.
Reality is messier than the happy path, which is why this is hard to do well. Many domains are configured as catch-all (accept-all): they return 250 for every address whether or not the mailbox exists, so the honest verdict is 'catch-all / accept-all', not 'valid'. Some servers greylist new senders with a temporary 4xx, some rate-limit or block probes outright, and some large providers deliberately make mailbox probing unreliable. When the server's behavior doesn't permit a confident answer, the correct result is 'unknown' rather than a fabricated verdict.
MailBounce runs its live SMTP prober on a dedicated VPS (the SMTP handshake needs a stable, reputable IP and outbound port 25, which serverless edge runtimes don't provide), while the rest of the pipeline — syntax, DNS-over-HTTPS MX lookups, classification — runs on Cloudflare Workers. That split keeps the fast checks at the edge and isolates the slow, network-bound probe where it belongs.
Why this matters for deliverability and sender reputation
Mailbox providers like Gmail and Microsoft judge you by your sending behavior. A high bounce rate is one of the loudest negative signals you can send: it tells them you are mailing addresses you have no relationship with, which is exactly what a spammer does. Repeatedly hitting invalid addresses drags down your sender reputation, and once that drops your legitimate mail starts landing in spam for everyone, not just the bad addresses.
Worse, recycled invalid addresses sometimes become spam traps — addresses providers use specifically to catch senders with poor list hygiene. Hitting a trap can get you blocklisted. Verifying before you send removes the addresses most likely to bounce or trip a trap, which is why list verification is now a baseline part of email hygiene rather than an optional extra.
The cheapest place to verify is at the point of capture. Validating an address in your signup form in real time stops the bad data from ever entering your database. Periodic re-verification of your existing list handles the addresses that decay over time as people change jobs and abandon inboxes.
How to integrate an email verification API
Integration falls into two patterns, and most teams eventually use both. The real-time pattern calls the single-address endpoint synchronously when a user submits an address — typically on form blur or submit. Keep the user experience graceful: show the did-you-mean suggestion inline, soft-block disposable addresses, and crucially, do not hard-block on an 'unknown' verdict, because that punishes real users behind a cautious mail server. Treat verification as a signal that informs your policy, not an absolute gate.
The bulk pattern handles existing lists. You upload a file and the service processes it asynchronously, because verifying tens of thousands of addresses with live SMTP probes takes time and cannot block an HTTP request. MailBounce accepts CSV, TXT, or ZIP uploads and processes them in the background using Cloudflare Queues, then returns categorized results — valid, invalid, catch-all, unknown, disposable — that you can download as a CSV. Design your code to poll for completion or receive a callback rather than waiting on the request.
A clean integration follows a few rules: call the API server-side so your key is never exposed in the browser; cache verdicts in your own store so you can reuse a recent result instead of spending a credit to validate the same address again; handle the full set of result states (not just valid/invalid) so 'catch-all' and 'unknown' get sensible business logic; and fail open on timeouts so a verification outage never blocks a real signup. MailBounce returns plain, predictable JSON for exactly this reason, and you can try every check in the free playground before writing a line of integration code. For pricing on production volume, see the pricing page.
Where MailBounce fits — honestly
MailBounce is a developer-friendly email verification API that runs the full check chain described above: syntax, MX over DNS-over-HTTPS, disposable and role-account detection, free-provider flagging, typo/did-you-mean correction, and live SMTP mailbox verification, plus background bulk list validation with categorized CSV export. The stack is modern (Cloudflare Workers at the edge, a dedicated VPS SMTP prober), the JSON is clean, and there is a free playground that uses no credits so you can evaluate accuracy on your own addresses before committing.
The billing model is built to be fair rather than maximal: you are only charged a credit for a definitive verdict each time you validate an address. 'Unknown' results are always free, so you never pay for an answer the network refused to give, and every account gets 100 free credits every month, refreshed automatically. The free playground uses no credits at all. That is the opposite of pricing models that bill every lookup regardless of outcome.
Being honest about limitations matters for trust, so here they are. MailBounce is newer and smaller than long-established incumbents. It currently runs a single prober IP, which means very large lists process more slowly and there is no IP-pool rotation yet. And it does not have the proprietary spam-trap and historical-bounce datasets that the biggest legacy providers have accumulated over a decade — those datasets are genuinely valuable for catching risky-but-deliverable addresses. If you need petabyte-scale historical bounce intelligence today, weigh that. If you want a transparent, modern, fairly-billed API that is free to try and pleasant to integrate, MailBounce is a strong fit. See how it stacks up in our ZeroBounce alternatives comparison.
Frequently asked questions
How accurate is an email verification API?
For most addresses, a well-built API is highly accurate because syntax, MX, and disposable checks are deterministic. The uncertainty lives in the live SMTP step: catch-all domains accept everything, and some providers block or throttle probes. Honest APIs return 'catch-all' or 'unknown' in those cases instead of guessing, so accuracy is high on definitive verdicts and explicitly uncertain elsewhere. Treat anyone promising 100% accuracy with suspicion.
Does email verification actually send an email?
No. The live SMTP check opens a connection and goes through the delivery handshake up to the RCPT TO command, which is where the server reveals whether the mailbox exists, then disconnects before sending any message body (the DATA stage). The recipient never receives anything, so verification is silent and does not affect your send volume.
What is a catch-all (accept-all) result and how should I handle it?
A catch-all domain is configured to accept mail for every possible address, so the server returns success even for mailboxes that don't exist. The verifier can't confirm the specific inbox, so it labels the address 'catch-all'. Don't treat it as invalid; mail often delivers fine. Treat it as a lower-confidence 'probably valid' and weigh it against engagement data over time.
Should I verify emails in real time at signup or in bulk?
Both. Real-time verification at the point of capture stops bad data from entering your database and is the highest-ROI moment, especially with did-you-mean typo correction. Bulk verification cleans your existing list and catches addresses that have decayed since signup. MailBounce supports both: a real-time single-address API and background bulk processing of CSV, TXT, or ZIP files.
Will I get charged for 'unknown' results?
With MailBounce, no. Only definitive verdicts cost a credit, and they cost one credit each time you validate an address; 'unknown' results are always free. This avoids the common frustration of paying for lookups where the receiving server refused to give a usable answer. Every account also gets 100 free credits each month, and the free playground uses no credits at all.