SMTP Email Explained

An In-Depth Technical Analysis of the Simple Mail Transfer Protocol (SMTP)

I. Understanding the Simple Mail Transfer Protocol (SMTP)

A. Defining SMTP: The Engine of Email Transmission

The Simple Mail Transfer Protocol, universally abbreviated as SMTP, serves as the cornerstone technical standard for the transmission of electronic mail (email) across networks, including the internet.¹ It is fundamentally a communication protocol, a set of defined rules enabling disparate computer systems and servers to reliably exchange email messages.³ Operating at the Application Layer (Layer 7) of the Open Systems Interconnection (OSI) model, SMTP typically relies on the Transmission Control Protocol (TCP) for its transport layer services, inheriting TCP's connection-oriented nature to ensure ordered and reliable data delivery.²

The primary mandate of SMTP is to facilitate the transfer of email data—encompassing sender information, recipient details, and the message content itself—between mail servers, often referred to as Mail Transfer Agents (MTAs), and from email clients (Mail User Agents, MUAs) to mail servers (specifically, Mail Submission Agents, MSAs).³ Its design allows this exchange irrespective of the underlying hardware or software platforms of the communicating systems, providing the interoperability essential for a global email network.¹ In essence, SMTP functions as the digital equivalent of a postal service, standardizing the addressing and transport mechanisms required to move electronic letters from origin to destination servers.⁵

The protocol's origins trace back to 1982 with the publication of RFC 821.⁷ This initial specification emphasized simplicity and robustness, leveraging the reliability of TCP to focus on the core logic of mail transfer through a text-based command-reply interaction model.² This design choice facilitated implementation and debugging across the diverse computing landscape of the early internet. However, this initial focus on simplicity meant that security features like sender authentication and message encryption were not inherent in the original protocol.⁴

Subsequent revisions, notably RFC 2821 in 2001 and the current standard RFC 5321 published in 2008, have updated and clarified the protocol.⁶ Furthermore, the introduction of Extended SMTP (ESMTP) through RFC 1869 in 1995 paved the way for crucial enhancements, including mechanisms for authentication (SMTP AUTH), encryption (STARTTLS), and handling larger messages, addressing the security and functional limitations of the original specification in the context of the modern internet.⁷ This evolution highlights how SMTP has adapted over decades, layering necessary complexities onto its simple foundation to meet contemporary requirements for security and functionality.

B. SMTP's Foundational Role in Internet Email

SMTP's role within the broader internet email architecture is specific and critical: it is the protocol responsible for sending or pushing email messages through the network.² It acts as the transport mechanism, the digital mail carrier, moving an email from the sender's mail system towards the recipient's mail server.²

Crucially, SMTP is defined as a mail delivery or push protocol, distinguishing it sharply from mail retrieval protocols.² Its function concludes when it successfully delivers the email message to the mail server responsible for the recipient's mailbox.² The subsequent process, where the recipient uses an email client application to access and read the email stored in their server-side mailbox, relies on entirely different protocols: primarily the Post Office Protocol version 3 (POP3) or the Internet Message Access Protocol (IMAP).² In architectural terms, SMTP pushes the email to the destination server, while POP3 and IMAP allow the user's client to pull the email from that server.²

This fundamental separation between the "push" mechanism of sending (SMTP) and the "pull" mechanism of retrieval (POP3/IMAP) is a defining characteristic of the internet email system. Sending mail inherently requires a protocol capable of initiating connections across the network and actively transferring data, potentially traversing multiple intermediate servers (relays) to reach the final destination; this is the active "push" performed by SMTP.² Conversely, receiving mail typically involves a user checking their mailbox periodically or being notified of new mail. The recipient's mail server passively holds the mail until the user's client initiates a connection to retrieve it—a "pull" action facilitated by POP3 or IMAP.⁶

This architectural dichotomy allows for specialization: SMTP servers (MTAs) are optimized for routing, relaying, and handling the complexities of inter-server communication, while POP3/IMAP servers focus on mailbox management, storage, and providing efficient access for end-user clients.⁶ This separation also enables diverse user experiences; IMAP, for instance, facilitates synchronized access across multiple devices, whereas POP3 traditionally supports a simpler download-and-delete model suitable for single-device offline access.²² Understanding this push/pull distinction is essential for correctly configuring email clients, which require settings for both the outgoing (SMTP) server and the incoming (POP3 or IMAP) server ²⁵, and for appreciating SMTP's specific, yet vital, contribution to the overall email ecosystem.

II. The Journey of an Email: SMTP in Action

A. Conceptual Overview: From Sender to Recipient

The process of sending an email using SMTP can be effectively understood through an analogy with traditional postal mail.² When a user sends an email, their email client (MUA) acts like someone dropping a letter into a mailbox. This initial action transfers the email to the sender's configured outgoing mail server, akin to a local post office.² This server, acting as an SMTP client, then examines the recipient's address. If the recipient is on a different domain, the server forwards the email to another mail server closer to the recipient, similar to how a post office routes mail to another post office in the destination city.² This relay process may involve several intermediate mail servers ("hops") before the email finally arrives at the mail server responsible for the recipient's domain—the destination post office.² This final server then uses SMTP to accept the message and subsequently delivers it into the recipient's individual mailbox, where it awaits retrieval.³ The recipient then uses a retrieval protocol like POP3 or IMAP to access the email from their mailbox.³

This multi-step process reveals that SMTP operates fundamentally as a distributed, store-and-forward relay system.⁶ An email rarely travels directly from the sender's originating server to the recipient's final server in a single SMTP connection.² Instead, the initial mail server (MTA), after receiving the email from the sender's client (MUA) via a Mail Submission Agent (MSA) ⁶, determines the next hop by querying the Domain Name System (DNS) for the recipient domain's Mail Exchanger (MX) record.² It then establishes a new SMTP connection to the server indicated by the MX record and transfers the message.⁶ This receiving server might be the final destination or another intermediary MTA, which repeats the lookup and relay process.⁶ Each MTA that handles the message assumes responsibility for its onward transmission and typically adds a Received: header field to the message, creating a traceable path.⁵ This store-and-forward architecture provides resilience, as alternative routes can potentially be used if one server is unavailable. However, it can also introduce latency due to multiple network roundtrips and processing delays at each hop.⁸ Historically, this relay function, when improperly configured without authentication ("open relays"), was heavily abused for spam distribution, leading to the widespread adoption of authentication mechanisms.³⁵

B. Detailed Step-by-Step Transmission via SMTP

The journey of an email via SMTP involves a precise sequence of interactions between different mail agents. Let's trace this path in detail:

1. Initiation (MUA to MSA/MTA): The process begins when a user composes an email using their Mail User Agent (MUA)—an email client like Outlook or a webmail interface like Gmail—and clicks "Send".¹⁰ The MUA establishes a TCP connection to the outgoing mail server configured in its settings.² This server typically functions as a Mail Submission Agent (MSA) and listens on standard submission ports, primarily port 587 or, for legacy compatibility using implicit TLS, port 465.⁶ The connection usually requires authentication (SMTP AUTH) to verify the sender's identity.⁶

2. SMTP Handshake: Once the TCP connection is established, the client (initially the MUA, later a sending MTA) starts the SMTP dialogue by sending a greeting command: either HELO or, preferably, EHLO (Extended HELO).² EHLO signals that the client supports ESMTP extensions. The server responds with a success code (e.g., 250) and, if EHLO was used, a list of the extensions it supports, such as AUTH, STARTTLS, SIZE, etc..³⁵ If the connection needs to be secured, and STARTTLS is supported, the client issues the STARTTLS command now to encrypt the session before proceeding to authentication or data transfer.⁵

3. Sender & Recipient Identification (Envelope Creation): The client defines the "envelope" for the message. It issues the MAIL FROM:<sender_address> command, specifying the envelope sender address (also known as the return-path or RFC5321.MailFrom).² This address is crucial as it's where bounce notifications (Non-Delivery Reports, NDRs) will be sent if delivery fails.⁶ The server acknowledges with a success code (e.g., 250 OK) if the sender is acceptable.²⁴ Next, the client issues one or more RCPT TO:<recipient_address> commands, one for each intended recipient (envelope recipient or RFC5321.RcptTo).² The server verifies each recipient address and responds with a success code for each valid one or an error code for invalid ones.²⁴

4. Data Transfer: After successfully identifying the sender and at least one recipient, the client sends the DATA command to signal its readiness to transmit the actual email content.² The server typically responds with an intermediate code like 354 Start mail input; end with <CRLF>.<CRLF> indicating it's ready to receive.⁶ The client then sends the entire email message content, formatted according to RFC 5322, which includes the message headers (e.g., From:, To:, Subject:) followed by a blank line and the message body.⁶ The end of the data transmission is marked by sending a single line containing only a period (.).² Upon receiving the end-of-data marker, the server processes the message and responds with a final status code, such as 250 OK: queued as <message-id> if accepted for delivery, or an error code if rejected.⁶

5. Relaying (MTA to MTA): If the server that just received the message (acting as an MTA) is not the final destination server for a given recipient, it must relay the message. It assumes the role of an SMTP client. It performs a DNS query to find the MX (Mail Exchanger) records for the recipient's domain.² Based on the MX records, it selects the appropriate next-hop MTA (prioritizing lower preference values) and establishes a new TCP connection, typically to port 25 of the target MTA.⁶ It then repeats the SMTP transaction steps (Handshake, Sender/Recipient ID, Data Transfer - steps 2-4 above) to forward the message. Each MTA involved in relaying usually adds a Received: trace header to the message content.⁵

6. Final Delivery (MTA to MDA): When the email eventually reaches the MTA designated by the MX record as the final destination for the recipient's domain, that MTA accepts the message via the standard SMTP transaction (steps 2-4).⁶ Instead of relaying further, this final MTA passes the complete message to the Mail Delivery Agent (MDA) responsible for local delivery.⁶

7. Storage: The MDA takes the message and saves it into the specific recipient's server-side mailbox.⁶ The storage format might be mbox, Maildir, or another system used by the mail server software.⁶ At this point, the email is successfully delivered from SMTP's perspective and awaits retrieval by the recipient's MUA using POP3 or IMAP.

8. Termination: After the DATA sequence is completed (successfully or with an error) and the client has no more messages to send in the current session, it sends the QUIT command.² The server responds with a final acknowledgment code (e.g., 221 Bye) and closes the TCP connection.¹⁸

This step-by-step process illustrates that an SMTP transaction is fundamentally a stateful dialogue. The sequence of commands—EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT—must occur in a specific order, and the server maintains context about the ongoing transaction (who the sender is, who the recipients are).⁶ The success of each command typically depends on the successful completion of the preceding ones. For example, RCPT TO is only valid after a successful MAIL FROM, and DATA only after successful MAIL FROM and at least one successful RCPT TO. The RSET command provides a mechanism to abort the current transaction state (sender/recipients) without closing the underlying TCP connection, allowing the client to restart the transaction if an error occurs mid-sequence.² This stateful, command-driven interaction requires strict adherence to the protocol by both client and server but provides explicit control and error reporting at each stage, contributing to the robustness of email delivery. The clear status codes (2xx for success, 3xx for intermediate steps, 4xx for temporary failures, 5xx for permanent failures) allow the client to react appropriately, such as retrying later for temporary issues or generating an NDR for permanent ones.⁵

C. The Role of DNS MX Records in Email Routing

The Domain Name System (DNS) plays an indispensable role in directing SMTP traffic across the internet, specifically through Mail Exchanger (MX) records.² When a Mail Transfer Agent (MTA) needs to send an email to a recipient at a domain different from its own (e.g., sending from [e-mail] to [e-mail]), it cannot simply connect to destination.org. Instead, it must determine which specific server(s) are designated to handle incoming mail for the destination.org domain.⁶

To achieve this, the sending MTA performs a DNS query, specifically requesting the MX records associated with the recipient's domain name (destination.org in this case).² The DNS server responsible for destination.org responds with a list of one or more MX records.⁶ Each MX record contains two key pieces of information:

1. Preference Value (or Priority): A numerical value indicating the order in which servers should be tried. Lower numbers represent higher priority.³⁴

2. Hostname: The fully qualified domain name (FQDN) of a mail server configured to accept email for that domain (e.g., mx1.destination.org, mx2.provider.net).⁶

The sending MTA uses this list to select the target server. It attempts to establish an SMTP connection (usually on TCP port 25 for inter-server relay) with the server listed in the highest priority MX record (the one with the lowest preference number).⁶ If that connection fails (e.g., the server is unreachable or refuses the connection), the MTA proceeds to try the server with the next highest priority, continuing down the list until a successful connection is made or all options are exhausted.³⁴ Once connected, the MTA initiates the SMTP transaction to transfer the email.

The use of MX records provides a crucial layer of indirection, decoupling the logical domain name used in email addresses from the physical or logical infrastructure handling the email.³⁴ An organization (destination.org) can have its website hosted on one set of servers while its email is managed by entirely different servers, potentially operated by a third-party provider (like Google Workspace or Microsoft 365), without senders needing to know these specific server hostnames.³⁴ The MX records act as pointers, directing SMTP traffic to the correct location(s). This architecture offers significant advantages:

• Flexibility: Organizations can change their email hosting provider or internal mail server infrastructure simply by updating their DNS MX records, without impacting their domain name or how others send email to them.

• Redundancy: Having multiple MX records with different priorities allows for backup mail servers. If the primary server (highest priority) is down, email can still be delivered to a secondary server.³⁴

• Load Balancing: While not its primary purpose, multiple MX records with the same priority can distribute incoming mail load across several servers (though this requires careful configuration).

Consequently, correctly configured MX records are vital for reliable email delivery. Errors in MX records (e.g., pointing to non-existent servers, incorrect hostnames, or incorrect priorities) are a common source of email routing problems, preventing legitimate emails from reaching their intended recipients.

III. Core Components of the SMTP Ecosystem

The transmission of email via SMTP involves the coordinated action of several distinct software components or agents, each fulfilling a specific role in the message lifecycle. Understanding these components is key to grasping the end-to-end process.

Agent	Full Name	Primary Function	Key Interactions / Typical Port(s)	Supporting Information
MUA	Mail User Agent	User interface for composing, sending, reading mail	Submits mail to MSA (via 587/465); Retrieves mail via POP/IMAP (110/995, 143/993)	2
MSA	Mail Submission Agent	Receives mail from MUA, authenticates sender	Listens on 587 (preferred) or 465; Requires authentication (SMTP AUTH); Hands off to MTA	2
MTA	Mail Transfer Agent	Relays mail between servers using SMTP	Receives from MSA/MTA; Sends to MTA/MDA; Uses DNS MX lookup; Often uses port 25 for relay	2
MDA	Mail Delivery Agent	Delivers mail to the recipient's local mailbox	Receives from final MTA; Stores mail in mailbox format (mbox/Maildir)	2

A. Mail User Agent (MUA): The User's Interface

The Mail User Agent (MUA) is the application layer software that end-users interact with directly to manage their email.² It serves as the primary interface for composing new messages, reading received messages, and organizing email correspondence.²⁶ MUAs come in various forms, including desktop client applications such as Microsoft Outlook, Mozilla Thunderbird, and Apple Mail, as well as web-based interfaces provided by services like Gmail, Yahoo Mail, and Outlook.com.⁷

In the context of sending email, the MUA's role is to construct the message based on user input and then initiate the transmission process. After the user composes the message and clicks "Send," the MUA connects to a pre-configured outgoing mail server, typically a Mail Submission Agent (MSA), using the SMTP protocol.⁶ This connection is usually established over secure ports like 587 (using STARTTLS) or 465 (using implicit TLS/SSL) and involves authentication to verify the user's permission to send mail through that server.⁶ For receiving email, the MUA employs different protocols, POP3 or IMAP, to connect to the incoming mail server and retrieve messages from the user's mailbox stored on that server.⁶

B. Mail Submission Agent (MSA): The Initial Hand-off

The Mail Submission Agent (MSA) acts as the initial gatekeeper for outgoing email originating from a user's MUA.² It is a server-side component specifically designed to receive email submissions from authenticated clients.¹¹ The MSA typically listens on TCP port 587, the designated standard port for email submission, although port 465 (originally for SMTPS) is also commonly used.⁶

A primary and critical function of the MSA is to enforce sender authentication using SMTP AUTH.¹¹ Before accepting an email for further processing and relay, the MSA verifies the credentials provided by the MUA (e.g., username/password, API key, OAuth token).¹⁹ This step is crucial for preventing unauthorized users or spammers from abusing the mail server.⁹ The MSA might also perform preliminary checks on the message headers or recipient addresses.⁷ Once a message is successfully authenticated and accepted, the MSA's responsibility is to pass it along to a Mail Transfer Agent (MTA), which will handle the subsequent routing and delivery towards the recipient.⁶ It's important to note that while MSA and MTA represent distinct logical functions, they are often implemented within the same mail server software (e.g., Postfix, Sendmail, Exim), potentially running as different instances or configurations on the same machine.⁶ The separation of the submission function (MSA on port 587/465 with mandatory authentication) from the relay function (MTA often on port 25) is a key architectural element for modern email security.

C. Mail Transfer Agent (MTA): The Relay System

The Mail Transfer Agent (MTA), often simply called a mail server, mail relay, mail exchanger, or MX host, forms the backbone of the email transport infrastructure.² Its core function is to receive emails (from MSAs or other MTAs) and route them towards their final destinations using the SMTP protocol.⁶ Well-known MTA software includes Sendmail, Postfix, Exim, and qmail.²⁶

When an MTA receives an email, it examines the recipient address(es). If the recipient's domain is handled locally by the server itself, the MTA passes the message to the appropriate Mail Delivery Agent (MDA) for final delivery.⁶ However, if the recipient is on a remote domain, the MTA must act as an SMTP client to relay the message forward.⁶ It performs a DNS lookup to find the MX records for the recipient's domain, identifies the next-hop MTA based on priority, and establishes an SMTP connection (traditionally on port 25) to that server.² It then uses SMTP commands to transfer the message to the next MTA.⁶ This process may repeat through several intermediate MTAs.⁶ MTAs are designed to handle potential delivery delays; if a destination server is temporarily unavailable, the MTA will typically queue the message and retry delivery periodically.⁷ As messages traverse the network, each handling MTA usually prepends a Received: header field, creating a log of the message's path.⁵

D. Mail Delivery Agent (MDA): The Final Delivery

The Mail Delivery Agent (MDA), sometimes referred to as the Local Delivery Agent (LDA), represents the final step in the email delivery chain on the recipient's side.⁶ Its responsibility begins after the last MTA in the path—the one authoritative for the recipient's domain—has successfully received the email message via SMTP.²

The MTA hands the fully received message over to the MDA.⁶ The MDA's primary task is to place this message into the correct local user's mailbox on the server.⁶ This involves writing the message data to the server's storage system according to the configured mailbox format, such as the traditional mbox format (where all messages in a folder are concatenated into a single file) or the more modern Maildir format (where each message is stored as a separate file).⁶ In addition to simple storage, MDAs may also perform final processing steps, such as filtering messages based on user-defined rules (e.g., sorting into specific folders) or running final anti-spam or anti-virus checks.¹⁶ Common examples of MDA software include Procmail (often used for filtering) and components within larger mail server suites like Dovecot (which also provides IMAP/POP3 access).³⁷ Once the MDA has successfully stored the email in the recipient's mailbox, the SMTP delivery process is complete. The message is now available for the recipient to access using their MUA via POP3 or IMAP protocols.⁶

It is important to recognize that while MUA, MSA, MTA, and MDA represent distinct logical functions within the email ecosystem, they are not always implemented as entirely separate software packages or running on different physical servers.⁶ For instance, a single mail server software suite like Postfix or Microsoft Exchange might perform the roles of MSA (listening on port 587 for authenticated submissions), MTA (relaying mail on port 25 and receiving incoming mail), and even MDA (delivering to local mailboxes or integrating with a separate MDA like Dovecot).⁶ Similarly, webmail providers like Gmail integrate the MUA (web interface) tightly with their backend MSA, MTA, and MDA infrastructure.²⁷ Sometimes the term MTA is used more broadly to encompass the functions of MSA and MDA as well.¹¹ Despite this potential consolidation in implementation, understanding the distinct functional roles is crucial for analyzing email flow, identifying potential points of failure, and implementing security measures effectively. The conceptual separation, particularly between authenticated submission (MSA) and inter-server relay (MTA), remains a cornerstone of secure email architecture.

IV. The SMTP Command Language

A. Protocol Interaction: Commands and Replies

The communication between an SMTP client and an SMTP server is governed by a structured dialogue based on text commands and numeric replies.² The client, which could be an MUA submitting mail, an MSA authenticating a client, or an MTA relaying mail, initiates actions by sending specific commands to the server.² These commands are typically short, human-readable ASCII strings, often four letters long (e.g., HELO, MAIL, RCPT, DATA), sometimes followed by parameters or arguments.²

The server, in turn, responds to each command with a three-digit numeric status code, usually accompanied by explanatory text.⁵ These codes are critical as they indicate the outcome of the command and guide the client's subsequent actions. The first digit of the code signifies the general status:

• 2xx (Positive Completion): The requested action was successfully completed. The client can proceed to the next command in the sequence.⁷ Examples: 220 Service ready, 250 OK, 235 Authentication successful.

• 3xx (Positive Intermediate): The command was accepted, but further information or action is required from the client to complete the request.⁶ Example: 354 Start mail input after the DATA command.

• 4xx (Transient Negative Completion): The command failed, but the failure is considered temporary. The server was unable to complete the action at this time, but the client should attempt the command again later.¹⁶ Example: 421 Service not available, 451 Requested action aborted: local error in processing.

• 5xx (Permanent Negative Completion): The command failed permanently. The server cannot or will not complete the action, and the client should not retry the same command.¹⁶ Example: 500 Syntax error, 550 Requested action not taken: mailbox unavailable, 535 Authentication credentials invalid.

This explicit command-response structure, coupled with standardized numeric codes defined in the relevant RFCs, provides a robust framework for email transfer. It ensures that both client and server have a clear understanding of the state of the transaction at each step. The unambiguous status codes allow clients to handle errors gracefully, for instance, by retrying delivery attempts in case of temporary failures (4xx codes) or by generating Non-Delivery Reports (NDRs) and aborting the attempt in case of permanent failures (5xx codes).³⁹ Furthermore, the text-based nature of the protocol allows for manual interaction and debugging using tools like Telnet, which can be invaluable for diagnosing connectivity and protocol issues.⁸ This structured dialogue is fundamental to SMTP's historical success and continued reliability in the face of network uncertainties.

B. Essential Transaction Commands: HELO/EHLO, MAIL FROM, RCPT TO, DATA, QUIT

A standard SMTP email transaction relies on a core set of commands exchanged in a specific sequence. These essential commands orchestrate the identification, envelope definition, data transfer, and termination phases of the session.

• HELO / EHLO (Hello): This is the mandatory first command sent by the client after establishing the TCP connection.² It serves as a greeting and identifies the client system to the server, typically providing the client's fully qualified domain name or IP address as an argument (e.g., HELO client.example.com).²⁶ HELO is the original command from RFC 821. EHLO (Extended HELO) was introduced with ESMTP (Extended SMTP) and is the preferred command for modern clients.² When a server receives EHLO, it responds not only with a success code but also with a list of the ESMTP extensions it supports (e.g., AUTH for authentication, STARTTLS for encryption, SIZE for message size limits, PIPELINING for sending multiple commands without waiting for individual replies).³⁶ This allows the client to discover server capabilities and utilize advanced features if available.

• MAIL FROM: This command initiates a new mail transaction within the established session and specifies the sender's email address for the SMTP envelope.² The address provided (e.g., MAIL FROM:<[e-mail]>) is known as the envelope sender, return-path, reverse-path, or RFC5321.MailFrom.⁶ This address is critically important because it is used by receiving systems to send bounce messages (NDRs) if the email cannot be delivered.⁶

• RCPT TO: Following a successful MAIL FROM command, the client uses RCPT TO to specify the email address of an intended recipient.² This address constitutes the envelope recipient address, or RFC5321.RcptTo.¹³ If the email is intended for multiple recipients, the client issues the RCPT TO command repeatedly, once for each recipient address (e.g., RCPT TO:<[e-mail]>, RCPT TO:<[e-mail]>).² The server responds to each RCPT TO command individually, confirming whether it can accept mail for that specific recipient.

• DATA: Once the sender and at least one valid recipient have been specified via MAIL FROM and RCPT TO, the client sends the DATA command to indicate it is ready to transmit the actual content of the email message.² The server, if ready to receive the message, responds with a positive intermediate reply, typically 354 Start mail input; end with <CRLF>.<CRLF>.⁶ The client then sends the message content, which comprises the RFC 5322 headers (like From:, To:, Subject:) followed by a blank line and the message body. The transmission of the message content is terminated by sending a single line containing only a period (.).²

• QUIT: After the message data has been transferred (and acknowledged by the server with a 250 OK status) or if the client wishes to end the session for other reasons, it sends the QUIT command.² This command requests the graceful termination of the SMTP session. The server responds with a final positive completion reply (e.g., 221 Service closing transmission channel) and then closes the TCP connection.¹⁸

These five commands form the backbone of nearly every SMTP transaction, facilitating the reliable transfer of email messages across the internet.

Command	Purpose	Typical Usage / Example
HELO/EHLO	Initiate session, identify client, query extensions	EHLO client.domain.com
MAIL FROM	Specify envelope sender (return path)	MAIL FROM:<[e-mail]>
RCPT TO	Specify envelope recipient(s)	RCPT TO:<[e-mail]> (can be repeated)
DATA	Signal start of message content transfer	DATA (followed by headers, blank line, body, and . on a line by itself)
QUIT	Terminate the SMTP session	QUIT

C. Auxiliary and Deprecated Commands: RSET, VRFY, EXPN

Beyond the essential transaction commands, SMTP includes auxiliary commands for session management and, historically, for address verification, though some of these are now deprecated due to security concerns.

• RSET (Reset): This command allows the client to abort the current mail transaction without closing the SMTP connection.² When issued, it instructs the server to discard any state information accumulated since the last HELO/EHLO command, including the sender address specified by MAIL FROM and any recipient addresses specified by RCPT TO. The connection remains open, and the client can initiate a new transaction, typically starting again with MAIL FROM (or potentially another EHLO/HELO if needed). This is useful if the client detects an error in the information it has sent (e.g., an incorrect recipient) and needs to start the transaction over.²

• VRFY (Verify): This command was originally intended to allow a client to ask the server whether a given username or email address corresponds to a valid mailbox on the local server.¹⁴ For example, VRFY <username>. If the user existed, the server might respond with the user's full name and mailbox details.⁴⁶

• EXPN (Expand): Similar to VRFY, the EXPN command was designed to ask the server to expand a mailing list alias specified in the argument.¹⁴ If the alias was valid, the server would respond with the list of email addresses belonging to that list.⁴⁶

However, both VRFY and EXPN proved to be significant security vulnerabilities.⁴⁶ Spammers and other malicious actors quickly realized they could use these commands to perform reconnaissance: VRFY allowed them to easily validate lists of potential email addresses without actually sending mail, and EXPN provided a way to harvest large numbers of valid addresses from internal mailing lists.⁴ This information disclosure facilitated targeted spamming and phishing attacks.⁴⁶

Due to this widespread abuse, the email community and standards bodies (e.g., RFC 2505) strongly recommended disabling or severely restricting these commands on public-facing mail servers.⁴⁹ Consequently, most modern MTA configurations disable VRFY and EXPN by default.⁴⁹ When queried, they might return a non-committal success code like 252 Argument not checked, effectively providing no useful information, or simply return an error indicating the command is not supported.⁵⁰ While potentially useful for internal diagnostics in controlled environments, enabling VRFY and EXPN on internet-accessible servers is now considered a serious security misconfiguration.⁴⁷

This shift away from supporting VRFY and EXPN illustrates a critical aspect of internet protocol evolution: features designed with benign intent can become dangerous liabilities in an adversarial environment. The practical response—disabling these commands—demonstrates the community's adaptation of SMTP practices to mitigate emerging security threats, prioritizing security over the originally intended functionality in this case.

Other less common or specialized SMTP commands include NOOP (No Operation), which does nothing except elicit an OK response (250 OK) from the server, often used as a keep-alive or to check connection status ⁴⁶, and HELP, which requests information about supported commands.⁴ Numerous other commands are defined as part of various ESMTP extensions, enabling features beyond the basic protocol.⁴⁶

V. Navigating SMTP Ports and Encryption

SMTP communication relies on standardized TCP ports to establish connections between clients and servers. The choice of port often dictates the expected security mechanisms and the role of the connection (submission vs. relay).

A. Standard Network Ports: 25, 587, 465

Three primary TCP ports are commonly associated with SMTP traffic ⁵:

• Port 25: This is the original and oldest port assigned for SMTP, as defined in the initial standards.⁴ Its primary intended purpose in modern email architecture is for mail relay, meaning the communication between different Mail Transfer Agents (MTAs) as email traverses the internet from the sender's infrastructure to the recipient's.⁵ While historically also used for client submission (MUA to server), this practice is now strongly discouraged due to security implications and widespread ISP blocking.⁵

• Port 587: This port is officially designated by IANA and relevant RFCs (e.g., RFC 6409) as the standard port for mail submission.⁵ It is intended for use when an email client (MUA) connects to its outgoing mail server (MSA) to send a message. Connections on port 587 typically require sender authentication (SMTP AUTH) and are expected to use opportunistic encryption via the STARTTLS command (Explicit TLS).⁵

• Port 465: This port was initially assigned by IANA for SMTPS (SMTP over SSL), providing an implicit TLS/SSL connection where encryption is established immediately upon connection, before any SMTP commands are exchanged.³ Although it was later deprecated by the IETF in favor of STARTTLS on port 587, its widespread implementation and use, particularly for client submission requiring guaranteed encryption, led to its continued prevalence.⁵ Recognizing this reality, RFC 8314 formally re-established port 465 as a legitimate port for SMTP submission using implicit TLS.⁶ Like port 587, it requires authentication.

Additionally, port 2525 is sometimes used as an unofficial alternative submission port, often configured by hosting providers or ESPs as a fallback if port 587 is blocked by an ISP.⁵ It typically operates similarly to port 587, expecting STARTTLS and authentication.

B. Evolution and Context of Port Usage

The existence of multiple ports for SMTP reflects the protocol's evolution and the changing security landscape of the internet. Port 25, established in 1982, was designed in an era where network security was less of a concern.⁴ It operated primarily in plaintext and often allowed unauthenticated relaying.⁴ This openness was exploited heavily by spammers, who used misconfigured or open relays on port 25 to distribute vast amounts of unsolicited email.⁵

As a countermeasure, many Internet Service Providers (ISPs) began blocking outbound connections on port 25 originating from their residential customer networks, aiming to prevent compromised home computers (bots) from sending spam directly.⁵ This blocking made port 25 unreliable for legitimate users needing to submit email from their clients.

To address the need for secure submission and bypass port 25 blocking, ports 465 and 587 emerged. Port 465 was assigned in 1997 specifically for SMTP over SSL (implicit encryption).⁵ Port 587 was designated later (standardized in RFC 2476, updated by RFC 6409) explicitly for the message submission function, separating it logically and operationally from the message relay function (which remained primarily on port 25).⁶ Port 587 was designed to work with the STARTTLS command for opportunistic encryption and to mandate SMTP authentication.⁵

For a period, the IETF favored the STARTTLS approach on port 587 and deprecated port 465.⁷ However, the simplicity and guaranteed encryption of the implicit TLS model on port 465 ensured its continued widespread use. RFC 8314 eventually acknowledged this practical reality and formally recognized port 465 for implicit TLS submission alongside port 587 for STARTTLS submission.⁶

Therefore, the current best practice distinguishes between:

• Submission (MUA to MSA): Use port 587 (with STARTTLS) or port 465 (Implicit TLS), both requiring authentication.

• Relay (MTA to MTA): Primarily use port 25, which may optionally support STARTTLS between cooperating servers.

C. Securing Connections: Plaintext, STARTTLS (Explicit TLS), and SMTPS (Implicit TLS/SSL)

SMTP connections can operate with varying levels of security, primarily differing in how encryption is applied:

• Plaintext: All communication between the client and server occurs unencrypted. This was the default for early SMTP on port 25.⁵ It is highly insecure, as all data, including SMTP commands, message content, and potentially authentication credentials (if using basic methods like PLAIN or LOGIN), can be easily intercepted and read by eavesdroppers on the network.⁴ Plaintext communication should be avoided whenever possible, especially for submission involving authentication.

• STARTTLS (Explicit TLS): This mechanism provides a way to upgrade an initially unencrypted connection to a secure, encrypted one. It is the standard method used on port 587 and is sometimes available on port 25.⁵ The process works as follows:

  1. The client establishes a standard TCP connection to the server (e.g., on port 587).

  2. After the initial EHLO exchange, if the server advertises STARTTLS capability, the client sends the STARTTLS command.³⁶

  3. If the server agrees, it responds positively, and both parties initiate a Transport Layer Security (TLS) or Secure Sockets Layer (SSL) handshake.⁵ TLS is the modern, more secure successor to SSL.³ Current standards recommend TLS 1.2 or TLS 1.3.³⁸

  4. If the handshake is successful, a secure, encrypted channel is established. All subsequent SMTP communication within that session, including authentication (AUTH) commands and message data (DATA), is protected by encryption, ensuring confidentiality and integrity.⁵

  5. If the server does not support STARTTLS, or if the TLS handshake fails, the connection might proceed in plaintext (if allowed by policy) or be terminated.⁵ This flexibility allows for "opportunistic encryption" but requires careful configuration to ensure security.

• SMTPS (Implicit TLS/SSL): This method, associated with port 465, establishes an encrypted connection from the very beginning.³ Unlike STARTTLS, there is no initial plaintext phase. The TLS/SSL handshake occurs immediately after the underlying TCP connection is made, before any SMTP commands (like EHLO) are exchanged.⁵ If the secure handshake cannot be successfully completed, the connection fails, and no SMTP communication takes place.⁵ This ensures that the entire SMTP session, including the initial greeting and all subsequent commands and data, is encrypted. While originally associated with the older SSL protocol, modern implementations on port 465 use current TLS versions.³

The existence of both explicit (STARTTLS) and implicit (SMTPS) TLS mechanisms reflects different design philosophies and historical development. Implicit TLS on port 465 offers simplicity and guarantees encryption if the connection succeeds, making it immune to certain "protocol downgrade" or "STARTTLS stripping" attacks where an attacker might try to prevent the upgrade to TLS in the explicit model. STARTTLS on port 587 provides flexibility, allowing a single port to potentially handle both secure and (less ideally) insecure connections, and aligns with the negotiation philosophy common in other internet protocols. Both methods are considered secure for client submission when implemented correctly using strong TLS versions (TLS 1.2+) and appropriate cipher suites.³⁸ The choice often depends on client and server compatibility and administrative preference.

Table: SMTP Port Comparison

Port	Common Use	Default Security Method	Key Considerations
25	MTA-to-MTA Relay	Plaintext (STARTTLS optional)	Often blocked by ISPs for client use; Primarily for server-to-server communication
587	MUA-to-MSA Submission	STARTTLS (Explicit TLS)	Recommended standard for submission; Requires authentication (SMTP AUTH)
465	MUA-to-MSA Submission	Implicit TLS/SSL (SMTPS)	Widely used alternative for submission; Requires authentication; Encrypted from start
2525	MUA-to-MSA Submission	STARTTLS (usually)	Non-standard alternative to 587; Used if 587 is blocked

VI. SMTP Security Practices and Extensions

While SMTP itself was initially designed without robust security features, numerous extensions and related technologies have been developed to address modern threats like unauthorized relaying (spam), eavesdropping, message tampering, and sender address spoofing (phishing).

A. Authenticating Senders: SMTP AUTH

SMTP Authentication, commonly referred to as SMTP AUTH, is a crucial extension to the SMTP protocol (specifically, ESMTP) defined in RFC 4954.³⁶ Its primary purpose is to allow an SMTP client, typically an MUA submitting an email, to verify its identity to the mail server (specifically, the MSA) before being granted permission to send or relay messages.⁵

By requiring authentication, SMTP AUTH prevents unauthorized users or automated systems (like spambots) from exploiting the server as an "open relay" to send unsolicited or malicious emails, thereby protecting the server's reputation and resources.⁵ It ensures that only legitimate, registered users can utilize the server's outgoing mail services.³⁵

The authentication process typically occurs early in the SMTP session, after the initial EHLO command and, importantly, usually after the connection has been secured using STARTTLS (on port 587) or is implicitly secured (on port 465).³⁶ Securing the connection first is vital to protect the authentication credentials themselves from eavesdropping, especially when using simpler authentication mechanisms.¹⁹

The server indicates its support for SMTP AUTH and lists the specific authentication mechanisms it accepts in its response to the client's EHLO command (e.g., 250 AUTH LOGIN PLAIN CRAM-MD5).²⁰ The client then initiates the authentication process by issuing the AUTH command, followed by the chosen mechanism name and any required credential data, encoded or processed according to the rules of that specific mechanism.¹⁵ A successful authentication attempt is typically confirmed by the server with a 235 Authentication successful response, after which the client can proceed with the MAIL FROM command.²⁰ A failed attempt usually results in a 535 Authentication credentials invalid or similar error, preventing the client from sending mail through the server.²⁰ SMTP AUTH is essentially mandatory for using the standard submission ports 587 and 465.²⁰

1. Authentication Mechanisms Explained (PLAIN, LOGIN, CRAM-MD5, OAuth, etc.)

SMTP AUTH leverages the Simple Authentication and Security Layer (SASL) framework, which defines various mechanisms for authentication. Common mechanisms supported by SMTP servers include:

• PLAIN: This is one of the simplest mechanisms. The client sends the authorization identity (optional, often null), the authentication identity (username), and the password, all concatenated with null bytes (\0) and then Base64 encoded, in a single step following the AUTH PLAIN command or in response to a server challenge.¹⁹ While easy to implement, it transmits credentials in a form that is trivially decoded from Base64. Therefore, it is only secure when used over an already encrypted connection (TLS/SSL).¹⁹

• LOGIN: Similar to PLAIN in its security level, LOGIN uses a two-step challenge-response process. After the client sends AUTH LOGIN, the server prompts for the username (with a Base64 encoded challenge "Username:"). The client responds with the Base64 encoded username. The server then prompts for the password (with Base64 encoded "Password:"), and the client responds with the Base64 encoded password.¹⁹ Like PLAIN, LOGIN is only secure when protected by TLS/SSL.¹⁹

• CRAM-MD5 (Challenge-Response Authentication Mechanism using MD5): This mechanism offers improved security over unencrypted channels compared to PLAIN or LOGIN. The server sends a unique, timestamped challenge string to the client. The client computes an HMAC-MD5 hash using the password as the key and the server's challenge string as the message. The client then sends back its username and the resulting hexadecimal digest, Base64 encoded.¹⁹ The server performs the same calculation using its stored password information. If the digests match, authentication succeeds. This avoids transmitting the password itself, even in encoded form.⁴⁰ However, it requires the server to store password-equivalent data, and MD5 itself is considered cryptographically weak by modern standards.³⁶

• DIGEST-MD5: Another challenge-response mechanism, considered more secure than CRAM-MD5 but also more complex.³⁵ It also aims to avoid sending the password directly.

• NTLM / GSSAPI (Kerberos): These mechanisms are often used within Microsoft Windows environments, particularly with Microsoft Exchange Server, to provide integrated authentication.¹⁴ GSSAPI typically leverages Kerberos. NTLM is another Windows-specific challenge-response protocol.²⁰ These can sometimes allow authentication using the current logged-in Windows user's credentials.⁵³

• OAuth 2.0: This is a modern, token-based authorization framework increasingly used by major email providers like Google (Gmail) and Microsoft (Office 365/Exchange Online) for authenticating client applications, including MUAs connecting via SMTP.¹⁹ Instead of the client handling the user's password directly, the user authenticates with the provider (often via a web flow) and authorizes the client application. The application then receives a short-lived access token, which it uses for authentication with the SMTP server (often via SASL mechanisms like OAUTHBEARER or XOAUTH2).²⁰ This approach is generally considered more secure because it avoids storing or transmitting user passwords, allows for finer-grained permissions, and enables easier credential revocation.¹⁹ It is often the recommended method when available.¹⁹

The diversity of these mechanisms reflects the broader evolution of authentication technologies. Early methods prioritized simplicity but relied heavily on transport-level encryption (TLS). Challenge-response mechanisms attempted to add security even without TLS but have limitations. Integrated methods served specific enterprise ecosystems. OAuth 2.0 represents the current best practice, aligning with modern security principles by minimizing password handling. When configuring SMTP clients or servers, it is crucial to select the most secure mechanism supported by both ends, prioritizing OAuth 2.0, then strong challenge-response mechanisms, and only using PLAIN or LOGIN when strictly enforced over a mandatory TLS connection.⁵⁴

B. Mitigating Spam and Phishing

While SMTP AUTH authenticates the client submitting the email to the initial server, it does not inherently verify that the email content, particularly the user-visible "From" address, is legitimate or that the sending infrastructure is authorized by the domain owner. To combat the pervasive problems of email spam, sender address spoofing (where an attacker fakes the "From" address), and phishing attacks, a suite of complementary authentication technologies operating at the domain level has become essential.⁴ The three core components of this framework are SPF, DKIM, and DMARC.¹⁷

1. Sender Policy Framework (SPF)

SPF allows a domain owner to specify which IP addresses are authorized to send email on behalf of that domain.¹⁷ This policy is published as a TXT record in the domain's DNS.⁵⁶ When a receiving mail server gets an incoming connection from an IP address attempting to send an email, it performs the following check:

1. It looks at the domain name provided in the SMTP envelope sender address (the MAIL FROM command, also known as the RFC5321.MailFrom or return-path address).¹⁷

2. It queries the DNS for the SPF (TXT) record associated with that domain.

3. It evaluates the SPF record's policy against the connecting IP address. The record contains mechanisms (like ip4:, ip6:, a:, mx:, include:) to define authorized senders.

4. If the connecting IP address matches one of the authorized sources defined in the SPF record, the SPF check passes.

5. If the IP address does not match, the SPF check fails. The SPF record can also specify a qualifier (-all for hard fail, ~all for soft fail, ?all for neutral) that suggests how the receiver should treat failing messages (e.g., reject, mark as spam, or take no action).⁶²

SPF primarily helps prevent spammers from forging the envelope sender address using unauthorized IP addresses.⁵⁶ However, it doesn't directly validate the user-visible From: header address, nor does it protect against message content modification.

2. DomainKeys Identified Mail (DKIM)

DKIM provides a mechanism for verifying the authenticity of the sending domain and ensuring that the message content has not been tampered with during transit.¹⁷ It employs public-key cryptography:

1. The sending mail system (MTA or ESP) generates a cryptographic signature based on selected parts of the email message, including key headers (like From:, To:, Subject:) and the message body.⁵⁷ This signature is created using a private key associated with the sending domain.

2. The signature, along with information about how it was generated (e.g., the domain used for signing (d=), the selector (s=) identifying the specific key pair), is added to the email as a DKIM-Signature: header field.⁵⁶

3. The corresponding public key is published in the domain's DNS as a TXT record, located at <selector>._domainkey.<domain>.⁵⁶

4. When a receiving server gets the email, it extracts the domain and selector from the DKIM-Signature: header, queries DNS for the public key, and uses that key to verify the signature against the received message content.⁵⁶

A successful DKIM verification provides strong assurance that the email was indeed authorized by the domain listed in the signature (d= tag) and that the signed parts of the message have not been altered since signing.⁵⁶ DKIM directly authenticates the domain associated with the signature and protects message integrity, complementing SPF's IP-based validation.¹⁷

3. Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC acts as an overarching policy layer that leverages both SPF and DKIM, adding crucial alignment checks and reporting capabilities.¹⁷ It allows domain owners to tell receiving mail servers how to handle emails that claim to be from their domain but fail authentication checks. DMARC is also published as a TXT record in DNS, typically at _dmarc.<domain>.⁵⁶

DMARC introduces two key concepts:

1. Alignment: DMARC requires not only that SPF or DKIM passes, but also that the domain validated by the passing mechanism aligns with the domain found in the user-visible From: header (RFC5322.From).⁵⁹ For SPF alignment, the RFC5321.MailFrom domain must match the RFC5322.From domain. For DKIM alignment, the domain in the DKIM signature's d= tag must match the RFC5322.From domain. This alignment check is critical because it directly addresses the common spoofing tactic where an email might pass SPF or DKIM for a legitimate sending service's domain, but the From: header shows the victim's domain. DMARC ensures the authenticated domain matches the claimed sender domain.

2. Policy and Reporting: The DMARC record specifies a policy (p=) that instructs receivers on what action to take if a message fails the DMARC check (i.e., fails both SPF and DKIM, or passes but fails alignment). The policies are:

   • p=none: Monitor mode. Take no action based on DMARC failure, just collect data and send reports. Used initially during deployment.⁵⁷

   • p=quarantine: Request receivers to treat failing messages as suspicious, typically by placing them in the spam/junk folder.⁵⁷

   • p=reject: Request receivers to block delivery of failing messages entirely.⁵⁷ DMARC also enables reporting through rua (aggregate reports) and ruf (forensic reports) tags in the record, allowing domain owners to receive feedback from receivers about authentication results, identify legitimate sending sources, and detect potential abuse or misconfigurations.⁵⁶

The combination of SPF, DKIM, and DMARC provides a layered defense against email spoofing and phishing. SPF validates the sending server's IP based on the envelope sender domain. DKIM validates message integrity and authenticates the signing domain, often aligning with the header From: domain. DMARC enforces alignment between these checks and the visible From: domain, providing policy instructions and reporting. This multi-faceted approach is necessary because of the fundamental separation between the SMTP envelope (RFC 5321), used for transport, and the message content headers (RFC 5322), displayed to the user.¹³ SPF primarily addresses the envelope, DKIM addresses the content, and DMARC bridges the gap by requiring alignment with the user-visible From: address, offering the most comprehensive protection against domain impersonation when implemented with an enforcement policy (quarantine or reject).⁵⁹ Major email providers like Google and Yahoo now mandate the use of SPF and DKIM, and often DMARC, for bulk senders to improve email security and deliverability.⁵⁷

C. Addressing Command Vulnerabilities (VRFY/EXPN)

As previously discussed in Section IV.C, the SMTP commands VRFY and EXPN represent historical vulnerabilities.⁴⁶ Their functions—verifying individual addresses and expanding mailing lists, respectively—provide mechanisms for attackers to harvest valid email addresses and map internal organizational structures without sending actual emails.¹⁴ This information significantly aids spammers and phishers in targeting their attacks.⁴⁶ Recognizing this severe security risk, the standard and best practice within the email administration community is to disable these commands on any internet-facing mail server.⁴⁹ Most modern MTA software (like Postfix and Sendmail) allows administrators to easily turn off support for VRFY and EXPN through configuration settings, and often ships with them disabled by default.⁴⁹ Responding with non-informative codes like 252 or error codes effectively mitigates the risk associated with these legacy commands.⁵⁰

Table: SMTP Authentication Mechanisms

Mechanism	Security Level	Description	Notes
PLAIN	Low (w/o TLS)	Sends authzid\0userid\0password as Base64 in one step.	Requires TLS for security. Simple. 19
LOGIN	Low (w/o TLS)	Server prompts for username and password separately; client sends each as Base64.	Requires TLS for security. Widely supported. 19
CRAM-MD5	Medium	Challenge-response using HMAC-MD5. Avoids sending password directly.	Better than PLAIN/LOGIN without TLS, but MD5 has weaknesses. Requires specific server storage. 19
DIGEST-MD5	Medium	More complex challenge-response mechanism.	Less common than CRAM-MD5. 35
NTLM/GSSAPI	Variable	Integrated Windows Authentication. Security depends on underlying mechanism (e.g., Kerberos).	Primarily for Windows/Exchange environments. 20
OAuth 2.0	High	Token-based authentication. Client gets temporary token instead of using password directly with SMTP server.	Modern standard, avoids password exposure, better permission control. 19

Table: Email Authentication Frameworks (SPF/DKIM/DMARC)

Framework	Purpose	Verification Method	DNS Record Type	Key Aspect Verified
SPF	Authorize sending IPs for envelope sender domain	Check connecting IP against list in DNS TXT record for RFC5321.MailFrom domain.	TXT	Sending Server IP Address (for envelope domain)
DKIM	Verify message integrity & signing domain	Verify cryptographic signature in header using public key from DNS TXT record.	TXT	Message Content Integrity & Signing Domain Authenticity
DMARC	Set policy for failures & enable reporting	Check SPF/DKIM pass & alignment with RFC5322.From domain; Apply policy from DNS TXT record.	TXT	Alignment of SPF/DKIM domain with From: header domain

VII. SMTP in Context: Sending vs. Receiving Protocols

A. Defining Boundaries: SMTP vs. POP3 and IMAP

It is crucial to reiterate the distinct roles played by SMTP, POP3, and IMAP within the internet email architecture. SMTP (Simple Mail Transfer Protocol) is exclusively responsible for the transmission or sending of email messages.² It functions as a "push" protocol, moving emails from the sender's client to their mail server, and then relaying those messages across the internet between mail servers until they reach the recipient's designated mail server.²

In contrast, POP3 (Post Office Protocol version 3) and IMAP (Internet Message Access Protocol) are retrieval protocols.² They operate as "pull" protocols, used by the recipient's email client (MUA) to connect to their mail server and access the emails stored within their mailbox.² SMTP's job ends once the email is delivered to the recipient's server; POP3 or IMAP then take over to allow the user to read and manage their mail. Therefore, when configuring an email client application, users typically need to provide settings for both the outgoing server (using SMTP) and the incoming server (using either POP3 or IMAP).²⁵

B. How SMTP Interacts with Retrieval Protocols

The interaction between SMTP and the retrieval protocols (POP3/IMAP) occurs at the recipient's mail server, specifically at the mailbox level. SMTP, via the final MTA and MDA in the delivery chain, places the incoming email message into the recipient's mailbox storage on the server.⁶ At this juncture, SMTP's involvement with that specific message concludes.

Subsequently, when the recipient launches their email client (MUA), the client establishes a connection to the mail server using the configured retrieval protocol—either POP3 or IMAP.² POP3 clients typically download all messages from the server to the local device, often deleting the server copies, while IMAP clients access and manage the messages directly on the server, synchronizing the state across multiple devices.²³ SMTP plays no role in this client-to-server retrieval process. It is purely the transport mechanism that gets the email to the server mailbox where POP3 or IMAP can then access it.

C. Comparative Analysis of Functionality (SMTP vs. POP3 vs. IMAP)

The three protocols differ significantly in their functionality, intended use cases, and operational characteristics:

• SMTP:

  • Function: Sending and relaying emails.³

  • Operation: Client-to-server (submission) and server-to-server (relay).⁶

  • Type: Push protocol.²

  • Ports: 25 (relay, usually plaintext/STARTTLS), 587 (submission, STARTTLS), 465 (submission, Implicit TLS).²⁸

  • Storage: Messages are typically transient on relay servers, only stored temporarily if forwarding is delayed.⁷

  • Key Feature: Reliable transport and delivery attempts across networks.²⁵

• POP3:

  • Function: Retrieving emails.⁵

  • Operation: Client-to-server.²³

  • Type: Pull protocol.²³

  • Ports: 110 (plaintext), 995 (Implicit TLS/SSL).²⁶

  • Storage: Downloads messages to the client device, usually deleting them from the server (default behavior).⁵

  • Key Features: Simple, good for single-device offline access, minimizes server storage usage.³⁰ Poor for multi-device synchronization.²³

• IMAP:

  • Function: Accessing and managing emails on the server.⁵

  • Operation: Client-to-server.²³

  • Type: Pull/Synchronization protocol.³²

  • Ports: 143 (plaintext), 993 (Implicit TLS/SSL).²⁶

  • Storage: Messages remain on the server; client typically caches copies. State (read/unread, folders) is synchronized.²²

  • Key Features: Excellent for multi-device access, server-side organization (folders), synchronized view across clients.²² Requires more server storage and reliable internet connectivity.²²

The choice between POP3 and IMAP for retrieval largely depends on user behavior and needs. In the early days of email, when users typically accessed mail from a single desktop computer, POP3's simple download-and-delete model was often sufficient and efficient in terms of server storage.²⁸ However, the modern proliferation of multiple devices per user (desktops, laptops, smartphones, tablets) and the rise of webmail interfaces have made synchronized access essential. IMAP, by keeping messages and their status centralized on the server and reflecting changes across all connected clients, directly addresses this need.²² Consequently, IMAP is generally the preferred retrieval protocol for most users today, offering a consistent experience across all their devices.²² POP3 remains a viable option primarily for users who access email from only one device, require extensive offline access, or have severe server storage limitations.²² Regardless of the retrieval protocol chosen (POP3 or IMAP), SMTP remains the indispensable standard for the initial sending and transport of the email message to the recipient's server.

Table: Protocol Comparison: SMTP vs. POP3 vs. IMAP

Feature	SMTP (Simple Mail Transfer Protocol)	POP3 (Post Office Protocol 3)	IMAP (Internet Message Access Protocol)
Primary Function	Sending / Relaying Email	Retrieving Email	Accessing / Managing Email on Server
Protocol Type	Push	Pull	Pull / Synchronization
Typical Ports	25 (relay), 587 (STARTTLS), 465 (Implicit TLS)	110 (plain), 995 (TLS/SSL)	143 (plain), 993 (TLS/SSL)
Message Storage	Transient during relay	Downloads to client (server copy usually deleted)	Stays on server
Multi-Device Use	N/A (Transport)	Poor (Not synchronized)	Excellent (Synchronized)
Key Feature	Transports email between servers	Simple download for single device	Server-side management, multi-device sync

VIII. Deconstructing the SMTP Message Format

A. The Dual Structure: Envelope (RFC 5321) and Content (RFC 5322)

A fundamental concept in understanding email transmission is the distinction between the SMTP envelope and the message content.² These two components serve different purposes and are governed by separate standards.

The SMTP envelope is defined by the Simple Mail Transfer Protocol itself, specified in RFC 5321.⁶ It comprises the information necessary for mail servers (MTAs) to route and deliver the email message through the network. This envelope information is established dynamically during the SMTP transaction through commands like MAIL FROM (which provides the envelope sender or return-path address, RFC5321.MailFrom) and RCPT TO (which provides the envelope recipient address(es), RFC5321.RcptTo).² Think of the SMTP envelope as the physical envelope used for postal mail: it contains the addresses needed by the postal system (the MTAs) to handle delivery and returns (bounces).¹³ This envelope information is generated during the transmission process and is generally not part of the final message content visible to the end recipient in their email client.² Once the message reaches its final destination MDA, the envelope information used for transport is effectively discarded.¹³

The message content, on the other hand, is the actual email message itself—the "letter" inside the envelope.¹³ Its format is defined by the Internet Message Format (IMF), specified in RFC 5322.¹³ This content is transmitted from the client to the server during the DATA phase of the SMTP transaction.⁶ The RFC 5322 message content is structured into two main parts: the message header and the message body, separated by a blank line.²

In summary, RFC 5321 governs the transport protocol (how the email is sent, the envelope), while RFC 5322 governs the format of the message being sent (the headers and body, the content).⁶ Both standards have evolved from their predecessors (RFC 821/822 from 1982, RFC 2821/2822 from 2001) to their current versions published in 2008.¹³

Recognizing this separation between the transport-level envelope (RFC 5321) and the message content (RFC 5322) is crucial for understanding many aspects of email functionality and security. For instance, the envelope sender address (MAIL FROM) used for routing and bounce handling ⁶ can legally differ from the From: address displayed in the message header, a fact often exploited in email spoofing.¹⁸ Email authentication mechanisms like SPF primarily validate the envelope sender domain against the sending IP ¹⁷, while DKIM signs parts of the message content, including the From: header.⁵⁷ DMARC then attempts to bridge this gap by requiring alignment between the authenticated domain (via SPF or DKIM) and the domain in the visible From: header.⁵⁹ Furthermore, informational headers like Received: trace the path taken by the envelope through MTAs but are added to the RFC 5322 message header ⁵, while the Return-Path: header, often added at final delivery, records the envelope sender address.¹³ Failure to distinguish these two layers leads to significant confusion about how email routing, bounces, and modern authentication protocols function.

B. Dissecting the Message Header (Key Fields and Purpose)

The message header, as defined by RFC 5322, is a series of structured lines appearing at the beginning of the email content, preceding the message body and separated from it by a blank line.⁶ Each header field follows a specific syntax: a field name (e.g., From, Subject), followed by a colon (:), and then the field's value or body.¹³ These headers contain metadata about the message, its originators, recipients, and its passage through the mail system. Key header fields include:

• Originator Fields:

  • From:: Specifies the mailbox(es) of the message author(s) (RFC5322.From). This is the address typically displayed as the sender in the recipient's email client.¹³ RFC 5322 implies it's usually mandatory, or requires a Sender: field if absent.¹⁸ The format often includes an optional display name followed by the email address enclosed in angle brackets (e.g., "Alice Example" <[e-mail]>).⁴¹

  • Sender:: Identifies the agent (mailbox) responsible for the actual transmission of the message, if different from the author listed in the From: field. Its use is less common in typical user-to-user mail.

  • Reply-To:: An optional field providing the preferred address(es) for recipients to use when replying to the message, overriding the From: address for reply purposes.¹³

• Destination Fields:

  • To:: Lists the primary recipient(s) of the message (RFC5322.To).¹³

  • Cc: (Carbon Copy): Lists secondary recipients who also receive a copy of the message.¹⁸ Addresses in To: and Cc: are visible to all recipients.

  • Bcc: (Blind Carbon Copy): Lists tertiary recipients whose addresses should not be visible to the primary (To:) or secondary (Cc:) recipients.¹⁸ Mail servers are responsible for removing the Bcc: header field itself (or its contents) before delivering the message to To: and Cc: recipients, ensuring the privacy of the Bcc'd addresses.¹⁸ The envelope (RCPT TO) commands must still include all Bcc recipients for delivery to occur.

• Identification and Informational Fields:

  • Message-ID:: Contains a globally unique identifier for this specific email message, typically generated by the originating MUA or MSA. Used for tracking and threading.

  • Date:: Specifies the date and time the message was composed and submitted by the originator. This field is mandatory.¹³

  • Subject:: Contains a short string describing the topic of the message, intended for display to the recipient.¹³

• Trace and Operational Fields: These are often added by mail servers (MTAs and MDAs) during transport and delivery, rather than by the original sender.

  • Received:: Each MTA that processes the message typically prepends a Received: header, recording its own identity, the identity of the machine it received the message from, the time of receipt, and other diagnostic information. A chain

Works cited

1. www.cloudflare.com, accessed April 9, 2025, https://www.cloudflare.com/learning/email-security/what-is-smtp/#:~:text=The%20Simple%20Mail%20Transfer%20Protocol%20(SMTP)%20is%20a%20technical%20standard,their%20underlying%20hardware%20or%20software.
2. What is the Simple Mail Transfer Protocol (SMTP)? | Cloudflare, accessed April 9, 2025, https://www.cloudflare.com/learning/email-security/what-is-smtp/
3. What Is SMTP? - SMTP Server Explained - AWS, accessed April 9, 2025, https://aws.amazon.com/what-is/smtp/
4. What is SMTP? Simple Mail Transfer Protocol Explained - Darktrace, accessed April 9, 2025, https://www.darktrace.com/es/cyber-ai-glossary/simple-mail-transfer-protocol-smtp
5. What is SMTP (Simple Mail Transfer Protocol) & SMTP Ports ..., accessed April 9, 2025, https://www.siteground.com/kb/what-is-smtp/
6. Simple Mail Transfer Protocol - Wikipedia, accessed April 9, 2025, https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
7. Simple Mail Transfer Protocol (SMTP) Explained [2025] - Mailtrap, accessed April 9, 2025, https://mailtrap.io/blog/smtp/
8. What is the Simple Mail Transfer Protocol (SMTP)? - HAProxy Technologies, accessed April 9, 2025, https://www.haproxy.com/glossary/what-is-the-simple-mail-transfer-protocol-smtp
9. SMTP (Simple Mail Transfer Protocol): Servers and Sending Emails - SendGrid, accessed April 9, 2025, https://sendgrid.com/en-us/blog/what-is-an-smtp-server
10. What is Simple Mail Transfer Protocol (SMTP)? A complete guide - Heyflow, accessed April 9, 2025, https://heyflow.com/blog/smtp-a-complete-guide/
11. Teach Me Email: What is SMTP? | SocketLabs, accessed April 9, 2025, https://www.socketlabs.com/blog/teach-me-email-what-is-smtp/
12. RFC 2821 - Simple Mail Transfer Protocol (SMTP) - IETF, accessed April 9, 2025, https://www.ietf.org/rfc/rfc2821.txt
13. Email address types explained - Mailhardener knowledge base, accessed April 9, 2025, https://www.mailhardener.com/kb/email-address-types-explained
14. Pentest - Everything SMTP – LuemmelSec – Just an admin on someone else´s computer, accessed April 9, 2025, https://luemmelsec.github.io/Pentest-Everything-SMTP/
15. Send Emails using SMTP: Tutorial with Code Snippets [2025] - Mailtrap, accessed April 9, 2025, https://mailtrap.io/blog/smtp-send-email/
16. How does email work: MUA, MSA, MTA, MDA, MRA, accessed April 9, 2025, https://oxilor.com/blog/how-does-email-work
17. RFC 5321 and RFC 5322 - Understand DKIM and SPF - Easy365Manager, accessed April 9, 2025, https://www.easy365manager.com/rfc-5321-and-rfc-5322/
18. SMTP protocol and e-mail addresses - SAMURAJ-cz.com, accessed April 9, 2025, https://www.samuraj-cz.com/en/article/smtp-protocol-and-e-mail-addresses/
19. SMTP Authentication & Security: How to Protect Your Email Program - SendGrid, accessed April 9, 2025, https://sendgrid.com/en-us/blog/smtp-security-and-authentication
20. SMTP Authentication - Its Significance and Usage - MailSlurp, accessed April 9, 2025, https://www.mailslurp.com/blog/smtp-authentication/
21. Differences Between SMTP, IMAP, and POP3 - Sekur, accessed April 9, 2025, https://sekur.com/blog/differences-between-smtp-imap-and-pop3/
22. POP3 vs. IMAP vs. SMTP: Uncovering the Key Distinctions - Folderly, accessed April 9, 2025, https://folderly.com/blog/imap-vs-smtp-vs-pop3
23. Difference Between SMTP, IMAP, And POP3 (With Comparisons) - SalesBlink, accessed April 9, 2025, https://salesblink.io/blog/difference-between-smtp-imap-pop3
24. Everything you need to know about SMTP (Simple Mail Transfer ..., accessed April 9, 2025, https://postmarkapp.com/guides/everything-you-need-to-know-about-smtp
25. A Step-by-Step Guide to Use an SMTP Server as Your Email Sending Service | SMTPProvider.com, accessed April 9, 2025, https://smtpprovider.com/a-step-by-step-guide-to-use-an-smtp-server-as-your-email-sending-service/
26. An Introduction to Internet E-Mail - wooledge.org, accessed April 9, 2025, https://wooledge.org/~greg/mail.html
27. Understanding Email. How Email Works | Medium - Sudip Dutta, accessed April 9, 2025, https://kh4lnay4k.medium.com/understanding-e-mail-84621bb97949
28. What are Email Protocols (POP3, SMTP and IMAP) and their default ports? - SiteGround, accessed April 9, 2025, https://www.siteground.com/tutorials/email/protocols-pop3-smtp-imap/
29. IMAP vs POP3 vs SMTP - The Ultimate Comparison - Courier, accessed April 9, 2025, https://www.courier.com/guides/imap-vs-pop3-vs-smtp
30. IMAP vs POP3 vs SMTP - Choosing the Right Email Protocol Ultimate Guide - SuprSend, accessed April 9, 2025, https://www.suprsend.com/post/imap-vs-pop3-vs-smtp-choosing-the-right-email-protocol-ultimate-guide
31. IMAP vs POP3 vs SMTP - A Comprehensive Guide for Choosing the Right Email Protocol, accessed April 9, 2025, https://dev.to/nikl/imap-vs-pop3-vs-smtp-a-comprehensive-guide-for-choosing-the-right-email-protocol-33m7
32. IMAP vs. POP3 vs. SMTP: What Are the Differences? - phoenixNAP, accessed April 9, 2025, https://phoenixnap.com/kb/imap-vs-pop3-vs-smtp
33. Learn The Basics Of How SMTP Works With A Simple SMTP Server Example - DuoCircle, accessed April 9, 2025, https://www.duocircle.com/content/smtp-email/smtp-server-example
34. What protocols and servers are involved in sending an email, and what are the steps?, accessed April 9, 2025, https://stackoverflow.com/questions/32744/what-protocols-and-servers-are-involved-in-sending-an-email-and-what-are-the-st
35. What is SMTP authentication? SMTP Auth explained - IONOS, accessed April 9, 2025, https://www.ionos.com/digitalguide/e-mail/technical-matters/smtp-auth/
36. How exactly does SMTP authentication work? - Server Fault, accessed April 9, 2025, https://serverfault.com/questions/1050393/how-exactly-does-smtp-authentication-work
37. The Fundamentals of SMTP: how it works and why it is important. - MailSlurp, accessed April 9, 2025, https://www.mailslurp.com/blog/smtp/
38. How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Learn, accessed April 9, 2025, https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365
39. Difference between envelope and header from - Xeams, accessed April 9, 2025, https://www.xeams.com/difference-envelope-header.htm
40. AUTH Command and its Mechanisms (PLAIN, LOGIN, CRAM-MD5) - SMTP Commands Reference - SamLogic, accessed April 9, 2025, https://www.samlogic.net/articles/smtp-commands-reference-auth.htm
41. How EOP validates the From address to prevent phishing - Microsoft Defender for Office 365, accessed April 9, 2025, https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-from-email-address-validation
42. How to Send an SMTP Email | SendGrid Docs - Twilio, accessed April 9, 2025, https://www.twilio.com/docs/sendgrid/for-developers/sending-email/getting-started-smtp
43. Email Infrastructure Explained [2025] - Mailtrap, accessed April 9, 2025, https://mailtrap.io/blog/email-infrastructure/
44. What is a Mail Transfer Agent (MTA)? A Complete Guide - Smartlead, accessed April 9, 2025, https://www.smartlead.ai/blog/mail-transfer-agent-guide
45. Anatomy of Email - Internet Stuff, accessed April 9, 2025, https://kanatzidis.com/2020/11/22/anatomy-of-email.html
46. SMTP Commands and Response Codes List - MailSlurp, accessed April 9, 2025, https://www.mailslurp.com/blog/smtp-commands-and-responses/
47. SMTP Commands and Response Codes Guide | Mailtrap Blog, accessed April 9, 2025, https://mailtrap.io/blog/smtp-commands-and-responses/
48. Everything you need to know about mail servers - MonoVM, accessed April 9, 2025, https://monovm.com/blog/what-is-mail-server/
49. Securing Mail Servers: Disabling the EXPN and VRFY Commands, accessed April 9, 2025, https://www.criticalpathsecurity.com/securing-mailservers-disabling-the-expn-and-vrfy-commands/
50. Whatever happened to VRFY? - Spam Resource, accessed April 9, 2025, https://www.spamresource.com/2007/01/whatever-happened-to-vrfy.html
51. Question - PCI compliance - Postfix EXPN/VRFY issue - Plesk Forum, accessed April 9, 2025, https://talk.plesk.com/threads/pci-compliance-postfix-expn-vrfy-issue.376022/
52. CVE-1999-0531 - Alert Detail - Security Database, accessed April 9, 2025, https://www.security-database.com/detail.php?alert=CVE-1999-0531
53. SMTP authentication in detail - AfterLogic, accessed April 9, 2025, https://afterlogic.com/mailbee-net/docs/smtp_authentication.html
54. SMTP AUTH Mechanisms Explained Choosing the Right Authentication for Secure Email Sending - Warmy Blog, accessed April 9, 2025, https://blog.warmy.io/blog/smtp-auth-mechanisms-explained-choosing-the-right-authentication-for-secure-email-sending/
55. Enable or disable SMTP AUTH in Exchange Online - Learn Microsoft, accessed April 9, 2025, https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission
56. SPF vs. DKIM vs. DMARC: A Guide - Mimecast, accessed April 9, 2025, https://www.mimecast.com/content/dkim-spf-dmarc-explained/
57. SPF, DKIM, DMARC: The 3 Pillars of Email Authentication | Higher Logic, accessed April 9, 2025, https://www.higherlogic.com/blog/spf-dkim-dmarc-email-authentication/
58. What are DMARC, DKIM, and SPF? - Cloudflare, accessed April 9, 2025, https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/
59. DMARC, DKIM, & SPF explained (email authentication 101) - Valimail, accessed April 9, 2025, https://www.valimail.com/blog/dmarc-dkim-spf-explained/
60. How do you send emails (SMTP) from your server? I feel like this should be easier to set up. - Reddit, accessed April 9, 2025, https://www.reddit.com/r/selfhosted/comments/bqksu4/how_do_you_send_emails_smtp_from_your_server_i/
61. SPF, DKIM, DMARC explained [Infographic] - InboxAlly, accessed April 9, 2025, https://www.inboxally.com/blog/spf-dkim-dmarc-explained-infographic
62. Understanding SPF, DKIM, and DMARC: A Simple Guide - GitHub, accessed April 9, 2025, https://github.com/nicanorflavier/spf-dkim-dmarc-simplified
63. Can someone explain DMARC, SPF, and DKIM to me like I'm 5? : r/sysadmin - Reddit, accessed April 9, 2025, https://www.reddit.com/r/sysadmin/comments/16gvtdj/can_someone_explain_dmarc_spf_and_dkim_to_me_like/
64. Fortifying Digital Communications: A Comprehensive Guide to SPF, DKIM, DMARC, and DNSSEC - Medium, accessed April 9, 2025, https://medium.com/it-security-in-plain-english/fortifying-digital-communications-a-comprehensive-guide-to-spf-dkim-dmarc-and-dnssec-136d8d1a2390
65. Email messages: header section of an email-message, email-message envelope, email-message body and SMTP - Stack Overflow, accessed April 9, 2025, https://stackoverflow.com/questions/64497251/email-messages-header-section-of-an-email-message-email-message-envelope-emai

RFC 5322 - Internet Message Format - IETF Datatracker, accessed April 9, 2025, https://datatracker.ietf.org/doc/html/rfc5322