SMTP Verification Explained: Check If an Email Actually Exists

You have confirmed the email address has valid syntax. You have verified the domain has MX records. But does the actual mailbox — the part before the @ sign — exist on that mail server? SMTP verification answers this question by simulating the first steps of an email delivery without actually sending a message.

# How SMTP Verification Works

SMTP (Simple Mail Transfer Protocol) is the standard protocol for sending email between servers. When one server wants to deliver a message to another, they engage in a handshake — a series of commands and responses. SMTP verification exploits this handshake to probe whether a recipient address is accepted by the destination server.

Here is the sequence step by step:

1. DNS lookup — Resolve the MX records for the recipient's domain to find the mail server hostname.
2. TCP connection — Open a connection to the mail server on port 25.
3. EHLO/HELO — Introduce yourself with a greeting command.
4. MAIL FROM — Specify a sender address (this does not need to be a real address for verification purposes, though some servers check).
5. RCPT TO — Specify the recipient address you want to verify. This is the critical step.
6. Interpret the response — If the server responds with a 250 status code, the mailbox exists. A 550 response means the mailbox is not found. Other codes indicate various conditions.
7. QUIT — Close the connection without sending any data.

No email is actually sent. You abort the transaction before the DATA command, which is when message content would be transmitted.

# A Simplified Implementation

Here is a conceptual Node.js implementation showing the SMTP conversation:

import net from "node:net";
import dns from "node:dns/promises";

async function verifyMailbox(email: string): Promise<{
  exists: boolean;
  code: number;
  message: string;
}> {
  const domain = email.split("@")[1];
  const mxRecords = await dns.resolveMx(domain);
  mxRecords.sort((a, b) => a.priority - b.priority);

  const mxHost = mxRecords[0].exchange;

  return new Promise((resolve, reject) => {
    const socket = net.createConnection(25, mxHost);
    let step = 0;

    socket.on("data", (data) => {
      const response = data.toString();
      const code = parseInt(response.substring(0, 3), 10);

      switch (step) {
        case 0: // Server greeting
          socket.write("EHLO verify.example.com\r\n");
          step++;
          break;
        case 1: // EHLO response
          socket.write("MAIL FROM:<verify@example.com>\r\n");
          step++;
          break;
        case 2: // MAIL FROM response
          socket.write(`RCPT TO:<${email}>\r\n`);
          step++;
          break;
        case 3: // RCPT TO response — this is the answer
          socket.write("QUIT\r\n");
          resolve({
            exists: code === 250,
            code,
            message: response.trim(),
          });
          break;
      }
    });

    socket.on("error", reject);
    socket.setTimeout(10000, () => {
      socket.destroy();
      reject(new Error("SMTP connection timed out"));
    });
  });
}

This is a teaching example — production implementations need more robust error handling, connection pooling, and retry logic.

# Limitations of SMTP Verification

SMTP verification is powerful but far from perfect. Several real-world complications reduce its reliability:

# Catch-All Domains

Some domains are configured to accept mail for any address, regardless of whether the mailbox exists. Corporate domains and some hosting providers do this as a spam-filtering strategy — they accept everything at the SMTP level and sort or discard internally. For catch-all domains, RCPT TO always returns 250, making verification inconclusive.

# Greylisting

Greylisting servers temporarily reject the first delivery attempt from an unknown sender with a 4xx code, expecting legitimate senders to retry. A naive SMTP verifier might interpret this as a failure. You need to recognize 4xx responses as "try again later" rather than "mailbox does not exist."

# Rate Limiting and Blocking

Mail servers monitor incoming connections. If your verification service sends too many RCPT TO probes to the same server in a short period, you may be rate-limited, temporarily blocked, or even blacklisted. This is why running SMTP verification at scale requires rotating source IPs and careful throttling.

# Anti-Verification Measures

Some servers (notably Microsoft 365 and certain Yahoo configurations) have hardened their SMTP endpoints to return generic responses regardless of whether a mailbox exists, specifically to prevent this type of probing.

# When to Use SMTP Verification

SMTP verification is most valuable when:

• You need to verify addresses before sending high-stakes transactional email (invoices, legal notices, account recovery).
• You are cleaning a large legacy list and want to prune obviously dead addresses before re-engagement.
• You want to layer it with other signals — syntax, MX, disposable detection, risk scoring — for a comprehensive validation verdict.

Because of the operational complexity (IP management, rate limiting, greylisting handling), most teams are better served using a validation service like MailSentry that manages the SMTP infrastructure and wraps the result in a clean API response, rather than building and maintaining their own verification pipeline.

# Key Takeaways

SMTP verification lets you check whether a specific mailbox exists by simulating an email delivery handshake without actually sending a message. It is the deepest layer of email validation, but it comes with caveats: catch-all domains, greylisting, rate limits, and anti-verification measures all reduce its reliability. Use it as one signal in a multi-layered validation strategy, and lean on specialized infrastructure to handle the operational complexity at scale.