Draft&Check

Guide

How email verification actually works.

Every check that decides whether an address is safe to send to, in plain English, and why the honest answer is sometimes "we do not know."

Sending to a bad list is expensive. Every hard bounce tells the mailbox providers you are not careful, and once your bounce rate creeps up, your good emails start landing in spam. Verification exists to catch the dead addresses before you send, not after. Here is what a real verifier does, step by step.

1. Syntax and normalization

First, is it even a valid address? This is more than checking for an @. It means parsing the local part and domain against what mail servers actually accept, and normalizing the address (trimming, lowercasing the domain) so the same mailbox is not counted twice. Most obviously broken addresses die here.

2. Domain and MX records (DNS)

An address can be perfectly formed and still have nowhere to go. The verifier looks up the domain's MX records, the DNS entries that name the mail servers responsible for that domain. No MX (and no usable A record as a fallback) means no mailbox can exist there, so the address is undeliverable. This step also catches domains that were never registered or have lapsed.

3. Disposable, role, and typo checks

Some addresses are technically deliverable but bad for you:

• Disposable domains (temporary, throwaway inboxes) signal a low-quality signup and rarely convert.
• Role addresses like info@, sales@, or support@ go to a team, not a person, and often should not be cold-emailed.
• Typos like gmial.com get a "did you mean gmail.com?" suggestion so you can recover a real customer instead of losing them.

4. The SMTP mailbox check (the important one)

This is what separates real verification from a spell-check. The verifier opens an SMTP conversation with the domain's mail server, exactly as a sending server would, and asks whether that specific mailbox exists, using the RCPT TO command. Crucially, it never sends an actual email, it just reads the server's response and hangs up.

> MAIL FROM:<[email protected]>
> RCPT TO:<[email protected]>
< 250 2.1.5 OK        # mailbox exists

A 250 means the mailbox is accepted. A 550 means it does not exist. That single exchange is the difference between "the domain can receive mail" and "this person's inbox is really there."

5. Catch-all detection

Some domains accept mail for every address, real or not, and sort it out later. These are called catch-all (or accept-all) domains. If you only did the SMTP check, a catch-all would look deliverable for any address you tried, which is misleading. A good verifier probes with a random address first; if the server accepts that too, it flags the domain catch-all and marks the result risky rather than pretending it is confirmed.

Why "unknown" is the honest answer

Here is the part most services gloss over. Many mail servers deliberately decline verification probes, they greylist, tarpit, or accept everything to stop exactly this kind of check. When that happens, the truth is that the mailbox cannot be confirmed. A service that returns "deliverable" anyway is guessing, and you are the one who eats the bounce.

Draft & Check returns four verdicts, and it is not afraid of the fourth:

Each one also carries a 0 to 100 score so you can set your own threshold, send to everything above 80, hold the rest, whatever fits your risk.

Verifying through the API

One REST call, JSON in and JSON out. Single address in real time, or up to 1,000 in a batch:

$ curl -X POST https://api.draftandcheck.com/verify \
    -H "Authorization: Bearer lv_..." \
    -d '{"email":"[email protected]","smtp":true}'

{
  "status": "deliverable",
  "score": 90,
  "reason": "Mailbox confirmed via SMTP"
}