SMTPSimple Mail Transfer Protocol
SMTP (Simple Mail Transfer Protocol) is the standard that moves email between servers across the internet. Defined in RFC 5321, it is a text-based conversation of commands like MAIL FROM, RCPT TO, and DATA, each answered with a numeric reply code. Server-to-server relay runs on port 25, while mail clients submit on port 587 or 465.
- The protocol every server uses to hand email to the next server
- A scripted exchange of commands, each met with a numeric reply code
-
Port
25relays between servers;587and465are for authenticated submission -
The SMTP envelope is separate from the visible
From:header
25
587 (STARTTLS) · 465 (implicit TLS)
HELO/EHLO, MAIL FROM, RCPT TO, DATA
2xx ok · 4xx temporary · 5xx permanent
How an SMTP conversation runs
SMTP is a back-and-forth dialogue. The sending server connects, greets the receiver with EHLO (announcing its hostname), then names the sender with MAIL FROM, the recipient with RCPT TO, and finally sends the message itself after DATA. The receiver replies to each step with a three-digit code: 2xx means accepted, 4xx means a temporary failure (a soft bounce), and 5xx means a permanent one (a hard bounce).
S: 220 mail.example.com ESMTP ready
C: EHLO sender.example.net
S: 250-mail.example.com
S: 250 STARTTLS
C: MAIL FROM:<alice@sender.example.net>
S: 250 2.1.0 Ok
C: RCPT TO:<bob@example.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Hello
C: .
S: 250 2.0.0 Ok: queued
The ports: 25 for relay, 587 and 465 for submission
Not every SMTP port does the same job, and using the wrong one is a frequent source of trouble:
25: server-to-server relay, the port one mail server uses to deliver to another. It is unauthenticated and widely blocked on consumer connections to curb spam, so it is not for mail clients.587: the standard submission port (RFC 6409) for a mail client or app to hand mail to its provider. It requires authentication and upgrades to encryption with STARTTLS.465: submission with implicit TLS (RFC 8314), encrypted from the very first byte. Now recommended alongside 587 for client submission.
The rule of thumb: applications and devices submit on 587 or 465 with a username and password; servers relay to each other on 25.
The envelope vs the header
SMTP draws a line that confuses many senders: the envelope versus the message headers. The envelope is the MAIL FROM and RCPT TO exchanged in the SMTP conversation; it controls where the message actually goes and where bounces return, and it is what SPF checks. The headers (From:, To:, Subject:) travel inside the DATA block and are what the recipient sees.
The two can differ, and legitimately do: a newsletter might carry an envelope Return-Path at your ESP’s domain while the visible From: is your brand. That gap is precisely why DMARC exists, to require that the authenticated domain aligns with the From: the reader actually sees. Understanding the split is the key to reading an email header.
SMTP and deliverability
Every deliverability signal flows through an SMTP transaction. The receiver runs reverse DNS on your connecting IP, checks the hostname you gave in EHLO (which should be a fully qualified domain name that resolves), validates SPF against your envelope sender, and replies with the code that becomes your bounce. A clean SMTP setup, correct EHLO, encryption on, matching reverse DNS, is the table stakes that lets your authentication and content be judged fairly.
Since February 2024, Google and Yahoo also require senders to use a TLS connection when transmitting mail, so plain unencrypted SMTP to their servers is no longer acceptable for bulk sending. Getting the basics right at the protocol layer prevents a whole class of avoidable rejections.
An SMTP delivery, step by step
25EHLO and upgrades to TLSMAIL FROM) and recipient (RCPT TO)DATA; the receiver replies with a code2xx reply the message is queued for the inboxSMTP ports at a glance
| Port 25 | Port 587 | Port 465 | |
|---|---|---|---|
| Purpose | Server-to-server relay | Client submission | Client submission |
| Encryption | Opportunistic | STARTTLS | Implicit TLS |
| Authentication | None | Required | Required |
| Defined in | RFC 5321 | RFC 6409 | RFC 8314 |
By the numbers
2xx accept, 4xx retry, 5xx reject.Common mistakes
EHLO name that does not resolveEHLO is a common reason mail is downgraded or rejected.From: headerMAIL FROM, not the visible From: the reader sees. Treating them as one thing is why mail can pass SPF yet still fail DMARC alignment.Frequently asked questions
MAIL FROM, RCPT TO, DATA) and reply codes that move a message from the sender’s server, through any relays, to the receiving mail server. It handles sending; protocols like IMAP and POP handle retrieval.MAIL FROM and RCPT TO exchanged during the SMTP conversation. It controls actual routing and bounce handling and is what SPF checks. It is separate from the visible From: and To: headers inside the message, which is why an email can pass SPF on the envelope yet fail DMARC alignment on the header.2xx means success, 4xx is a temporary failure that triggers a retry (a soft bounce), and 5xx is a permanent failure (a hard bounce). The codes are how senders learn whether mail was accepted, deferred, or rejected.