SMTP

Send an email from [email protected] to [email protected] and it doesn't travel directly between their two mailboxes. It goes from Alice's mail client to her provider's outgoing mail server, hops from there to Bob's provider's mail server, and only then lands in a mailbox Bob's own client will later come and collect from. Every one of those server-to-server and client-to-server handoffs speaks the same protocol: SMTP, the Simple Mail Transfer Protocol, specified in RFC 5321 and essentially unchanged in its core mechanics since the 1980s.

The envelope and the message are two different things

The single idea that unlocks the rest of SMTP is that a piece of mail has two separate identities layered on top of each other.

The envelope is what SMTP itself uses for delivery: a sender address and one or more recipient addresses, exchanged as commands during the SMTP conversation. Think of it like the outside of a physical envelope — what the postal service actually reads to route it.

The message is the actual email — the From:, To:, Subject:, and body — written by the mail client and carried as opaque data inside the DATA command. SMTP doesn't parse or care about these headers at all; it just transports whatever bytes it's given between the DATA command and the terminating line.

Those two don't have to match, and that mismatch is both completely normal and the reason email spoofing is possible at all. A mailing list commonly sets the envelope sender to a special bounce-handling address while the message's From: header shows the original author. Nothing in SMTP itself verifies that the envelope sender and the From: header belong to the same person — that verification, where it exists, is bolted on afterward by mechanisms this article's closing section points toward.

A real SMTP conversation

SMTP commands and replies are plain ASCII, one line at a time, in the same style as FTP. A session delivering one message looks like this, after a TCP connection is opened to port 25:

220 mail.example.com ESMTP Postfix
EHLO client.example.org
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250 STARTTLS
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: Alice <[email protected]>
To: Bob <[email protected]>
Subject: Meeting tomorrow

Let's meet at 10am.
.
250 2.0.0 Ok: queued as A1B2C3D4
QUIT
221 2.0.0 Bye

Reading it top to bottom: EHLO (Extended HELLO) opens the conversation and asks the server to list which SMTP extensions it supports — the 250- lines that follow are exactly that list, with STARTTLS meaning the connection can be upgraded to TLS mid-session before anything sensitive is sent. MAIL FROM and RCPT TO are the envelope; note they're separate commands from anything in the message body that follows. DATA switches the connection into message-transfer mode, and the sending side ends the message with a line containing only a period — the SMTP equivalent of Content-Length, giving the receiving side an unambiguous end marker inside a stream that has no boundaries of its own. The 250 2.0.0 reply's extra 2.0.0 is an enhanced status code, a finer-grained classification layered on top of the older three-digit reply for exactly the cases where "it worked" isn't specific enough for automated logging.

HELO, without the E, is the original 1982 command and still accepted by every server for compatibility — but a server that only speaks HELO won't offer any of the extensions listed above, including STARTTLS, which is reason enough that virtually nothing sends plain HELO today.

Relay, submission, and why there are three ports

SMTP genuinely uses three different well-known ports, and each one exists for a distinct reason rather than as historical accident:

Port	Role	Encryption
25	Server-to-server relay	Opportunistic `STARTTLS`, often none at all
587	Message submission from a mail client	`STARTTLS` required in practice
465	Message submission from a mail client	Implicit TLS from the first byte

Port 25 is for mail servers talking to each other — the actual internet-wide relay of a message from Alice's provider to Bob's. Port 587, standardized separately in RFC 6409 as "message submission," exists so a mail client — Alice's laptop or phone — has a distinct, clearly-authenticated path to hand a message to her own provider, kept apart from the relay traffic on port 25 precisely so a provider can lock down authentication requirements on submission without disturbing how it accepts relayed mail from the rest of the internet. Port 465 does the same job as 587 but wraps the entire connection in TLS immediately, before any SMTP command is exchanged, rather than negotiating encryption partway through with STARTTLS — RFC 8314 recommends this "implicit TLS" approach for new client configurations, though both still work and both remain in wide use.

The practical consequence: a residential ISP blocking outbound port 25 (a common anti-spam measure, since a botnet-infected home computer relaying mail directly is a classic abuse pattern) doesn't stop you from sending mail through your own provider's mail app, because that app is very likely configured to submit on 587 or 465, not to relay on 25 at all.

Open relays and why nobody runs one anymore

An SMTP server that accepts RCPT TO for any domain, from any connecting client, without authentication, is an open relay. In the early internet this was the default and unremarkable configuration. Today it's treated as a serious misconfiguration.

An open relay gets found and abused within hours

Spam operations continuously scan the internet for servers that will accept and forward mail without authenticating the sender. An accidentally open relay becomes a free spam-sending platform almost immediately, and the consequence isn't abstract: major providers maintain shared blocklists, and a server caught relaying spam gets its IP address blocklisted, at which point legitimate mail from that server starts bouncing or landing in everyone's spam folder — often for a mail server that has nothing to do with the abuse beyond having been the unwitting relay for it.

Every modern mail server requires authentication before accepting mail for relay to an external domain — either the connecting client is authenticated (the submission-port case above) or the message is destined for a domain the server is itself authoritative for.

Practical scenario: mail that sends, arrives, and lands in spam anyway

An internal notification service starts emailing customers directly from a new backend server, sending straight to each customer's mail provider on port 25. The SMTP conversation itself completes cleanly every time — 250 2.0.0 Ok on every send — but customers report the messages either never arrive or land straight in their spam folder.

telnet mail-provider.example.com 25 from the sending server, followed by the same EHLO/MAIL FROM/RCPT TO/DATA sequence by hand, confirms the receiving server accepts the message without complaint — so this isn't a connectivity or syntax problem. The issue is that a 250 Ok from SMTP only means "I accepted this message for further processing." It says nothing about whether the receiving provider's spam filter later decides to deliver it to the inbox, and modern spam filtering leans heavily on whether the sending server is actually authorized to send mail for that sender's domain in the first place — a check performed by looking up specific DNS records for the sender's domain, not by anything carried inside the SMTP conversation itself.

The fix isn't in SMTP at all: it's publishing the right DNS records for the sending domain — TXT records that authorize this specific server to send as that domain and let receiving servers cryptographically verify the message wasn't forged. Without them, a technically perfect SMTP delivery still reads, to every major receiving provider, like mail from a server with no stated authority to send it.

Common mistakes

Reading 250 Ok as proof of successful delivery to the inbox. It confirms the receiving server accepted the message for its own further handling — nothing about spam filtering, inbox placement, or even final delivery has happened yet.
Confusing relay and submission. Port 25 is for server-to-server relay; a mail client sending its own outgoing mail should be authenticating and submitting on 587 or 465, not connecting to port 25 directly.
Assuming envelope sender and the From: header are the same thing, or must match. SMTP never requires it, which is exactly why forging the visible From: header while leaving a different envelope sender is trivial without additional authentication layered on top.

Practice exercises

Using telnet <mail-server> 25 (or openssl s_client if the server requires TLS immediately) against a mail server you're authorized to test, walk through EHLO, MAIL FROM, RCPT TO, and DATA by hand, and identify which reply corresponds to each step.
Explain, citing the three-port table above, why blocking outbound port 25 on a residential network is a reasonable anti-abuse measure that still leaves ordinary users able to send email normally.
A message's envelope sender is [email protected] while its From: header reads [email protected]. Explain why this is legitimate, routine behavior rather than evidence of spoofing.

SMTP gets a message from sender to recipient's mail server. What happens after that — how the message actually reaches a person's inbox and screen — is a completely separate problem, handled by a different pair of protocols: POP3 is next.