What Is SMTP?

Every email ever sent traveled over SMTP at some point. We open billions of SMTP conversations to verify addresses, and the protocol is far simpler than its reputation suggests: it is a short, readable exchange between two servers. Understanding that exchange explains not just how mail moves, but how you can confirm an address is real without ever sending a message.

What SMTP is and what it is for

SMTP, the Simple Mail Transfer Protocol, is the internet standard for sendingemail. It is the language mail servers speak to hand a message from one place to the next. When you press send, your mail client connects to an outgoing mail server and speaks SMTP to it; that server then speaks SMTP to the recipient’s server, relaying the message across the internet until it lands at the destination provider. SMTP governs that entire outbound journey.

The key thing to hold onto is direction. SMTP only ever pushes mail outward, from sender toward recipient. It does not fetch mail out of a mailbox so you can read it; that job belongs to other protocols, covered below. SMTP is the send path, full stop.

How the SMTP handshake works

An SMTP session is a short, ordered conversation. The sending server opens a TCP connection to the receiving server and then they trade a handful of plain-text commands, each answered with a three-digit status code. The sequence runs like this:

• Connect. The sender opens a TCP connection to the receiving server and the server answers with a 220 greeting, signalling it is ready.
• HELO / EHLO. The sender introduces itself by name. EHLO is the modern Extended SMTP greeting that also asks the server which features it supports, such as encryption and authentication; HELO is the older, plainer form.
• MAIL FROM. The sender declares the envelope sender, the address that should receive any bounce.
• RCPT TO.The sender names a recipient. The server’s reply here is the moment of truth: a 250 OK means it will accept mail for that mailbox, while a 550 means the address is rejected.
• DATA. Only now does the sender transmit the actual message, headers and body, ending with a single dot on its own line. The server replies 250 once it has taken responsibility for the message.
• QUIT. The sender closes the session cleanly.

That is the whole protocol in spirit. You can watch a real handshake play out against any domain, command by command, with the SMTP test tool.

Common SMTP ports: 25, 587, and 465

SMTP runs over a few well-known ports, and which one to use depends on who is talking. Port 25 is the original, and it is still how one mail server relays to another across the internet. Because spammers abused it from end-user machines, it is now widely blocked for ordinary clients, so in practice port 25 is reserved for server-to-server relay.

For a mail client or application submitting outbound mail, the modern standard is port 587, which upgrades to an encrypted channel via STARTTLS and requires authentication. Port 465 does the same job with implicit TLS, meaning the connection is encrypted from the very first byte. If you are configuring an app to send through an SMTP server, you almost always want 587 or 465, never 25.

SMTP vs IMAP and POP

SMTP is constantly confused with IMAP and POP, but the split is clean once you anchor on direction. SMTP sends; IMAP and POP3 receive. When your client pulls messages down so you can read them, it is speaking IMAP or POP3 to your mailbox, not SMTP.

The two receive protocols differ too. IMAP keeps your mail on the server and syncs it across every device, so an email read on your phone shows as read on your laptop. POP3 is the older model that typically downloads messages to one device and removes them from the server. A working email account therefore uses two protocols at once: SMTP for the outbound send path, and IMAP or POP for the inbound read path. They are partners, not competitors.

How email verification uses an SMTP handshake

Here is where SMTP becomes a verification tool rather than just a delivery mechanism. Notice that in the handshake above, the server tells you whether a mailbox exists at the RCPT TO step, which comes before the DATA step where the message is actually transmitted. That gap is the entire trick.

To verify an address, email verification runs the front half of the conversation and then stops. The engine looks up the domain’s MX records to find its mail server, connects, greets with EHLO, issues MAIL FROM, and then issues RCPT TO for the address in question. It reads the reply, learns whether the mailbox is real, and quits. It never sends DATA, so no message is ever delivered. The recipient sees nothing, yet you walk away knowing whether the address exists. That is how you confirm a mailbox without sending it mail.

One wrinkle keeps this from being trivial. Some domains are configured to accept mail for every address, real or not, and they answer 250 OK at RCPT TO even for an address that does not exist. A naive verifier marks those as valid and is wrong. Our engine detects catch-all behaviour during the SMTP stage and then runs an AI-confidence pass to return a real, scored verdict rather than a false positive, the same engine that powers the free email checker.

Used well, an SMTP handshake lets you clean a list before you ever press send, so the addresses that would have triggered a hard bounce are caught in advance and your sender reputation stays intact. For teams verifying at scale, the volume tiers are on the pricing page.