Unless you have successfully gone off the grid, chances are you get a steady stream of email during the day. These could be commercial or marketing email, transactional email about your purchases, or personal email between you and other individuals. And, to most users, sending an email is as easy as pressing a button.

But email itself is exponentially more complex than simply hitting “send.” In fact, email is hard and even explaining how it works can get complicated.

Here we’ll break down a core component of email delivery: SMTP. Yes, it’s technical and no, most people can’t explain it to you, but after reading this guide to SMTP, you’ll be one of the few who can explain it yourself.

And just so you know, when it comes to SMTP we’re the experts. We’ve been offering cloud SMTP servers for over a decade now, having delivered billions of emails through SMTP to the inbox. If you’re in need of a cloud-based SMTP server, then you can grab a free trial of our services here.

What is SMTP?

STMP stands for “Simple Mail Transfer Protocol.” It’s kind of funny “simple” is in the name, because as we go along, it’ll be clear it’s not exactly the most simple process in the world.

SMTP is a protocol used for routing and sending email from a client or server to another. What is a protocol, you may ask? Protocols are formally defined rule-sets that set the basis for how two systems communicate. If you think of a protocol as a language that is spoken between two machines, then the IETF published RFCs 5321 and 5322 define email similar to how dictionaries and grammar guides define the English language.

Just as there are many different languages spoken around the world, the SMTP protocol is one of the most common protocols. Many people may be familiar with HTTP as the language of web browsers and websites. There are also other protocols used commonly with email, such as Internet Message Access Protocol (IMAP) and Post Office Protocol (POP). These latter two protocols focus on defining how mail clients retrieve messages from an inbox to display in a client. SMTP though is the only protocol concerned with sending mail.

SMTP was originally formalized in 1982. Since then, it has been updated a few times by the IETF. Along with the updates to the protocol, other technologies have been layered on top of SMTP over the years. One of the biggest changes to SMTP was the introduction of Extended Simple Mail Transfer Protocol (ESMTP). ESMTP introduced the ability to have email messages with multimedia content within it, like graphics and video. It also enabled new protocol commands like STARTTLS, which is a means to secure the SMTP conversations as they transit the internet. Encryption of data in transit is important to email because SMTP as a protocol is just text-based strings passed from client to server, or server to server.

For example, here is the opening string passed by the SMTP servers at SocketLabs: 

220 r3.east.aws.in.socketlabs.com Hurricane Server ESMTP service ready.

It’s super important to understand SMTP because the only thing between you and major email clients like Gmail, Microsoft Outlook, and Yahoo are a handful of SMTP transactions.

How does SMTP work?

This is where it starts to get a little tricky. More than a little, honestly, but it’s our job to help you send email better than before.

Email clients (also known as a mail user agent or MUA) can connect and communicate with an established SMTP server. The client opens an SMTP connection as soon as a user presses “send” on their email. Then, the SMTP client tells the server what to do using SMTP commands and it also transfers important data like the email content and both the recipient and destination addresses.

SMTP commands

There are a number of SMTP commands that help facilitate the transfer of mail from one location to another. If we go back to our original comparison of the SMTP protocol to languages, commands would be verbs. These are just a few of the most popular commands you’ll see.

• EHLO (or HELO): This command starts the entire sending process as the email client or server introduces itself to the SMTP server it is connecting to. Then, the receiving systems sends a response back, and this will include an introduction as well as a list of all the different supported SMTP commands for a server.
• MAIL FROM: After getting a EHLO, the sender will then provide a text snippet outlining where asynchronous bounce messages should be returned aka the return path address. This command also serves as a notification to the SMTP server that a new message transaction is beginning. The receiving server determines if it wants to accept this command in terms of both formatting and syntax (is the address valid?) and in terms of interest in mail from that address/domain (is there a spam block in place?). Assuming everything looks good, the receiving system will return a 250 response code.
• RCPT TO (Recipient To): After the 250 response to a MAIL FROM command, the next step is to issue a RCPT TO command which specifies to whom the email is being sent. One really interesting facet of these first two commands is that the email addresses provided in these commands may never be seen by the end recipient. When a message is BCC’d, an SMTP RCPT TO command is issued for the receiving address even though it is not present in the message itself (inside the envelope). The SMTP server sends back another 250 response code if it accepts the recipient destination. If there are multiple recipients, this process can go back and forth until all the recipients have been acknowledged. 
• DATA: This command initiates the transfer of data (aka the message). In response, the server replies with a 354 code and then the client or server starts transferring the message body and header, and all message attachments as one big text blob. Once the contents are given to the server, a single period and carriage return is sent to notify the server the message ended. If everything checks out and it is ready to be delivered, another 250 response is sent from the server and the message proceeds to its recipients.

SMTP servers

At its most basic level, an SMTP server can send, receive, and relay mail, and if it does any combination of three of those things, it is a Message Transfer Agent (MTA). Using Gmail as an example, their SMTP server is smtp.gmail.com. When a mail client like Outlook goes to submit a message to Gmail, the client uses a DNS query to get the IP address of smtp.gmail.com. It will then attempt to open a connection to the resulting IP address using an agreed upon port (most likely port 587 for message submission). The client will also use IMAP/POP, but this would be to retrieve messages for the address and likely be communication that occurs with a different Google server.

Today’s SMTP servers and MTAs now do a lot more than just send and receive email messages.  You often find these systems of accomplishing other message related tasks like applying or validating email authentication standards like DKIM and SPF. These systems may also run spam scanning systems that operate in real time as messages come in and out of the system. The operation of an MTA can get more complex than just speaking SMTP. 

What is an SMTP port?

If you think of the internet as computers around the world, and think of IP addresses as the physical address on a map for a computer, a port is like the specific door you need to use to get in the house/business. Computers have thousands of ports (over 65,000!) and they are critical to SMTP because if you don’t use the right port, your SMTP connection will not be successful.

What SMTP port should you use?

What SMTP port should you use? It’s a very common question that is asked, luckily we’ve written a blog post about it and we’re also further explaining SMTP port numbers in this SMTP guide as well. SocketLabs has multiple SMTP port configurations to use, so which one is right for your needs? Let’s take a look!

Port 25

Port 25 is the original port for email, and in fact, it is still the only port where inter-system (think of a message going from SocketLabs to Yahoo) messages are transmitted. So if there is just one standard port for email, why is there always so much confusion around SMTP ports?

Well, the prolific nature of email, and especially email spam, means any computer that has their door for port 25 open can be used to transmit messages to recipients over the internet. Malware and viruses in the 90’s and 2000’s loved finding access to a computer with port 25 open. So much so that it later became a best practice to shut off this door unless necessary. Most well-managed computers and servers on the internet have port 25 disabled now by default. 

Port 587

So, how do systems where port 25 is closed send email messages? They don’t do direct message delivery, rather they use an alternate SMTP port to submit messages to a server that does have port 25 open. You might hear about port 587 as the formal message submission port. Port 587 is used where a consumer device can submit a message to a server for processing. Imagine you’re a Gmail customer trying to send an email to a Yahoo address from Outlook on your PC. Stay with us, here. When you click send in Outlook, it connects to Gmail’s SMTP server on port 587 and submits the message for delivery. At that point, Gmail’s servers will then connect to Yahoo over port 25 to actually deliver the message.

Port 465

There are some other ports too, like port 465, which was suggested as the formal port where mail clients and servers could connect and use explicit SSL/TLS. Port 465 was never formally adopted as a standard, but you may occasionally find systems still using it. We’ll refer to those as ”artifacts,” as they won’t be found in any modern email software.

Port 2525

Finally, the last common email port is 2525. This port is not and never was formally associated with email. It is actually designed to a now-defunct Microsoft application. Technically, email between client and server could be transmitted over any pre-agreed upon port, the pre-agreed part is the hard part for system interoperability. The use of 2525 took off when the original port of 25 started to become blocked by default. Double entering the port number results in a port that looks like 25, but isn’t and is still within the acceptable range of ports 0-65,000. SocketLabs SMTP relay servers listen on all of these ports – 25, 587, 465, and 2525. 

What’s the difference between SMTP and POP or IMAP?

Post Office Protocol (POP) and IMAP only retrieve mail from a server; they pull in mail from servers down to a mail client. SMTP, on the other hand, only communicates with servers in order to send outgoing email. There’s good use cases for each, should you use SMTP or IMAP? 

Post office protocol (POP)

POP receives mail and then keeps them until clients pick them up. Instead of sending mail, an email client requests new mail from the server, and then the new messages are sent out to the client. All messages are stored locally on the user’s hard disk, without the server retaining a copy. They’re deleted from the server upon local download.

Internet access message protocol (IMAP)

IMAP is an email protocol for managing and retrieving email from the receiving server. It is only concerned with retrieving messages, so as mentioned, you cannot use IMAP to actually send mail. Unlike POP, though, IMAP doesn’t delete the message from the server, and doesn’t exclusively place an email onto a local source. Instead, it can sync an email across different devices.

Using SMTP

Now that you understand the basics of SMTP and how it works, you can be more in control of your email’s journey via SMTP. We’ve got lots of resources you can use to get going.

How do I setup an SMTP Server?

You have a couple choices when it comes to setting up an SMTP server. First, yes, you can set up your own. There are OS- bundled and open-source email server solutions, as well as commercially licensable solutions like Hurricane MTA offered by SocketLabs. However, it can be a lot of work with a high level of complexity. If you’re in the beginning of your SMTP journey and it sounds like it might make the most sense to you to set up a server on your own, we have a few questions you should ask before doing so.

SMTP relay service

An SMTP relay service, sometimes called an SMTP provider, is a service that helps a sender deliver personal, transactional, and bulk email by routing it through a trusted server. The service will provide all of the technology and expertise necessary for businesses to deliver email by SMTP.

For instance, Gmail has its own SMTP relay server, but Gmail puts a cap on how many SMTP relays can be used per account per day. If you’re sending a high volume of email, you may need an stand-alone professional SMTP relay service to assist you in delivering the volume you need without errantly being labeled as spam.

SMTP Error Analysis

When a message is sent from a mail client to an SMTP server, the server will reply with a specific response code. Sometimes this code is 250 OK, which means the email is being accepted for delivery, or sometimes the code is an error.  

If there is a communication error, you will receive an SMTP error code, which indicates the specific problem. There are several smtp errors you can run into, but we have a list of common smtp error codes right here.

SMTP Monitoring

Even though you better understand how mail is sent via SMTP, it’s still not as simple as hitting “send” and expecting your email to travel without issue. Whether you are running your own server, or using a stand alone solution, it is critical to monitor SMTP results. You can monitor a server’s ability to receive connections via a connection test, you can monitor the ability to authenticate a user with an Authentication test, and you can monitor the ability for it to process mail (message acceptance test). Here at SocketLabs we’ve built a tool called 360 monitoring to fully understand round-trip performance. We even publicly publish the results from our monitoring on our status page here. Every two seconds we push a new message into our servers to not only make sure they are online, authenticating customers, accepting their messages, but also processing them through to end systems in a reasonable time.

SMTP Troubleshooting

It probably goes without saying, any problems you have with SMTP directly impacts your deliverability. At its most simple, SMTP issues can hinder your ability to even send mail to recipients, leaving you without a reliable way to communicate with clients and prospects.

There are any number of reasons your emails aren’t being delivered. There are a few common issues you can run into:

• The SMTP settings are not configured correctly.
• Your SMTP provider has specific settings you must use, but those were missed during setup.
• Mail is being blocked for security reasons.

Looking at error codes is the first step in determining whether the issue is temporary, permanent.

Choosing an SMTP service

You have a couple options for an SMTP service: a third party or DIY. Setting up your own SMTP service is absolutely doable if you understand how it works and have confidence it’ll work for your needs. If you do it yourself, you have full control over your SMTP infrastructure, but the downside is it can take a very, very long time to set up properly.

And with that being said, you’ll also need to be absolutely certain your email infrastructure is built and managed successfully. Why? Because a solid email infrastructure is the foundation of functioning SMTP.

Another key component to setting up your own SMTP server is the need to fully understand deliverability. Gmail and other major ISPs are constantly evolving their anti-spam processes, and it is becoming increasingly difficult to even reach recipients’ inboxes.

Overall, as you can probably see, it can become quite complex very quickly.

But the good news is there are plenty of SMTP relay services out there! You won’t need to spend your own time setting up your own SMTP server or troubleshooting issues when they arise and better protect your deliverability over time. Simply put, a third-party SMTP service provider will take the guesswork out of SMTP.

There are a ton of benefits to using SocketLabs to manage SMTP, too.

Our SMTP relay service is powered by our proprietary Hurricane MTA, and it has an uptime of 99.999%. Plus, we offer in-depth analytics and reporting to help you make sense of your email performance. Designed to make email delivery simple and effective, you’ll benefit from less headaches and more email reaching the inbox.

Using SocketLabs’ email APIs, you can see the results of your SMTP relay service when you want it, how you want it, thanks to having total control of your reporting with the ability to integrate our advanced reporting into your applications. Plus, because we take our customers’ success super seriously and SMTP relays are only one feature of our platform. We are constantly monitoring our high-volume SMTP relays to ensure they are always functioning.

Best of all, we have an easy integration to our service in which all you have to do is reconfigure your SMTP configuration. It’s truly plug-and-play, making your life easy.

Conclusion

The only thing simple about SMTP is the fact that it’s really, really hard. Email itself is hard, and when you layer on the complexity of how email is actually sent behind the scenes, it can feel almost paralyzing. But that’s ok! You can trust the experts at SocketLabs to help you understand how email works and how to optimize the email you’re sending, all while providing support, experience, and the infrastructure you need to send email…better!