Your IP: Unknown · Your Status: ProtectedUnprotectedUnknown

Skip to main content

Simple mail transfer protocol (SMTP): Everything you need to know

Did you get a link to this article by email? Blame SMTP, the protocol at the heart of modern email communications. In this article, we examine what SMTP is and how it works.

Simple mail transfer protocol (SMTP): Everything you need to know

What is SMTP?

SMTP (short for “Simple Mail Transfer Protocol”) is an application layer TCP/IP protocol for sending email between computer networks. SMTP lays down the ground rules for delivering a message to a mail server, where its contents can be retrieved using an email client (also known as a mail client). It is a key part of many popular email services, including Gmail and Outlook.

But SMTP isn’t perfect. For one, it can only transmit plain text messages without any attachments. Worse yet, these messages must be written in 7-bit ASCII characters, limiting the text to the English alphabet and numbers. To overcome these limitations, SMTP must be combined with the Multipurpose Internet Mail Extensions (MIME) protocol, which converts all non-ASCII content to a format that SMTP can process.

What is an SMTP server?

Historically, SMTP used port 25 for unencrypted communications, but times have changed. Nowadays, port 25 should be avoided — in fact, some firewalls even block it automatically to protect against spam. Modern SMTP communications typically use port 587 or 465 in accordance with RFC 8314.

Think of SMTP servers as virtual post offices. When you post a letter in the real world, you don’t just hand it over to a postman to carry it all the way to the recipient’s mailbox. The letter must be processed at your local post office, which forwards it to the office in charge of the recipient’s area. SMTP servers collect and relay email messages in the same way, only faster.

Types of SMTP servers

SMTP servers don’t have to be pigeonholed into narrow functions — a single SMTP server can send, receive, and relay messages all at once. That being said, it is possible to differentiate SMTP servers by the role they play in a specific mail transaction.

Outgoing mail servers

Outgoing (outbound) mail servers are the type most often associated with SMTP — in fact, in email logistics, “outgoing mail server” is often synonymous with “SMTP server.” Outgoing mail servers are responsible for plucking the message from your email client and delivering it to the recipient’s incoming mail server.

To prevent spam, regular outgoing mail servers have strict daily limits on the number of messages they can send — for example, Gmail’s SMTP servers are limited to 500 emails per day for free users. While generous to the average user, these limitations make regular SMTP servers impractical for sending mass updates or marketing emails.

Dedicated SMTP servers

Fortunately for spam lovers everywhere, it is still possible to fill millions of inboxes with hot deals and exclusive offers by using dedicated SMTP servers. A dedicated SMTP server is a special outgoing mail server that has been set up to handle large volumes of traffic exclusively for one client (typically a corporate account). Dedicated SMTP servers offer their users more flexibility and greater limits than shared public SMTP servers.

SMTP relay servers

While every outgoing SMTP server is technically a relay server because it passes email messages to other servers, the name “SMTP relay server” is often reserved for servers used by a SMTP relay service for mass emailing. Like dedicated servers, SMTP relay services allow organizations to send tons of messages at once — only this time, the heavy lifting is done by a contracted third party.

Incoming mail servers

Incoming (inbound) mail servers store email messages received from SMTP relays until they can be retrieved by the recipient’s email client. Unlike outgoing mail servers, which almost exclusively use the SMTP protocol, incoming mail servers typically rely on the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP).

Fake SMTP servers

Fake SMTP servers (also known as “dummy SMTP servers”) are mainly used for testing emails. Just like a real SMTP server, a fake SMTP server will accept emails from your email client and make a show of sending them — only without the actual delivery. Fake SMTP servers let developers test how apps and websites handle emails without having to create throwaway email accounts.

How does SMTP work?

Just like its name implies, the Simple Mail Transfer Protocol is fairly simple in comparison to many other TCP/IP protocols. SMTP requires no authentication to work (although authentication can be added with the SMTP AUTH extension) and can be broken down into the following steps:

  1. To initiate the session, the SMTP client (referred to as the “mail user agent” or MUA) completes the SMTP handshake by connecting to its domain’s SMTP server (known as the “mail transfer agent” or MTA).
  2. The SMTP session begins once the connection is established. Your email client (the SMTP client referred to above) submits all required information for transmitting the email — the sender’s email address, the recipient’s email address, the contents of the message, and any attachments (using the MIME protocol).
  3. Before doing anything else, the SMTP server first checks if the sender’s and recipient’s domain names are the same. If they are, the email is immediately sent to the recipient’s incoming mail server.
  4. If the domains are different, the SMTP server asks a domain name system (DNS) server to provide the IP address of the recipient’s mail server. With this IP address in hand, the sender’s SMTP server connects to the recipient’s SMTP server (referred to as the “mail delivery agent” or MDA) to relay the message.
  5. If the recipient’s SMTP server is unavailable at the moment, the email message is either added to the SMTP queue (a buffer where emails are stored) or sent to a backup server.
  6. The recipient’s SMTP server verifies the email’s domain name and user name. If the information checks out, the SMTP server delivers the email to the appropriate incoming mail server.
SMPT infographic

SMTP commands

To communicate with SMTP servers, email clients and web applications use special SMTP commands. SMTP commands inform the SMTP server about the status of the email transmission and tell it what it needs to do next. Here are some examples of SMTP commands used in email transmission:

  • HELO. True to its name, the HELO command is used to initiate a SMTP session. The HELO command lets the email client formally introduce itself to the SMTP server to establish a connection. It’s not just about being polite — no mail transfer can take place without HELO. Nowadays, the HELO command has now been largely replaced by EHLO used by the Extended Simple Message Transfer Protocol (ESMTP).
  • MAIL FROM. The MAIL FROM command begins the email transfer and indicates the sender’s email address (the reverse path). The address may be left blank in some cases — for example, when an automated system is responding to someone about a failure to deliver a message.
  • RCPT TO. The RCPT TO command provides the destination mailbox (the forward path) for delivery. It is possible to include more than one recipient, but each must be added separately using RCPT TO.
  • DATA. The DATA command is a simple request for permission from the server to transfer the contents of the message. If the email client gets code 354 in response, it begins uploading the email line by line, including any attachments. The final line contains only a single period (“.”) to indicate that the data transfer is finished.
  • HELP. The HELP command instructs the SMTP server to respond with a list of supported commands. It is typically used by email clients or system administrators to check what functions their assigned SMTP server can perform.
  • RSET. The RSET command wipes the slate clean without terminating the SMTP connection. By erasing the sender’s and recipient’s buffers and state tables, the email client can begin a new message transfer.
  • QUIT. The QUIT command tells the SMTP server to terminate the session. The session is not closed immediately — the server must first respond with code 221 to acknowledge compliance on its end.

SMTP service providers

You’re not shackled to your email provider’s SMTP servers — you are free to choose another SMTP service provider or even set up your SMTP servers.

If you’re looking for the best free SMTP servers in 2023, you can’t go wrong with either Google (, port 465 or port 587) or Yahoo (, port 465 or port 587). Both SMTP service providers offer a reliable service and allow you to send up to 500 emails a day, which is more than enough for regular users and small businesses.

For larger enterprises that regularly send out email marketing campaigns, Brevo (, port 587) and SendGrid (, port 587) are options. These SMTP service providers offer more features and live support for businesses, but their free options are rather lacking — 300 messages per day for Brevo and only 100 messages per day for SendGrid.

Differences between SMTP, IMAP, and POP3

SMTP is not the only email protocol on the block. We’ve briefly mentioned the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP) when discussing incoming mail servers — let’s have a deeper look at how they deal with incoming messages.


IMAP (currently in its fourth iteration as IMAP4) is a TCP/IP protocol for receiving emails from servers. When using IMAP, the email client initially only retrieves the dates, sender information, and subject lines of email messages from the incoming mail server, storing this data in the local cache. This is done to conserve bandwidth — the rest of the contents are downloaded when the user chooses to open the message.

One big advantage of IMAP is that it doesn’t delete emails from the server after delivery, meaning that users can access them on multiple devices from different locations. It also stores any changes to the messages (such as whether they’ve been read or deleted) on the email server, which keeps the status of the user’s inbox the same across all devices.


Like IMAP, POP (currently in its third official release as POP3, with POP4 existing only as an informal proposal) is a TCP/IP protocol for receiving emails from servers. However, unlike IMAP, which retrieves email contents only when the user opens the message, POP automatically downloads all pending emails (including any attachments) from the incoming mail server to your device and deletes the server copies.

Downloading everything in one go offers one major advantage — you can read the emails at your leisure even when you’re not connected to the internet. However, because the server deletes its message copies as part of the process, you cannot access your emails from other devices. Once they’ve been downloaded, you’ll have to transfer the contents manually.

Learn more about the differences between POP3 and IMAP.

SMTP vs. IMAP vs. POP3

If you have been paying attention, you may have noticed that we primarily discuss SMTP in the context of sending emails. That is because SMTP is a push protocol — a protocol designed specifically for sending data from server to server. Push protocols force servers set to listening mode to automatically forward (push) data to its destination.

IMAP and POP, meanwhile, are both pull protocols meant for receiving emails from incoming mail servers. These protocols only retrieve (pull) the messages from the server at the user’s request. IMAP and POP play no part in relaying emails from the sender to the incoming mail server.

For modern email systems to work, you need both push and pull protocols. That means SMTP is not in competition with IMAP or POP — rather, it works together with them to deliver messages to people all over the world.


Without the Simple Mail Transfer Protocol, modern email simply wouldn’t exist. That’s the unfortunate reality — SMTP provides an easy method for mail exchange between different email providers, domains, and networks that populate today’s communications landscape. But SMTP is not a brilliant masterpiece of software engineering — it was built piecemeal over nearly four decades of ad-hoc work.

SMTP began its life in the 1980s as a simple way to send simple messages, and it shows its age. As originally envisioned, SMTP could only transfer 7-bit ASCII text, greatly limiting its use. It also did not have any provisions for encryption, leading to an explosion of spam and spoofing attacks in the 1990s.

Over time, these disadvantages were addressed by SMTP extensions and new security techniques. MIME added the ability to send non-ASCII characters and attachments. SMTP AUTH enabled authentication. Encryption software offered new ways to protect email contents. Thanks to these tools, SMTP is going strong today despite its numerous inherent limitations.