SMTP Protocol Deep-Dive: RFC 5321 Core Specification, Envelopes & Socket Conversations

Historical Foundations: 44 Years of SMTP Evolution

First standardized in August 1982 by Jon Postel in RFC 821, the Simple Mail Transfer Protocol (SMTP) was designed to deliver electronic mail across the ARPANET. Over four decades, while other legacy protocols were replaced, SMTP demonstrated extraordinary resilience, expanding through Extended SMTP (ESMTP, RFC 2821) and culminating in the current core standard: RFC 5321.

SMTP is an in-band, stateful, text-oriented client-server protocol operating over TCP. The client (sending MTA) issues ASCII command verbs, and the server (receiving MTA) responds with three-digit numeric status codes followed by human-readable text strings.

Anatomy of an SMTP Transaction: Full Socket Dialogue

The following trace illustrates a complete, raw RFC 5321 SMTP conversation occurring over an unencrypted TCP socket on port 25:

S: 220 mx.destination.com ESMTP Ready
C: EHLO mta.sender.com
S: 250-mx.destination.com
S: 250-PIPELINING
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<bounces@send.sender.com>
S: 250 2.1.0 Sender <bounces@send.sender.com> OK
C: RCPT TO:<user@destination.com>
S: 250 2.1.5 Recipient <user@destination.com> OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: "Sender Brand" <marketing@sender.com>
C: To: "User Name" <user@destination.com>
C: Subject: Production Status Update
C: Date: Mon, 27 Oct 2026 19:00:00 +0000
C: Message-ID: <unique-id-123@send.sender.com>
C: Content-Type: text/plain; charset=utf-8
C:
C: Hello, this is the message body text.
C: .
S: 250 2.0.0 OK: queued as 4Y8x9K0zZlz3
C: QUIT
S: 221 2.0.0 mx.destination.com Service closing transmission channel

The Envelope vs. Headers Distinction That Breaks DMARC

The single most critical architectural concept in email delivery is the fundamental separation between RFC 5321 Envelope Data and RFC 5322 Message Header Data:

When an email is bounced due to an invalid recipient, the receiving server generates an NDR addressed exclusively to the envelope sender (bounces@send.sender.com), never to the header From: address.

Complete SMTP Command Reference (HELO, EHLO, MAIL, RCPT, DATA)

• EHLO (Extended Hello): The mandatory greeting command that initiates an ESMTP session, transmitting the sending MTA’s fully qualified domain name (FQDN).
• MAIL FROM:: Initiates a new mail transaction and defines the envelope sender / bounce return-path address.
• RCPT TO:: Designates a recipient mailbox. Can be repeated multiple times for multi-recipient deliveries.
• DATA: Informs the server that all subsequent transmitted bytes represent message headers and body, terminating exclusively upon receiving the five-character sequence <CRLF>.<CRLF>.
• RSET (Reset): Aborts the current mail transaction without closing the TCP connection, clearing all envelope state.
• QUIT: Instructs the server to gracefully close the TCP socket.

SMTP Response Code Hierarchy (2yz, 3yz, 4yz, 5yz)

Every response issued by an SMTP server begins with a three-digit status code governed by RFC 5321 Section 4.2.1:

Essential ESMTP Extensions: PIPELINING, SIZE, 8BITMIME

During the initial EHLO greeting, receiving MTAs advertise capabilities using ESMTP extensions:

• PIPELINING (RFC 2920): Allows the client to send MAIL FROM, RCPT TO, and DATA commands in a single TCP packet without waiting for individual server acknowledgments, tripling transmission throughput.
• SIZE (RFC 1870): Declares the maximum message byte size accepted by the server, allowing clients to abort oversized transmissions before wasting bandwidth.
• 8BITMIME (RFC 6152): Permits transmission of 8-bit extended characters without requiring 7-bit ASCII Quoted-Printable encoding.