Understanding SMTP – The Protocol Behind Email Delivery 

SMTP is a fundamental protocol used in email communication. Most likely, it’s behind the emails we send and receive each day. Though it’s a simple protocol, it still involves multiple components and a lot of details. 

In this blog post, we’ll take a closer look at SMTP and explore its core features and functionalities. 

What is SMTP? 

SMTP or Simple Mail Transfer Protocol is an application layer protocol that makes it possible to transfer emails between different servers and computer networks. It does this by defining the rules of communication.

The original model was introduced in 1982. According to RFC 821, the user creates the connection request. In response, the sender-SMTP initiates a two-way connection with the receiver-SMTP. In modern terms, these are SMTP client and SMTP server, respectively. SMTP client and SMTP server communicate with commands and responses (more on that later), similar to real-life conversations.

The RFC 821 also defined the model for SMTP use. You can see the scheme in the illustration below. 

Once the connection is established, the SMTP client will transfer headers, recipients, body messages (including attachments), and all the data to the SMTP server step-by-step. When the transmission is complete, the connection will be closed. 

By definition, the full form of SMTP is when SMTP clients support relaying, email queues, and alternate address functions. This is called a fully-capable SMTP. If these functions aren’t supported, the SMTP isn’t fully-capable. In that case, relevant RFCs recommend using the message submission protocol instead. 

Keep in mind that SMTP can only send simple messages i.e., plain text without attachments. We use a separate protocol, Multipurpose Internet Mail Extensions, MIME (RFC 2045), to send attachments, message bodies exceeding the character limits imposed by SMTP, messages in languages other than English, and HTML/CSS formats. 

MIME is an extension protocol – it enhances the capabilities of SMTP, but it doesn’t operate separately. Most modern email services support MIME. 

What is ESMTP?

ESMTP or Extended Simple Mail Transfer Protocol was first introduced in 1995 in the RFC 1869. The purpose was to create a unified structure for all future extensions. The extensions aim to add functionalities that SMTP lacks by default. RFC 5321 consolidated and obsoleted previous documents. 

ESMTP uses a new EHLO command to initiate the connection. It also allows the use of additional parameters in SMTP’s MAIL FROM and RCPT TO commands. As a result, ESMTP removes the 512-character limit for additional parameters and leaves it only for cases when additional parameters aren’t defined. 

Both ESMTP and SMTP are widely used today. If the EHLO command isn’t supported, the connection should fall back to the SMTP and its HELO command. 

Speaking of extensions, we should also mention the SMTP-AUTH extension, which adds an authentication step to the process. This means that the mail client should log in to the mail server using its username and password. While SMTP authentication can’t protect against spoofing, it is an important security measure. 

What is SMTPS? 

SMTPS or Simple Mail Transfer Protocol Secure is a method that secures SMTP with the help of transport layer security (TLS) or Secure Sockets Layer (SSL) protocols. These security layers encrypt messages to prevent spammers or spoofers from viewing the contents of the emails. 

Though SSL is still widely used, TLS (more precisely, its 1.3 version) is considered to be the safest protocol for email encryption. For more information on SMTP security, read our dedicated blog post. 

Types of SMTP

RFC 5321 differentiates between four types of SMTP systems:

• Originating SMTP is the first system that interacts with the internet as it introduces mail; 
• Delivery SMTP is the system that receives emails from the internet and delivers them to the recipients; 
• Relay SMTP relays emails between SMTP servers or MTAs (more on transfer agent meaning below) without modifying the message in any way; 
• Gateway SMTP or SMTP gateway also transfers emails between different servers but, unlike SMTP relay, it’s allowed to transform the message if needed. SMTP gateways are usually firewalls that rewrite addresses or intermediary SMTP servers. 

SMTP infrastructure 

As we saw above, the main components of the SMTP model are User, Sender-SMTP (SMTP client), and Receiver-SMTP (SMTP server). However, mail agents also participate in the process of sending and receiving emails. Moreover, the SMTP model includes SMTP relay in specific scenarios. Let’s see what each of them means and what function they have. 

SMTP server 

SMTP server is an application for sending emails. It receives electronic messages from email clients (Gmail, Yahoo! Apple Mail, AOL, etc.) and transfers them to other servers. These can be other SMTP servers or an incoming mail server. 

SMTP email server can be local or cloud-based. A local SMTP server is a good option for those who don’t want to depend on third-party servers. On the other hand, a cloud-hosted SMTP server requires less effort and can be more secure in the majority of cases. 

Mail Agents 

There are four main agents: 

• MUA (Mail User Agent) is the email client we mentioned above. It’s an application or a website that you use to send and receive email messages.
• MSA (Mail Submission Agent) receives emails from the email client, checks its headers, and verifies that the addresses are indicated correctly. 
• MTA (Mail Transfer Agent) is a sendmail program that processes and transfers emails. It receives messages from the MSA. Most modern MTAs take on MSA’s responsibilities. In that case, message transfer won’t include MSAs. The most popular MTAs are Sendmail, Postfix, and Exim.
• MDA (Mail Delivery Agent) is the final agent before your emails get delivered to the recipient’s SMTP server and then retrieved through inbound email servers (IMAP or POP3). 

Note that the lines between agents’ responsibilities can be blurry at times, yet they are still useful for illustrative purposes. In the real world, MUAs, MTAs, and SMTP servers are the most essential components of email delivery. 

SMTP relay 

SMTP relay is the process of transmitting emails between SMTP servers hosted on different domains (from @gmail.com to @yahoo.com, for example). 

MTAs check if the domain names are the same. If they are, the SMTP relay won’t happen. But if the domains aren’t the same, MTAs will query Domain Name System (DNS) records to find the IP address for the recipient’s domain. Once the IP is located, they will route the message between one or multiple MTAs (SMTP relay) until it’s finally delivered to the recipient’s SMTP server. 

How does SMTP work?

An SMTP session begins when the client opens a Transmission Control Protocol connection (TCP connection, sometimes called TCP/IP) to the SMTP server. The server responds with an opening message, expressed with code 250. This process is often called an SMTP handshake. 

The client then sends a HELO command (EHLO for ESMTP) and identifies itself. It often follows up the command with the domain name or IP address. In non-technical words, the client says, “Hello, my name is John the Client, I’m sending an email from gmail.com, and my IP is 192.0.2.0”. The server will respond with code 250 again. 

After that, the email transfer stage will begin. Email contents will be transferred step-by-step with MAIL FROM (john@gmail.com), RCPT TO (oliver@gmail.com), and DATA (‘Hey, how have you been?’) commands. If the server accepts the transaction, the client will transfer email headers. It’s necessary to use an end-of-line indicator (period ‘.’) once everything has been transmitted. 

The server will respond with code 250 if the transaction is successful. The client will initiate the termination of the SMTP connection with the QUIT command, and the server will close the transmission channel with code 221. 

This is, of course, a simplified example without an SMTP relay, forwarding, gateways, or error codes. For more information on these, please refer to RFC 5321. 

What about the SMTP queue? 

SMTP queue is a set of emails that are waiting to be delivered. Emails are usually put in the queue when receiving SMTP server isn’t ready to accept emails, or you’re sending large volumes at once. When the server responds, the emails will be delivered one by one. SMTP queue is a sort of buffer between you and the receiving server. 

SMTP commands and responses

We mentioned some of the SMTP commands and responses in the example above. But, while sending emails with SMTP, you may encounter other commands and responses. 

In general, commands are alphabetic character strings ending with <CRLF>. If additional parameters follow, the characters will be terminated by <SP>. 

Responses (or replies) are numeric completion codes that can be positive or negative. Typically, they are followed by a text string. 

Commands and responses are composed of an ASCII character set. 

Commands 

• HELO/EHLO – initiates the start of the SMTP session.

Syntax: "EHLO" SP ( Domain / address-literal ) CRLF or"HELO" SP Domain CRLF

• MAIL FROM – initiates mail transaction and includes the reverse path and sometimes optional parameters. 

Syntax: MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

• RCPT TO – indicates the recipient(s) and includes their email address (a.k.a. forward-path) as an argument. 

Syntax: RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

• DATA – asks the server’s permission to transfer data and does so once it receives a positive reply. 

Syntax:  "DATA" CRLF

• VRFY – asks the server to verify if the mailbox in the argument exists on the local host. 

Syntax: "VRFY" SP String CRLF

• EXPN – does the same as VRFY but for the mailing list. 

Syntax: "EXPN" SP String CRLF

• NOOP – checks the ability of the server to respond. 

Syntax: "NOOP" [ SP String ] CRLF

• QUIT – initiates the termination of the connection 

Syntax: "QUIT" CRLF

• HELP – asks the server to verify which commands it supports. It may include a specific command as an argument. 

Syntax: "HELP" [ SP String ] CRLF

• RSET – resets the SMTP connection and erases all the buffers and state tables. The SMTP connection will be reversed to the initial state. 

Syntax: "RSET" CRLF

SMTP protocol may also support some ESMTP commands, such as STARTTLS, AUTH, and others. 

Responses 

Common positive responses 

• 250 – the requested action is okay or completed 
• 211 – system status or reply to HELP
• 220 – <domain> service is ready 
• 221 – <domain> closing the transmission channel 
• 354 – start mail input (usually responds to DATA command) 

Negative responses or error codes

• 500 – syntax error or command couldn’t be recognized 
• 503 – bad sequence of commands
• 252 – the server can’t verify the user. It will still accept the message and attempt the delivery (responds to VRFY command)
• 450 – mailbox unavailable 
• 510 – invalid email address 

SMTP ports

SMTP ports are communication endpoints that help identify the exact location of internet addresses. The most common ports used with SMTP are 25, 465, 587, and 2525. 

• 25 is the oldest SMTP port, but using it for email submission is no longer common. As it doesn’t have security mechanisms, spammers abuse it heavily. For that reason, internet service providers (ISPs) usually block port number 25. It’s recommended to use it only as a relay port. 
• 465 is more secure compared to 25, but it’s not an official SMTP port and is now deprecated. It supports SSL encryption. Still, it’s recommended to avoid using it whenever possible. 
• 587 is the default SMTP port recommended with STARTTLS. Almost all email service providers support it. 
• 2525 is an alternative to 587. It can be used when 587 is blocked or unavailable. 2525 has never been recognized as an official SMTP port. Regardless, most ISPs allow transactions through this port. 

Comparing SMTP, IMAP, and POP3

Apart from SMTP, the most common email protocols are IMAP and POP3. SMTP is an outbound email server used for sending and delivering emails. IMAP and POP3 are message access protocols used for retrieving incoming messages from the email server. 

IMAP is an Internet Message Access Protocol that connects to the server and downloads messages on request. The messages won’t be deleted once the connection is terminated. With IMAP, users can access their emails from any computer or device. 

POP3 or Post Office Protocol 3 also connects to the server, but it downloads all the received messages. Once that’s completed, it will delete all the emails from the server. Unlike IMAP, POP3 is device-dependent. 

More information on the differences between these protocols is available here as well as in our dedicated video.

How to send emails with SMTP 

One of the main benefits of SMTP is that it makes it easy to send emails from different apps or devices. Most programming languages allow users to route outgoing emails through SMTP either natively or with the help of different libraries. Unlike Web API (or Email API), SMTP integration doesn’t require advanced coding skills. 

You’ll need working SMTP credentials (such as host, port, username, password, and encryption) and the relevant programming language to complete that task. You can check out our recent blog post for more details on that. 

SMTP as a service – testing and sending 

SMTP (or, more precisely, SMTP server) is provided to users as a service for two main purposes – testing and sending. 

In terms of testing, SMTP service implies a fake SMTP server that captures outgoing mail. That way, emails don’t reach real inboxes, creating a safe environment for testing. 

When it comes to email sending, SMTP service is synonymous with SMTP relay service. Email providers have their own SMTP servers that enable users to send marketing or transactional emails. 

Ideally, these two SMTP services can be combined into one robust tool such as Mailtrap. 

Mailtrap is an Email Delivery Platform that combines Email Testing and Email Sending. It’s a complete email infrastructure that allows users to test SMTP server, send emails with it, and monitor their performance with actionable analytics. 

Email Testing is a Sandbox that captures all the SMTP traffic in a virtual inbox and eliminates the chances of spamming users. You can easily inspect and debug your emails in staging with HTML/CSS or spam checks, view tech info, or use manual/automatic forward features. Email Testing provides multiple inboxes for different projects and product stages. 

Email Sending is an infrastructure with high email deliverability rates by design. With its Email API and SMTP service, the integration is smooth and effortless. All you need to do is verify your domain and choose the preferred method of integration. Once that’s done, you can reach recipients’ inboxes in a matter of seconds. 

Email Sending also has actionable in-depth analytics with drill-down reports and helicopter-view dashboards that keep you on top of your deliverability metrics.