Simple Mail Transfer Protocol (SMTP)

1. SMTP: Mail Transfer Between Servers

Simple Mail Transfer Protocol (SMTP) is an application-layer protocol for transferring email between a mail client and a submission server, and between mail servers that relay messages across the internet. It defines the commands, replies, and transaction rules used while a server accepts a message for delivery. SMTP therefore describes message transfer; a mailbox client uses a separate protocol when it retrieves messages for reading. SMTP does not define mailbox storage or the user interface. A receiving server can accept, queue, relay, or reject a message according to its local delivery policy, so a successful SMTP transaction means acceptance by that server rather than proof that the message has reached the final mailbox.

Its primary role is the sending of mail. When you select "Send" in a mail client, the MUA starts an SMTP transaction and submits the message to the provider's MTA. That MTA can then act as an SMTP client and relay the message to another MTA until it reaches the server responsible for the recipient's mailbox. SMTP is a push protocol; it does not retrieve mail for display. POP3 and IMAP provide the usual mailbox-retrieval functions. At each relay hop, the receiving MTA returns a reply that determines whether the sender may continue, must retry later, or must stop. The message can remain in a queue while the next delivery attempt is pending.

2. Core Principles of SMTP

SMTP uses a client-server model, a reliable ordered transport stream, text commands with numeric replies, and assigned service ports.

• Client-Server Architecture

  SMTP uses a client-server model. In each transaction, one machine initiates the request and the other listens for and accepts mail. The same server can take either role in a relay:

  • Submission: Your email client (MUA) acts as the SMTP client, connecting to your email provider's outgoing mail server (MTA), which acts as the SMTP server.
  • Relay: Your provider's mail server (MTA) then acts as an SMTP client to connect to the recipient's mail server (another MTA), which acts as the server in this new transaction.
• Reliance on TCP for Reliability

  SMTP normally runs over the Transmission Control Protocol (TCP). TCP provides a reliable, ordered byte stream and handles sequencing, error detection, and retransmission of lost segments. A connection can still fail, so SMTP must interpret replies and retry delivery when its mail-queue policy permits. This division lets SMTP focus on mail-transfer rules rather than packet ordering.

• Text-Based Commands

  Communication between an SMTP client and server uses text commands and numeric response codes. Commands such as HELO, MAIL FROM, and RCPT TO use the protocol's ASCII command syntax, which supports implementation and troubleshooting. A Telnet session can expose this exchange for testing where the server permits it, but Telnet itself does not provide transport encryption.

• Designated Communication Ports

  SMTP services use assigned ports with different operational roles:

  • Port 25: The classic port for server-to-server (MTA-to-MTA) email relay. Many internet service providers restrict outgoing connections on port 25 from residential customers to reduce abuse by infected computers.
  • Port 587: The standard port for message submission (MUA-to-MTA). Mail clients commonly authenticate on this port and upgrade the connection with STARTTLS when the server advertises it.
  • Port 465: Message submission with implicit TLS, meaning TLS starts when the connection is established. RFC 8314 specifies this service; port 465 is used alongside port 587 with STARTTLS.

3. An SMTP Session

An SMTP transaction is a structured conversation between a client and a server. The following sequence shows a typical submission or relay transaction.

1. Connection establishment

   First, the client's machine establishes a TCP connection to the server on the appropriate port (usually 587 for submission or 25 for relay). Once the connection is established, the server starts the conversation by sending a "ready" message, typically starting with the code '220'.

   Server: 220 mail.example.com ESMTP Service ready

2. Client identification

   The client introduces itself using the 'EHLO' command (for Extended SMTP) or the older 'HELO' command, followed by its domain name. 'EHLO' is preferred because it tells the server that the client understands modern SMTP extensions.

   Client: EHLO client.domain.com

   The server responds with a series of '250' codes, acknowledging the greeting and listing all the extended features it supports, such as authentication methods and message size limits.

   Server: 250-mail.example.com Hello client.domain.com
   Server: 250-SIZE 52428800
   Server: 250-AUTH LOGIN PLAIN
   Server: 250-STARTTLS
   Server: 250 HELP

3. Mail transaction envelope

   The client uses the 'MAIL FROM' command to declare the reverse-path, also called the envelope sender. The final Return-Path header is assigned during delivery and should not be confused with the visible From header.

   Client: MAIL FROM:<sender@example.org>

   The server confirms it is okay to proceed.

   Server: 250 OK

   Next, the client specifies the recipient(s) using one or more 'RCPT TO' commands.

   Client: RCPT TO:<recipient@example.com>

   The server checks if it can accept mail for this recipient and responds.

   Server: 250 OK

4. Message data

   After the reverse-path and recipients are accepted, the client signals that it will send the message data with the 'DATA' command.

   Client: DATA

   The server gives the go-ahead with a '354' response code.

   Server: 354 End data with <CR><LF>.<CR><LF>

   The client then sends the email content as a block of text. This includes the headers (such as 'From:', 'To:', 'Subject:', and 'Date:'), a blank line, and the body. The SMTP data block ends with the sequence <CRLF>.<CRLF>, represented in the example by a period on its own line.

   Client: Subject: Meeting Tomorrow
   Client: From: Sender <sender@example.org>
   Client: To: Recipient <recipient@example.com>
   Client: 
   Client: Hi,
   Client: Are we still on for the 10 AM meeting tomorrow?
   Client: Thanks.
   Client: .

   The server confirms that it has received the message and has accepted it for delivery.

   Server: 250 OK: queued as 12345

5. Session termination

   Finally, the client terminates the connection gracefully using the 'QUIT' command.

   Client: QUIT

   The server acknowledges and closes the connection.

   Server: 221 Bye

4. SMTP Response Codes

Every SMTP reply contains a three-digit response code. The first digit identifies the general result, which helps the client and administrator diagnose a transaction or decide whether delivery can be retried.

• 2xx - Success: Codes starting with '2' indicate success. The requested action has been completed successfully. For example, '250 OK' is the most common success code.
• 3xx - Intermediate: Codes starting with '3' are intermediate replies. They indicate that the command was accepted, but the server needs more information from the client to complete the action. The best example is '354', which the server sends after a 'DATA' command to tell the client to start sending the message body.
• 4xx - Temporary Failure: Codes starting with '4' indicate a temporary failure. The server was unable to complete the request at this time, but the issue might be transient. The client should try sending the message again later. This is known as a soft bounce. Examples include '421 Service not available' or '452 Requested action not taken: insufficient system storage'.
• 5xx - Permanent Failure: Codes starting with '5' signify a permanent, fatal error. The server cannot complete the request as given, and the client should not repeat the exact request in the same sequence without correcting the cause. This is known as a hard bounce. Examples include '550 No such user here' or '501 Syntax error in parameters or arguments'.

5. SMTP Security Extensions

Base SMTP does not by itself encrypt traffic or authenticate the submitting user. ESMTP extensions add authentication, TLS negotiation, and domain-level checks used by contemporary mail systems.

• SMTP Authentication (SMTP-AUTH)

  An open relay accepts and forwards mail without restricting the sender, which permits abuse. SMTP AUTH lets a client authenticate with a SASL mechanism advertised in the server's 'EHLO' response. Some mechanisms use a username and password; others use different credential exchanges. The server can require successful authentication before accepting submission.

• Transport Layer Security (STARTTLS)

  SMTP can begin as a clear-text protocol exchange, so credentials and message data require an additional protection layer. The STARTTLS extension upgrades the connection to an encrypted channel using TLS (Transport Layer Security). The process works as follows:

  1. The client connects to the server on a standard port (e.g., 587).
  2. The client sends the 'EHLO' command and sees that the server supports STARTTLS.
  3. The client sends the 'STARTTLS' command.
  4. The server and client then perform a TLS handshake to establish an encrypted tunnel.
  5. After a successful TLS handshake and certificate or policy checks, the client and server issue EHLO again and send subsequent SMTP commands through the protected channel.
• Spam and Abuse Prevention

  Beyond authentication, modern mail servers use a suite of other technologies that work alongside SMTP to verify the legitimacy of incoming mail. These include:

  • SPF (Sender Policy Framework): Allows a domain owner to publish a list of servers that are authorized to send email on behalf of that domain.
  • DKIM (DomainKeys Identified Mail): Adds a domain-associated digital signature, allowing the receiving server to verify the signed content and selected headers were not changed in transit. DKIM alone does not establish every aspect of sender authorization.
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): Applies domain alignment rules to SPF and DKIM and lets a domain publish a receiver policy for failures, such as no action, quarantine, or rejection.