SMTP protocol explained (for people who do not write code)

SMTP stands for Simple Mail Transfer Protocol. It is the language that mail servers speak to each other across the internet. You do not need to write SMTP yourself, but understanding what it does makes a lot of deliverability decisions much clearer. Here is the plain-English version.

The conversation

Every email delivery is a conversation between two servers. Your sending server calls the receiving server and they talk through a fixed sequence:

1. Sender: Hi, I am mail.yourdomain.com. (HELO)
2. Receiver: Hi, glad to see you. (250 OK)
3. Sender: I have a message from you@yourdomain.com. (MAIL FROM)
4. Receiver: OK. (250 OK)
5. Sender: It goes to them@theirdomain.com. (RCPT TO)
6. Receiver: OK, that mailbox exists. (250 OK) or No, that mailbox does not exist. (550)
7. Sender: Here is the message. (DATA)
8. Receiver: Got it, queued for delivery. (250 OK)
9. Sender: Bye. (QUIT)

That is it. Six messages, three minutes of work, billions of times a day.

What email verification actually does

A verifier runs the same conversation through step 6, then stops:

1. Verifier: Hi, I am verifier.example.com.
2. Receiver: Hi. (250)
3. Verifier: I have a message from checker@verifier.example.com.
4. Receiver: OK.
5. Verifier: It goes to jane@acme.com.
6. Receiver: OK, that mailbox exists. (250) OR No, that mailbox does not exist. (550)
7. Verifier: Bye, never mind the actual message.

The verifier never sends the DATA step. No message goes through. The recipient never sees anything. The whole thing takes about a second and tells you whether the mailbox exists.

Why responses can be ambiguous

Three response patterns are common:

• 250 OK on RCPT TO: the mailbox exists. Or the domain is catch-all and accepts all addresses. The verifier needs to detect catch-all separately.
• 550 No such user: the mailbox does not exist. Clean fail.
• 451 / 421 / Greylisting: receiver is busy or asking you to retry later. Not a yes, not a no.

Quality verifiers handle each case correctly: catch-all detection runs a guaranteed-fake address first, greylist handling retries after a delay.

SMTP authentication and TLS

When you use Gmail or your company's SMTP server to send email, you authenticate (username + password or OAuth) and the connection is encrypted with TLS. Server-to-server SMTP traffic is also typically encrypted, though not always. The verification conversation above runs the same way over a TLS connection.

Why this matters for senders

• Bounce codes tell you what happened. 5xx codes (550, 552, 554) are permanent failures. 4xx codes (421, 451) are temporary. Knowing the difference shapes your retry logic.
• Catch-all is a domain decision, not a mailbox one. An admin enabled it; the protocol respects it; verifiers expose it as a separate signal.
• Real-time verification reuses the same protocol that delivery uses. If your verifier says invalid, the actual send would also bounce.

FAQ

Is SMTP still the standard in 2026?

Yes. There are extensions (SMTP over TLS, SMTPS, ESMTP) and newer protocols for specific cases (JMAP for IMAP replacement), but the core SMTP conversation has not changed in 40 years.

Do email APIs like Postmark use SMTP under the hood?

Internally, yes. They expose an HTTP API for developer convenience but they still speak SMTP to the receiving mail servers.

Verification uses the same protocol senders use

MailoClean's verifier runs real SMTP conversations against the actual mail servers. The signals are the same ones your future deliveries will see.