Three main parties are involved in transferring an electronic message: the sender, the recipient, and the email server. The email goes from the sender to the mail server, which then lets the recipient get the message.
What is the role of email protocols here? They establish connections between transferring parties. So, one protocol is needed to send, and one – to receive.
Today, we’ll review and compare the three most commonly used email protocols – IMAP vs POP3 vs SMTP – and help you choose the right option for your needs.
What is an email protocol?
An email protocol is a combination of principles and rules that make it possible to transfer messages between different servers, machines, and email clients. It creates standards that messages should follow to reach the recipients in their original state.
For example, when you send an email from Gmail client to someone with Outlook address, you expect all the attachments and body elements to be present when they view your email. This is true whether they use Apple Mail, Microsoft Outlook, or Thunderbird clients to access their inbox.
Email protocols also determine how messages should be sent and accessed, what format they should have, and what structure should the connection follow.
SMTP – a standard protocol to send emails
What is SMTP?
Simple Mail Transfer Protocol (SMTP) establishes how the message gets from the sender to the email server. Also, it is used by a mail transfer agent (MTA) to deliver emails between servers. This process is called mail relaying (or SMTP relay).
SMTP is only meant for sending email messages.
How SMTP works
SMTP workflow consists of commands sent by the SMTP client and corresponding replies by the SMTP server.
Default SMTP commands are text-based, such as HELO, MAIL FROM, and others. Sometimes you might encounter extended SMTP (ESMTP) commands such as EHLO, STARTTLS, etc.
Replies are represented by numeric completion codes (for example, 220, 250, 354, and so on). For more on SMTP commands and response codes, read our dedicated blog post.
Any SMTP conversation consists of three stages:
- SMTP handshake – The SMTP client establishes a TCP connection with the SMTP server. Once the server replies with 250, the handshaking starts. The stage ends when the server confirms the recipient’s address.
- Email transfer – Code 354, as a response to the DATA command, launches the transfer of the email. Once the server gets a final dot, the message is transferred.
- Termination – Client and server say goodbye to each other using the command QUIT and code 221, respectively.
Let’s take a look at the interaction between the SMTP client and server through a simple email delivery example:
| Command or Response | What it means | |
| Client: | HELO client.rocket.comorEHLO client.rocket.com | Identifies itself and initiates the SMTP conversation. The domain name or IP address is usually sent as an argument together with the command. EHLO is an alternative command to start the conversation. It identifies that the client uses the ESMTP protocol. |
| Server: | 250 | OK or completed |
| Client: | MAIL FROM:<andy@rocket.com> | Says that a new mail transaction is starting and specifies the sender |
| Server: | 250 | OK or completed |
| Client: | RCPT TO:<jane@gmail.com> | Specifies the recipient. (For multiple recipients, the command will be repeated for each recipient’s address) |
| Server: | 250 | OK or completed |
| Client: | DATA | Initiates the transfer of the email contents including body text, attachments, and so on. |
| Server: | 354 | Lets the client start the content transfer |
| Client: | Date: Wed, 24 July 2019 16:03:23 | Date |
| Client: | From: andy@rocket.com | From header |
| Client: | Subject: How SMTP works | Subject line |
| Client: | To: jane@gmail.com | To header |
| Client: | Empty line | |
| Client: | Hope, it’s not boring:) | Body text |
| Client: | . | Once the message contents have been transferred, a single dot must be sent in a line to terminate. |
| Server: | 250 | OK or completed |
| Client: | QUIT | Request to terminate the SMTP conversation |
| Server: | 221 | Closes transmission channel |
SMTP ports
- 25
This is a standard port for relaying messages between email servers. Cloud hosting providers and many email clients (Gmail, Microsoft Outlook, Mozilla Thunderbird, etc.) block port 25 to prevent spam. They usually prioritize secure connections like 587 or 465.
- 465
465 is not an RFC-compliant port. It was meant for the SMTPS encryption and authentication wrapper over SMTP. IANA registered 465 as an SMTP port, but it has never been recognized as an official SMTP transmission or submission channel.
Later on, port 465 became obsolete and was revoked in favor of STARTTLS wrapper over SMTP. Nevertheless, today many servers still use SMTPS and maintain 465.
- 587
A default SMTP port 587 is the option to submit an email for routing. TLS encryption ensures the secure submission of the email. Almost all mail servers support 587.
- 2525
It is not an official SMTP port, but almost any email service provider supports it. 2525 is secured similarly to 587 and is often used in lieu of it. So, if the use of the default SMTP port causes some trouble, try 2525.
For more on this, read our blog post about SMTP ports.
And for a deeper dive into the differences between SMTP and a protocol such as IMAP, check out this video:
IMAP4 and POP3 – protocols to receive emails
Once the email knocks at the mail server’s door, either IMAP or POP3 will be used to retrieve it. Both of these servers are message accessing agents (MAAs).
What is IMAP?
Internet Message Access Protocol (IMAP) is a communication standard for accessing emails. Today, its fourth version is in use, hence the name IMAP4.
IMAP stores emails on a remote server and downloads them on demand when the recipient opens them. So, the IMAP protocol gets access to the email from any device or location if authorized. This allows for email synchronization, which is why IMAP is the go-to option for most email service providers.
How IMAP works
Here is the basic flow of the IMAP client/server interaction:
- A recipient’s mail client connects to the server the message is stored on
- The recipient can see the message headers of all the emails on the server
- If the recipient chooses a particular message to read, IMAP downloads it on demand
Under the hood, a primitive IMAP connection may look as follows:
| Client command | Description |
| LOGIN | Opens the IMAP connection |
| LISTCREATERENAME and other commands | Commands that allow you to manage mailbox |
| SELECT | Defines the current mailbox and opens an IMAP session |
| LISTDOWNLOADDELETE and other commands | Commands that allow you to manage messages |
| CLOSE | Closes the IMAP session. If you want to open a new session, you can do this by setting up another current mailbox. Once the new session is opened, the IMAP server permanently updates the messages according to the previous session. |
| LOGOUT | Closes the IMAP connection |
Here you’ll find a full selection of client commands.
Darn! We forgot about the IMAP server responses. There are three forms of them:
- Status Responses (OK, NO, BAD, PREAUTH, and BYE)
They may include a response code like ALERT or CAPABILITY. A response code gives additional information beyond the status response condition.
- Server Data
These responses include Server and Mailbox Status (CAPABILITY, LIST, etc.), Mailbox Size (EXISTS and RECENT), and Message Status (EXPUNGE and FETCH)
- Command Continuation Request
This response confirms that the server is ready to accept the continuation of the client’s command. It is represented by a “+” token.
IMAP ports
- 143 – A default IMAP port without encryption
- 993 – A secured SSL/TLS port used by most email service providers. It is often called IMAPS.
What is POP3?
Post Office Protocol 3 is a simpler way to access mailboxes. We use its third version – that’s why it’s called POP3. Users love this protocol for its low dependency on Internet connections.
POP3 protocol downloads emails from the server to the local computer, so you can read them even offline. The server deletes messages once they are retrieved. This is the default and common setting, but there is the option to enforce a site policy regarding email retention on the server.
At the same time, even if the POP3 client contains configuration options to store email, the server won’t support such an action.
How POP3 works
POP3 connection consists of four steps:
- The client connects to the server (AUTHORIZATION State)
- The client retrieves new emails (TRANSACTION State)
- The server deletes the stored messages (UPDATE State)
- The client disconnects from the server
Let’s take a look under the hood of a POP3 session as well.
| Command or Response | What it means | |
| Server: | The server is waiting for the connection on TCP/IP port 110 | |
| Client: | The client establishes a TCP connection. | |
| Server: | +OK POP3 server ready <example.server.com> | If everything is OK, the server’s response will be consistent. Otherwise, it will show -ERR |
| Client: | APOP mrose c4c9334bac560ecc979e58001b3e22fb | Provides origin identification and replay protection for the session. mrose is the name parameter and c4c9334bac560ecc979e58001b3e22fb is the digest parameter. They identify a mailbox and an MD5 digest string |
| Server: | +OK | If everything is OK, the server’s response will be consistent. Otherwise, it will show -ERR |
| Client: | STAT | Now, the session enters the TRANSACTION state. STAT command asks how many messages are currently in the mailbox and their size in octets |
| Server: | +OK 1 334 | Maildrop has one message of 334 octets |
| Client: | DELE 1 | Deletes the message |
| Server: | +OK message 1 deleted | If everything is OK, the server’s response will be consistent. Otherwise, it will show -ERR |
| Client: | QUIT | Once the session is over, the client logs off via QUIT command |
| Server: | +OK dewey POP3 server signing off (maildrop empty) | If everything is OK, the server’s response will be consistent. Otherwise, it will show -ERR |
| Client: | The client closes the TCP connection. | |
| Server: | The server is waiting for connection on TCP port 110 |
We used only two commands (DELE and STAT) that are valid in the TRANSACTION state. You can find more options here.
As for POP3 responses, they contain a status indicator (+OK or -ERR) and a keyword that may be enhanced with additional information (for example, -ERR no such message, only 2 messages in maildrop).
POP3 ports
- 110 – A default POP3 port without encryption
- 995 – A secured SSL/TLS port that is often referred to as POP3S.
IMAP or POP3 – which protocol should I choose?
At first, we were considering making a table with a comparison of the pros and cons of IMAP and POP3. But this idea proved untenable since different users would have different demands in terms of the email protocol standards. So, we decided to set it up this way instead.
Pick IMAP4 if:
- you need access to mail from different devices
- you need to organize your mail in folders or some sort of hierarchy
- you have unlimited server storage space
- you have a constant and stable Internet connection
- you need fast access to your mail
Pick POP3 if:
- your internet connection is unstable or even unavailable
- you prioritize privacy over accessibility and prefer to store emails on the local machine
- you’re the only person with access to your email account and use a single device for that purpose
If you still don’t know which protocol to choose, check out our article on the key differences between IMAP and POP3 or watch this video:
What about HTTP?
HyperText Transfer Protocol (HHTP) is another option to access emails, yet it’s not an email protocol. Regardless, HTTP can be used to send and receive messages from webmail, such as Gmail.com. It’s also good practice to access emails in mobile apps through HTTP.
This protocol has two default ports: 80 for non-encrypted and 443 for secure connections.
How an email gets from a sender to a recipient
Now, you know what each email protocol is used for. Let’s map a full picture of how an electronic message can get from a sender (bruce@sender.com) to a recipient (jane@recipient.com).
- Sender’s email client connects to the SMTP server (for example, smtp.gmail.com)
- The SMTP server authenticates the recipient’s email address using DNS records (for more information on email authentication, read our blog posts about SPF, DKIM, DMARC, and BIMI records or watch videos on our YouTube channel)
- Once the Gmail SMTP server authorizes the recipient, it sends the email to the SMTP server of recipient.com
- Recipient.com’s SMTP server verifies whether jane@recipient.com is valid
- The SMTP server forwards the email to the IMAP/POP3 server
Is it enough to set up email protocols to send and receive emails successfully?
The short answer is no. While properly-set-up email protocols are essential, they are certainly not enough. You need a safe email infrastructure with built-in deliverability tools to reach recipients’ inboxes.
To learn more about what an email infrastructure is, check out our dedicated video:
Along with an email infrastructure, you may also need a virtual inbox to receive all your test emails.
Mailtrap is a single platform that takes care of all your email-related needs. Test your emails using a fake SMTP server provided by Email Testing, send your emails with Email Sending’s reliable SMTP server, and monitor the performance of your infrastructure. All of that within one Email Delivery Platform.
Email Testing is an Email Sandbox that captures all your SMTP traffic. You can use it to check the email sending functionality of your app and see whether the SMTP server is configured properly. With Email Testing’s HTML Check and Spam Analysis features, you’ll tackle deliverability issues before your app hits the production environment.
Once you’re done with testing, you can configure your app to use Email Sending’s SMTP server that delivers your emails to the inboxes in seconds. Alternatively, integrate Mailtrap with API for more flexibility. Whichever method you choose, you’ll get access to Email Sending’s unique monitoring capabilities – actionable analytics with drill-down reports and helicopter-view dashboards.
Here’s what the email delivery flow will look like if you were to use Mailtrap’s Email Sending or Email Testing:
- Sender’s email client connects to the real or fake SMTP server (live.smtp.mailtrap.io and sandbox.smtp.mailtrap.io, respectively). Mailtrap provides all the required credentials like port, username, password, and authentication method.
- If you’re using Email Testing, the fake SMTP server will send an email to the POP3 server (pop3.mailtrap.io).
- You’ll see your message in your Demo inbox if your app functions properly.
- If you’re using Email Sending, the emails will be directed to the recipients’ POP3 or IMAP servers.
- In a matter of seconds, they will pop up in your recipients’ inboxes.
For more information on integrating and using Mailtrap, refer to our getting started guide.
We hope our blog post on IMAP vs POP3 vs SMTP helped clarify the complicated world of emails.