SMTP — the Simple Mail Transfer Protocol — is how email moves. It is a plain-text conversation in which one machine announces itself, states who the message is from, states who it is for, and then hands over the content. Every delivery failure you will ever debug is one of those steps returning a number instead of an acceptance.
What SMTP Is Responsible For
SMTP is a push protocol: it only moves messages outward. It has no concept of an inbox, no way to list messages, and no way to fetch one. That work belongs to IMAP or POP3, which are separate protocols on separate ports. A mail client speaks both — SMTP to send, IMAP to read — which is why outgoing mail can fail while incoming mail keeps working perfectly.
The path a message takes has three distinct legs, and they behave differently:
- Submission. Your client hands the message to your own provider, on port 587 or 465, authenticated. This is the only leg where your password is involved.
- Transport. Your provider looks up the recipient domain's MX records and delivers to the receiving server on port 25, anonymously. There is no account to authenticate with.
- Delivery. The receiving server files the message into a mailbox. From here the recipient uses IMAP or POP3, and SMTP is out of the picture.
The Conversation
An SMTP session is line-based and readable. The client sends commands; the server answers each one with a three-digit code and some text. Here is a complete submission, with the server's replies prefixed:
S: 220 smtp.example.com ESMTP ready
C: EHLO client.example.org
S: 250-smtp.example.com
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250-SIZE 35882577
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS
... TLS handshake, everything below is encrypted ...
C: EHLO client.example.org
S: 250-smtp.example.com
S: 250 AUTH PLAIN LOGIN
C: AUTH PLAIN AGFsaWNlAHMzY3JldA==
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<alice@example.org>
S: 250 2.1.0 Sender OK
C: RCPT TO:<bob@example.net>
S: 250 2.1.5 Recipient OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Alice <alice@example.org>
C: To: Bob <bob@example.net>
C: Subject: Hello
C:
C: The message body goes here.
C: .
S: 250 2.0.0 Ok: queued as 4B2C1D
C: QUIT
S: 221 2.0.0 ByeEach command does one thing, and each is a separate place to fail:
| Command | Purpose | Typical failure |
|---|---|---|
EHLO | Announce the client and ask what the server supports | No reply at all — a blocked port, not a mail problem |
STARTTLS | Upgrade the plain connection to TLS | Handshake failure from a bad certificate or protocol mismatch |
AUTH | Prove you may submit mail through this server | 535 5.7.8 — wrong credentials or wrong auth method |
MAIL FROM | Declare the envelope sender (where bounces go) | 550 when the sender domain fails a policy check |
RCPT TO | Declare one recipient; repeat per recipient | 550 5.1.1 unknown user, or 5.7.1 relay denied |
DATA | Send headers and body, terminated by a lone dot | 552 size limit, or a content/spam rejection |
The reply codes follow a fixed shape: 2xx succeeded, 3xx means keep going, 4xx is a temporary failure worth retrying, and 5xx is permanent. SMTP reply codes covers the vocabulary in full — the difference between 4xx and 5xx is the single most useful thing to read off a bounce, because it tells you whether waiting will help.
Envelope Versus Headers
This is the part that surprises people. The addresses in MAIL FROM and RCPT TO are the envelope — they are protocol commands, and the recipient never sees them. The From: and To: lines are headers, part of the message content sent inside DATA, and they are what the mail client displays.
Nothing in SMTP requires the two to match. That is not a bug — it is how mailing lists, forwarding and bounce handling all work. It is also how spoofing works, which is why SPF checks the envelope sender, DKIM signs the headers, and DMARC requires that at least one of them align with the domain the reader actually sees.
Return-Path: header that the receiving server adds on delivery. If Return-Path and From disagree in a message you did not expect that from, you are looking at either a forwarder or a spoof — and the DMARC result in Authentication-Results tells you which.Ports and Encryption
Three ports are in general use, and each pairs with exactly one encryption mode. Mismatching them produces the most confusing symptom in mail configuration: the TCP connection succeeds and then the session hangs, because both ends are waiting for the other to speak first.
| Port | Role | Encryption | Authentication |
|---|---|---|---|
587 | Submission — clients sending mail | STARTTLS (connect plain, then upgrade) | Required |
465 | Submission — implicit TLS | TLS from the first byte | Required |
25 | Transport — server to server | Opportunistic STARTTLS | None |
Use 587 unless your provider says otherwise. Port 25 is not a client port, and most ISPs, AWS, Google Cloud and Azure block outbound connections to it by default — silently, by dropping packets, which is why the symptom is a timeout rather than an error.
STARTTLS Is Opportunistic
On the transport leg, TLS is negotiated only if the receiving server advertises STARTTLS in its EHLO response. If it does not, most senders deliver in cleartext rather than fail. That fallback is what makes SMTP encryption weaker than it looks: an attacker who can strip the STARTTLS line from the capability list downgrades the whole session, and neither end notices.
MTA-STS and TLS-RPT exist to close that gap — the first publishes a policy saying "TLS is mandatory for my domain", the second gets you reports when a sender could not comply. Neither changes SMTP itself; they add the commitment the protocol never had.
# Open a real session by hand and read the capability list
openssl s_client -connect smtp.example.com:587 -starttls smtp -crlf
# Implicit TLS on 465 — encrypted before the banner arrives
openssl s_client -connect smtp.example.com:465 -crlf
# Which hosts accept mail for a domain, in preference order
dig +short MX example.comWhere SMTP Sessions Break
Because the protocol is a sequence, the step that fails tells you the category of problem before you know anything else:
| Fails at | What it means | Where to look |
|---|---|---|
| DNS lookup | The hostname or MX record does not resolve | MX records, typos in the host |
| TCP connect | Port blocked (timeout) or nothing listening (refused) | Timeouts and refused connections |
| Banner | Connected but no greeting — usually a reverse DNS lookup stalling | Reverse DNS for your sending IP |
| STARTTLS | Certificate, protocol version or cipher mismatch | Certificate chain and TLS version on the server |
| AUTH | Credentials or auth mechanism rejected | SMTP authentication errors |
| MAIL FROM / RCPT TO | Policy rejection — SPF, DMARC, relay rules, unknown user | The enhanced status code in the reply |
| DATA | Size limit or content filtering | Message size, attachments, spam score |
Frequently Asked Questions
1. What is the difference between SMTP, IMAP and POP3?
SMTP sends and relays mail; IMAP and POP3 retrieve it. They are separate protocols on separate ports, and a mail client normally speaks both — SMTP on 587 to send, IMAP on 993 to read. If your outgoing mail fails but incoming still works, the problem is on the SMTP side and nothing about your IMAP settings is relevant.
2. Should I use port 25, 465 or 587?
Client software should use 587 with STARTTLS, or 465 with implicit TLS — both are submission ports and both require authentication. Port 25 is for server-to-server transport only, and most ISPs and cloud providers block outbound 25 to limit spam. Whichever port you pick, the encryption mode has to match it or the session hangs.
3. What is the difference between the envelope sender and the From header?
The envelope sender is the address in the MAIL FROM command — where bounces go, and what SPF checks. The From: header is inside the message body and is what the recipient sees. They are allowed to differ, which is how mailing lists work and also how spoofing works. DMARC exists precisely to require that one of them align with the visible domain.
4. Does SMTP encrypt my email?
Only the connection, and only when STARTTLS or implicit TLS is in use. SMTP over TLS protects the message in transit between two hops; it is not end-to-end. The message sits in plain text on every server along the way, and a hop that does not offer TLS falls back to cleartext unless a policy like MTA-STS forbids it.
5. Why does my mail server ask for authentication when the recipient server does not?
Two different roles. Submission — you handing a message to your own provider on port 587 — always requires authentication, because otherwise anyone could send as you. Transport — your provider delivering to the recipient’s MX host on port 25 — is anonymous by design, because the receiving server has no account for you. A server that accepts anonymous mail for someone else is an open relay.
6. How can I see the SMTP conversation for my own server?
Run the host through the SMTP Test — it opens a real session, shows the banner, the EHLO capability list, the STARTTLS upgrade and the AUTH result, with timings for each step. From a terminal, openssl s_client -connect host:587 -starttls smtp -crlf gives you the same conversation to type into by hand.