13.3 SMTP

Overview

Simple Mail Transfer Protocol, or SMTP, is the standard protocol used to send email between systems on IP networks. It defines how email is submitted from a mail client to a mail server, and how mail servers relay messages to each other until they reach the recipient’s mail server. SMTP focuses on the act of sending and transferring messages, not on how users later read or download them. Reading and mailbox access belongs to other protocols from this section.

SMTP operates at the application layer and assumes that lower layers provide a reliable connection, typically through TCP. It defines a text based command and response conversation between an SMTP client and an SMTP server. In most cases, your device or mail program acts as an SMTP client when sending, and a dedicated mail server acts as the SMTP server.

Role of SMTP in Email Flow

In a typical email journey, SMTP is used in two main steps. First, when you press “Send” in your mail client, the message is handed off to an SMTP server. The mail client, or a local agent on your system, connects to the provider’s SMTP submission server and transmits the message using the SMTP protocol. This server is often called an MSA, Mail Submission Agent.

Second, that mail server uses SMTP to relay the message to the recipient’s mail server. The sending server looks up information in DNS to find the mail exchanger for the recipient’s domain, then opens an SMTP session to that server. The message may pass through one or more intermediate SMTP relays, but each hop still uses SMTP. Only after the message arrives at the final server do mailbox access protocols, such as those from other chapters, become involved.

You can think of SMTP as the “postal truck” protocol that moves letters between post offices, not the mechanism you use to open and read letters in your own mailbox.

Default Ports and Submission vs Relay

SMTP normally uses TCP for transport. Historically, servers that exchange mail use TCP port 25. This port is still the standard for server to server mail transfer on the public internet. When one mail transfer agent connects to another to deliver or relay email, it usually targets port 25 on the remote side.

For end users who submit email from a client to their provider, a different port is common. Port 587 is widely used as the mail submission port. This is intended specifically for authenticated clients who send outgoing mail through their provider’s server. Sometimes you will still encounter port 465 for encrypted submission, but port 587 with explicit encryption is now the standard practice.

It is helpful to distinguish two roles. Mail submission refers to the client to server step, where a user’s device hands a message to its provider. Mail relay refers to server to server transfer, where SMTP servers accept mail from other servers and forward it closer to the destination.

The usual mapping is summarized here:

SMTP Conversation Basics

SMTP defines a clear conversation pattern between the client and the server. The client initiates a TCP connection to the server’s SMTP port. When the connection is established, the server sends a greeting line that starts with a three digit status code. After that, the client and server exchange SMTP commands and replies until the message is transmitted and the session ends.

Each command from the client is a short text word, often followed by arguments, and each server reply begins with a numeric code that indicates success, failure, or some intermediate state. The protocol is line oriented and human readable, so you can observe or even type SMTP interactions manually over a raw TCP connection.

A simplified flow for sending a single email looks like this at a high level. The client connects and receives the greeting. The client introduces itself, then announces the sender address, then announces the recipient address or addresses. After the server agrees to accept data, the client sends the message contents and finishes with a specific terminator sequence. Finally, the client closes the session.

Key Commands and Responses

SMTP uses a specific set of commands to move through its states. A few of these are fundamental to the basic operation. While there are many extensions and more advanced commands, beginners only need to understand the core sequence.

In a typical conversation, the server first sends a greeting that starts with a 220 code. The client then identifies itself with a HELO or EHLO command. EHLO is the extended form and is common in modern implementations. The server replies, often listing supported features when EHLO is used.

Next, the client uses the MAIL FROM command to specify the envelope sender address. This is followed by one or more RCPT TO commands that specify the envelope recipients. After the server confirms that it is willing to accept at least one recipient, the client issues the DATA command. The server responds to invite the client to send the message body. The client then sends the message headers and body, and ends the data with a line that contains only a single period. Finally, the client sends QUIT to terminate the session.

The main commands can be summarized as follows:

Responses from the server use three digit codes. Codes beginning with 2 indicate success, codes beginning with 4 indicate a temporary problem, and codes beginning with 5 indicate a permanent failure. Some examples include 220 for service ready, 250 for requested action completed, 354 for “start mail input”, and 550 for “mailbox unavailable” or similar errors. These response codes guide the client’s behavior, such as retrying a delivery later or generating a bounce message.

SMTP and Message Structure

SMTP itself does not define how the content of the message is formatted beyond treating it as lines of text ending in a specific line terminator. However, there is a close relationship between SMTP and internet email message format as defined in separate standards.

At minimum, the message data sent after the DATA command consists of headers followed by a blank line and then the body. Classic headers include fields such as “From”, “To”, “Subject”, and “Date”. SMTP treats this block as opaque text and is mostly concerned with delivering it rather than interpreting it.

Two different concepts of sender and recipient exist in email. The envelope sender and recipients, specified with MAIL FROM and RCPT TO, control routing and delivery. The message headers “From” and “To” describe who appears as sender and recipients to the user. In simple cases these match, but they can differ, especially for mailing lists and forwarding services. SMTP handles the envelope addresses directly but simply transports the headers as part of the message data.

Because SMTP was originally designed for plain text, additional mechanisms are used to represent attachments and rich content inside the message body. These mechanisms are covered elsewhere, but it is useful to know that SMTP simply carries the encoded data without needing to understand file formats.

Authentication and Encryption in SMTP

SMTP was originally created for a more trusting network environment, where servers freely relayed mail for others and encryption was not expected. Modern email systems add authentication and encryption on top of SMTP to cope with abuse, privacy concerns, and policy requirements.

Client authentication is a key feature for submission. When a user’s mail client connects to a submission server, it typically uses an SMTP extension to provide credentials. This process, often called SMTP AUTH, allows the server to verify that the user is entitled to send mail through that server and to apply policies and rate limits per account.

Encryption for SMTP usually occurs at the transport level. Instead of sending credentials and messages in plain text, the client and server negotiate a secure channel using TLS. For submission on port 587, the client often starts in plain text and then upgrades the connection using a STARTTLS command, which triggers a TLS handshake. Some older deployments use implicit TLS on port 465, where the connection is encrypted from the beginning.

For server to server SMTP over port 25, opportunistic encryption is common. Servers advertise support for TLS using the same STARTTLS mechanism, and if both sides agree, the conversation is encrypted. If not, some servers fall back to unencrypted transfer depending on policy. The use of certificates, trust models, and strict policies for encryption and authentication can be quite complex, but all of it wraps around the same basic SMTP commands and responses.

SMTP Limitations and Extensions

SMTP was designed in a time when email messages were small, mostly text, and character sets were simple. As a result, the core protocol has some limitations. Early SMTP assumed 7 bit ASCII characters and limited line lengths, which is not sufficient for binary files or large rich content. It also did not anticipate modern security, anti spam measures, or very large attachments.

To cope with new needs, SMTP has been extended through a set of optional features. These extensions are advertised by the server in response to EHLO. A common extension allows transmission of larger messages by advertising a maximum message size. Another extension supports authentication. Yet another allows the client to request enhanced status codes for more detailed error information.

Message format extensions work together with SMTP to carry non ASCII content and attachments by encoding them into a suitable form before transmission. From the perspective of SMTP itself, these are just part of the data. The protocol is flexible enough that new capabilities can be added while preserving interoperability, as long as both sides agree on the extensions during the EHLO capability exchange.

Despite its age and original simplicity, SMTP remains the backbone of email transfer on the internet. The core ideas of text based commands, numeric replies, and store and forward design have proved durable. Modern deployments layer security, policy, and filtering around this core without changing the fundamental behavior.

Core Rule Summary

Below is a concise box that highlights the most important operational facts about SMTP for beginners.