SMTP (Simple Mail Transfer Protocol)

SMTP (Simple Mail Transfer Protocol) is the Internet standard for email transmission. Created in 1982, it defines how mail servers communicate to transfer messages from senders to recipients. Despite being over four decades old, SMTP remains the backbone of email delivery, handling billions of messages daily.

Here's the thing about SMTP: it's a conversation. Literally. Two machines talking to each other in plain text, being polite, asking permission, and saying goodbye. Understanding SMTP means understanding that conversation.

The Conversation

SMTP operates through a text-based exchange between a client (the sender) and server (the receiver). The client issues commands, the server responds with three-digit status codes. Watch two mail servers talk:

S: 220 mail.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-mail.example.com
S: 250-SIZE 52428800
S: 250-STARTTLS
S: 250 HELP
C: MAIL FROM:<sender@client.example.com>
S: 250 OK
C: RCPT TO:<recipient@example.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: sender@client.example.com
C: To: recipient@example.com
C: Subject: Test Message
C:
C: This is the message body.
C: .
S: 250 OK: queued as 12345
C: QUIT
S: 221 Bye

That's it. The entire protocol. The server says hello (220), the client introduces itself (EHLO), they negotiate what the server can do (SIZE, STARTTLS), the client announces the sender and recipient, transmits the message, and they say goodbye. Polite machines.

The command structure:

• EHLO: "Hello, I'm client.example.com." The server responds with its capabilities.
• MAIL FROM: "I have a message from this address." The server says OK or rejects.
• RCPT TO: "It's going to this address." Can be repeated for multiple recipients.
• DATA: "Here comes the message." A lone period on a line ends it.
• QUIT: "Goodbye." Connection closes.

Response Codes

SMTP servers speak in three-digit codes. The first digit tells you everything:

2xx — Success. The server did what you asked.

• 220: Ready to talk
• 250: Done, no problems
• 251: User isn't here, but I'll forward it

3xx — Keep going. The server needs more.

• 354: Send me the message content

4xx — Try later. Temporary problem.

• 421: Service unavailable right now
• 450: Mailbox busy, try again
• 452: Out of storage space

5xx — Give up. Permanent failure.

• 550: Mailbox doesn't exist
• 553: Mailbox name not allowed
• 554: Transaction failed

When a sending server gets a 4xx, it queues the message and retries. When it gets a 5xx, it bounces the message back to the sender immediately.

The Original Sin

SMTP was designed when the Internet was a few hundred academics who trusted each other. Spam didn't exist yet. Neither did phishing. The protocol's original sin—trusting the sender to tell the truth about who they are—haunts email to this day.

The MAIL FROM address? The sender just types it. The server believes them. The From header in the message? Same thing. This is why spoofing email addresses is trivial, and why we've spent decades bolting on authentication systems (SPF, DKIM, DMARC) to verify that senders are who they claim to be.

ESMTP: Bolting Things On

The original SMTP was limited. ESMTP (Extended SMTP) adds capabilities through extensions negotiated during the EHLO exchange. When the server lists what it can do, it's advertising extensions:

SIZE — Maximum message size:

250-SIZE 52428800

That's 50MB. Send something bigger and you'll get a 552 (exceeded storage).

STARTTLS — Encryption. The client says STARTTLS, the server says ready, and they upgrade to an encrypted connection. After that, everything is protected from eavesdropping.

AUTH — Authentication. The client proves who they are before sending:

C: AUTH PLAIN
S: 334
C: [base64-encoded credentials]
S: 235 Authentication successful

PIPELINING — Send multiple commands without waiting for responses. Faster.

8BITMIME — Support for characters beyond ASCII. Because not everyone writes in English.

SMTPUTF8 — Unicode email addresses. Japanese characters in the local part, internationalized domain names.

Two Different Jobs

SMTP handles two distinct operations with different rules:

Submission (you to your mail server) — Port 587. Requires authentication and encryption. You prove who you are before your server accepts your message. Rate limits prevent abuse.

Relay (server to server) — Port 25. No authentication. Your mail server looks up the recipient's server via MX records and delivers. Trust is based on IP reputation and DNS, not passwords.

This distinction matters. In the 1990s, "open relays"—servers that accepted mail from anyone for delivery to anyone—were everywhere. Spammers exploited them ruthlessly. Modern servers separate submission (authenticated) from relay (controlled) to prevent this.

Security, Eventually

Original SMTP transmitted everything as plain text. Your password, your message, all readable by anyone watching the network. Modern SMTP adds security through layers:

STARTTLS encrypts the connection. Most server-to-server mail now travels encrypted, though opportunistically—if encryption fails, delivery proceeds unencrypted. Mail gets through, even if it's not private.

MTA-STS enforces encryption. Domains can publish policies requiring TLS, preventing downgrade attacks where an attacker forces unencrypted delivery.

SMTP AUTH requires authentication before submission. Your mail server won't send messages unless you prove you're allowed to.

What SMTP Can't Do

No end-to-end encryption. STARTTLS protects messages in transit, but servers see everything. For true privacy, you need something like PGP or S/MIME on top.

No delivery confirmation. SMTP confirms the receiving server accepted the message. Not that it reached an inbox. Not that anyone read it.

No recall. Once a server responds 250 OK, the message is gone. There's no "unsend." Some email providers fake it with proprietary extensions, but SMTP itself offers no mechanism.

No sender verification. The From address is just text. SPF, DKIM, and DMARC verify sender identity, but they're separate systems, not part of SMTP itself.

Why SMTP Endures

SMTP is 40 years old. It was designed for a network that no longer exists. Its security model was naive. Its trust assumptions were wrong. And yet:

Universal. Every mail server speaks SMTP. Gmail, corporate Exchange servers, self-hosted Postfix boxes—they all interoperate because they all speak the same protocol. You can email anyone from anywhere.

Simple. The protocol is text. You can (in theory) send email by typing commands manually. This simplicity makes it debuggable, implementable, and remarkably robust.

Extensible. ESMTP's extension mechanism has kept SMTP relevant. New capabilities get added without breaking old servers. A server that doesn't understand an extension just ignores it.

Resilient. SMTP's store-and-forward design handles failures gracefully. Message won't deliver? Queue it. Try again in an hour. Network back up? Delivery succeeds. This architecture survives the real Internet's unreliability.

SMTP's longevity isn't because it's perfect. It's because it's good enough, simple enough, and universal enough that replacing it would require everyone to agree on something better—and getting everyone to agree on anything is harder than living with SMTP's quirks.