Mailbox existence check

A mailbox existence check is a procedure that determines whether a specific mailbox on a recipient server exists and can accept incoming messages. It is the decisive step in email address validation: the syntax can be correct, the domain can be live, MX records can be in place, yet if the user@ part does not exist, the message will come back as a hard bounce.

Why it matters

Sending to a non-existent address generates a bounce. One bounce is trivial. Hundreds or thousands from a single campaign are not. Mail providers (Gmail, Outlook, Yahoo) track each sender's bounce rate. Once it crosses 2–3%, IP and domain reputation starts to fall, messages route to spam more often, and in severe cases the sender ends up on blocklists.

Checking mailbox existence before sending removes bad addresses at the source. The campaign reaches only live inboxes, bounce rate stays low, and sender reputation is not damaged.

How it works

The core method is an SMTP dialogue with the recipient's mail server. The validator connects and mimics the opening of an email delivery, then closes the connection before any message data is transferred. The sequence:

1. The validator queries DNS for the domain's MX records.
2. It opens a TCP connection on port 25 to the highest-priority mail server.
3. It sends EHLO to identify itself.
4. It sends MAIL FROM with a technical sender address.
5. It sends RCPT TO with the address under test. This is the critical step: the server replies whether it is prepared to accept mail for that mailbox.
6. The DATA command is never sent. The connection closes with QUIT. No message is delivered, but the answer is in hand.

The server's response to RCPT TO determines the outcome. Code 250 means the mailbox exists and the server is ready to accept mail. Code 550 means the mailbox was not found or is blocked. Code 450 is a temporary rejection, typically from greylisting or connection rate limits.

Where this step fits in the validation chain

Full email validation runs through several layers. First comes syntax: correct format, no illegal characters, valid domain part. Then DNS: does the domain exist, and does it have MX records pointing to a mail server. Only after both pass does the SMTP dialogue begin.

The ordering saves resources. An SMTP connection is the slowest and most expensive part of validation. There is no point spending time on it if the address has a syntax error or the domain does not exist. Syntax filters out gross mistakes in microseconds, DNS in milliseconds. SMTP handles only the addresses that cleared the first two checks.

Limitations

SMTP mailbox checking does not deliver a guarantee. Several situations produce ambiguous results:

• Catch-all domains. The server accepts mail for any address in the domain, including ones that do not exist. It returns 250 for every RCPT TO query. The validator sees a positive response, but the actual mailbox may be missing. Mail gets accepted by the server; the user never reads it.
• Greylisting. An anti-spam technique where the server rejects the first connection from an unfamiliar IP with a 450 code and waits for a retry a few minutes later. A legitimate mail server retries; a spam bot does not. For a validator, this is a problem: one request is not enough, and a delayed retry is needed.
• Rate limiting. Large mail providers cap SMTP connections from a single IP per unit of time. During bulk verification, some requests get rejected not because the mailbox is missing but because the connection limit was hit.
• Deferred mailbox check. Some servers accept RCPT TO unconditionally and verify the mailbox later, at the DATA stage. Because the validator never reaches DATA, it receives a false confirmation.
• IP blocklisting. If the validator's IP is on a blocklist or has triggered an anti-spam filter, the server rejects all requests regardless of whether the mailboxes exist.

Additional signals for better accuracy

Because of these limitations, professional validation services do not rely on the SMTP response alone. They collect and analyze supplementary data:

• Domain age. A domain registered yesterday is more likely to host throwaway addresses than one with a decade of history.
• Disposable email services. Providers like Guerrilla Mail or Mailinator create temporary mailboxes that live for a few hours. The SMTP check shows the address as valid, but it is useless for a campaign: by tomorrow, it is gone.
• Role-based addresses. Mailboxes like info@, support@, or admin@ belong to a function, not a person. They exist and accept mail, but campaigns sent to role addresses draw more spam complaints.
• Historical data. If an address returned a hard bounce on a previous check, the probability it will work now is low. A service may store aggregate statistics on domains and patterns.

Accuracy

For ordinary domains without catch-all configuration or greylisting, SMTP mailbox checks reach 95–98% accuracy. The remaining 2–5% split between false positives (server returned 250 but the mailbox does not work) and false negatives (server rejected for a side reason even though the mailbox exists).

For catch-all domains, accuracy drops: every address gets a status of “unknown.” For domains with greylisting, a retry after 5–10 minutes brings accuracy back to the normal range. That is why serious validators do not stop at one attempt; they return to addresses with ambiguous results.

Batch and real-time checking

Mailbox existence checks run in two modes. Batch: upload a list, process the whole file, receive results. This works for cleaning a list before a campaign. Real-time: check one address through an API the moment a user enters it on a website. This blocks invalid addresses at the entry point.

Batch checking clears out accumulated problems: dead addresses, stale contacts, typos. Real-time checking stops those problems from forming. The two approaches work together: clean the existing list, then control quality for every new address going in.

Practical results

A typical email list loses 20–30% of valid addresses per year. People change jobs, close mailboxes, move to other services. An address that worked six months ago may return a bounce today. Running mailbox existence checks is not a one-time operation; it is a routine part of list hygiene.

After a cleanup through mailbox existence verification, bounce rates typically drop to 0.5–1%. That is well below the 2–3% threshold where providers start cutting sender reputation. The effect shows immediately: more messages land in inboxes, fewer go to spam, open rates rise.