A comprehensive interactive lesson for network administrators — from RFC 5321 fundamentals to modern security hardening.
Understanding what SMTP is, where it fits, and why it matters for network administration
SMTP (Simple Mail Transfer Protocol) is the standard communication protocol for transmitting email messages across the Internet. Defined initially in RFC 821 (1982) and updated in RFC 5321 (2008), SMTP operates at the Application Layer (Layer 7) of the OSI model, using TCP for reliable transport at Layer 4.
SMTP is a push protocol — it delivers mail from sender to receiver. It does not retrieve mail (that's the job of POP3 or IMAP). Network administrators must understand SMTP to configure mail servers, prevent spam relay, implement security hardening, and troubleshoot delivery failures.
SMTP pushes mail from the client (MUA) through the Mail Transfer Agent (MTA) to the destination server. Unlike POP3/IMAP, it never pulls messages.
SMTP uses a reliable TCP connection. A full handshake is established before any mail transaction begins, ensuring message integrity and delivery confirmation.
Commands and server responses are human-readable ASCII text — a key advantage for troubleshooting with tools like Telnet or OpenSSL.
ESMTP (Extended SMTP, RFC 1869) adds capabilities like AUTH, STARTTLS, SIZE, PIPELINING, and 8BITMIME through the EHLO command.
Mail flow: Mail User Agent submits to MTA (submission), MTA relays to destination MTA, then Mail Delivery Agent stores for recipient retrieval.
MTAs queue messages for retry when a destination is unavailable. Retry intervals follow exponential backoff, typically for 4–5 days before generating NDRs.
The mail delivery pipeline and protocol conversation flow
Understanding the complete mail delivery path is essential for diagnosing failures and configuring mail infrastructure correctly.
Full email delivery pipeline from sender MUA to recipient MUA
Below is a complete SMTP session. The client issues commands; the server responds with 3-digit status codes.
Core commands, extended capabilities, and server response codes
| Command | Syntax | Description | RFC |
|---|---|---|---|
| HELO | HELO domain | Opens SMTP session (legacy). Identifies sending client by domain name. | 5321 |
| EHLO | EHLO domain | Opens ESMTP session. Server responds with supported extensions. | 5321 |
| MAIL FROM | MAIL FROM:<address> | Specifies envelope sender address (return path). Starts mail transaction. | 5321 |
| RCPT TO | RCPT TO:<address> | Specifies envelope recipient. May be repeated for multiple recipients. | 5321 |
| DATA | DATA | Signals start of message content (headers + body). End with lone "." on a line. | 5321 |
| QUIT | QUIT | Gracefully terminates SMTP session. Server sends 221 farewell. | 5321 |
| RSET | RSET | Resets current mail transaction without closing connection. | 5321 |
| NOOP | NOOP | No operation — keeps connection alive, tests server responsiveness. | 5321 |
| VRFY | VRFY username | Verifies mailbox existence. Often disabled to prevent user enumeration. | 5321 |
| EXPN | EXPN listname | Expands a mailing list. Usually disabled for security reasons. | 5321 |
ESMTP extensions are advertised by the server in its EHLO response. Each extension adds new functionality beyond basic SMTP.
| Extension | Keyword | Description | RFC |
|---|---|---|---|
| TLS Upgrade | STARTTLS | Upgrades a plaintext connection to TLS. Must re-EHLO after TLS handshake. | 3207 |
| Authentication | AUTH | Enables client authentication. Mechanisms: PLAIN, LOGIN, CRAM-MD5, OAUTH2. | 4954 |
| Message Size | SIZE | Declares max message size server accepts. Client can check before sending large messages. | 1870 |
| 8-bit MIME | 8BITMIME | Allows 8-bit data in message body without encoding. Needed for UTF-8 content. | 6152 |
| Pipelining | PIPELINING | Allows sending multiple commands without waiting for each response. Improves throughput. | 2920 |
| Delivery Status | DSN | Delivery Status Notifications — success/failure reports back to sender. | 3461 |
| Enhanced Status | ENHANCEDSTATUSCODES | Extended status codes (e.g., 2.0.0, 5.1.1) for better error diagnosis. | 2034 |
| UTF-8 | SMTPUTF8 | Supports Unicode in email addresses and headers (internationalization). | 6531 |
SMTP response codes are 3-digit numbers. The first digit indicates the category; the full code identifies the specific outcome.
The requested action completed successfully.
Command accepted but more input needed to complete the action.
Temporary failure. Sender should retry later (e.g., queue full).
Permanent error. Do not retry without fixing the underlying problem.
| Code | Meaning | Common Cause |
|---|---|---|
| 220 | Service Ready | Server greeting after TCP connection established |
| 221 | Service Closing | Server acknowledges QUIT command |
| 235 | Authentication Succeeded | AUTH credentials accepted |
| 250 | Requested Action OK | EHLO, MAIL FROM, RCPT TO accepted |
| 354 | Start Input, End with "." | Server ready to receive message DATA |
| 421 | Service Unavailable | Server temporarily unavailable, closing connection |
| 450 | Mailbox Unavailable | Temporary — mailbox busy or locked |
| 451 | Local Processing Error | Server error in processing — retry later |
| 452 | Insufficient Storage | Disk quota exceeded, retry later |
| 500 | Syntax Error | Command not recognized |
| 501 | Syntax Error in Parameters | Malformed MAIL FROM or RCPT TO address |
| 503 | Bad Sequence | Commands sent out of order |
| 530 | Authentication Required | Client must authenticate before sending mail |
| 550 | Mailbox Unavailable | No such user / relay denied / blacklisted |
| 552 | Exceeded Storage | Recipient mailbox full — permanent |
| 553 | Mailbox Name Not Allowed | Invalid address syntax |
| 554 | Transaction Failed | Spam rejection, policy violation |
Port assignments, TLS configurations, and anti-spam authentication mechanisms
| Port | Name | Encryption | Use Case | RFC |
|---|---|---|---|---|
| 25 | SMTP | None / STARTTLS | MTA-to-MTA relay. Blocked by ISPs for residential users to prevent spam. | 5321 |
| 465 | SMTPS (legacy) | Implicit TLS (SSL) | Deprecated but still widely used. TLS wraps entire session from start. | N/A |
| 587 | Submission | STARTTLS (required) | Recommended for MUA-to-MTA submission. Requires AUTH. | 6409 |
| 2525 | Alternate Submission | STARTTLS | Alternative when 587 is blocked. Non-standard, used by some cloud providers. | N/A |
Modern email security relies on three complementary DNS-based authentication systems that protect against spoofing, phishing, and spam.
A DNS TXT record that lists authorized mail servers for a domain. Receiving MTAs verify the sending IP is authorized.
Cryptographic signature added to outgoing messages. Receiving server verifies with public key from DNS. Ensures content integrity.
Policy layer on top of SPF and DKIM. Defines what to do when checks fail (none/quarantine/reject) and enables aggregate reporting.
An open relay is an SMTP server misconfigured to forward mail from any source to any destination without authentication. Open relays are immediately exploited by spammers and will be added to blacklists (DNSBLs) within hours. Network administrators must configure servers to require AUTH for submission and restrict relay to trusted networks.
Anatomy of an email message header — required fields, optional fields, and tracing headers
Email headers are structured name-value pairs separated from the message body by a blank line. Headers added by the originating MUA are called originating headers. Each MTA that handles the message prepends a Received: header, creating an audit trail.
| Header | Example | Description |
|---|---|---|
From: | From: Alice <alice@example.com> | Display name and email address of message author (RFC 5322 §3.6.2) |
Date: | Date: Tue, 21 Feb 2026 10:00:00 -0500 | Date and time message was composed (RFC 5322 format) |
Message-ID: | Message-ID: <abc123@sender.org> | Globally unique identifier for the message. Format: local@domain |
| Header | Example | Description |
|---|---|---|
To: | To: Bob <bob@example.com> | Primary recipient(s) displayed to the reader |
Cc: | Cc: Carol <carol@example.com> | Carbon copy recipients — visible to all recipients |
Bcc: | Bcc: Dave <dave@example.com> | Blind carbon copy — removed before delivery to other recipients |
Subject: | Subject: Meeting Tomorrow | Summary of message content |
Reply-To: | Reply-To: noreply@example.com | Directs replies to a different address than From: |
MIME-Version: | MIME-Version: 1.0 | Declares MIME compliance (RFC 2045) |
Content-Type: | Content-Type: text/html; charset=UTF-8 | Media type of message body |
Content-Transfer-Encoding: | Content-Transfer-Encoding: quoted-printable | Encoding of message body (7bit, 8bit, base64, quoted-printable) |
In-Reply-To: | In-Reply-To: <orig@example.com> | Message-ID of the message being replied to (enables threading) |
X-Mailer: | X-Mailer: Thunderbird 115.0 | Identifies the sending MUA (informational) |
Each MTA prepends a Received: header. Reading them from bottom to top traces the message path from origin to destination.
Each Received: header contains: from (sending host), by (receiving host), with (protocol), for (recipient), and the timestamp. Analyzing these headers is critical for tracing spam and diagnosing delivery delays.
| Header | Example | Description |
|---|---|---|
DKIM-Signature: | DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail; b=... | Cryptographic signature from sending domain |
Authentication-Results: | Authentication-Results: mx.google.com; spf=pass; dkim=pass; dmarc=pass | Results of SPF, DKIM, DMARC checks by receiving MTA |
Received-SPF: | Received-SPF: pass (google.com: domain of alice@example.com designates 192.0.2.1 as permitted sender) | SPF check result with details |
X-Spam-Status: | X-Spam-Status: No, score=1.2 required=5.0 | SpamAssassin or similar filter result |
X-Spam-Score: | X-Spam-Score: 1.2 | Numeric spam score — higher = more likely spam |
ARC-Authentication-Results: | ARC-Authentication-Results: i=1; mx.google.com; ... | Authenticated Received Chain — preserves auth results through forwarding (RFC 8617) |
Construct a complete SMTP message header — fill in the fields and generate your header in real time
Practice a live SMTP conversation — type commands and receive realistic server responses
Essential SMTP terms every network administrator must know
Test your understanding of SMTP — 10 questions covering commands, ports, security, and headers