Have you ever really thought about email? It’s so ubiquitous, it’s easy to forget just how incredible it is. The entire modern world is built on the back of email. We use it for business, authentication, shopping…some of us even still use it to write letters. It’s easy to take it for granted, but there’s a miracle of technology and infrastructure running in the background to make it all work.
The most important of these technologies is the Simple Mail Transfer Protocol, or SMTP. It’s the postal service of the internet! The pixelated Pony Express! Every major email service, from Gmail to Outlook, runs on SMTP.
For most people, SMTP is basically magic, but you aren’t most people. If you’re like me, you want to pull back the curtain. So let me indulge that curiosity, and take you behind the scenes of one of the biggest components of the modern internet.
-
Navigate This Article:
SMTP Basics
Think about sending a letter. I know, it’s archaic, but trust me on this one. What do you need to make sure it gets to where it’s supposed to? Obviously you need an address and a stamp to pay for postage. Then you put it in a mailbox and… then what? It’s not like it grows wings and flies to its destination.
Snail mail is complicated. Once that letter gets picked up, it goes into a massive sorting system designed to ensure it arrives where it’s supposed to be. The postal service checks the address and postage, and makes sure the mail arrives at its intended destination. Well, most of the time. I’ve had to awkwardly pick up packages at a neighbor’s house more than once.
At its core SMTP is what actually takes your email from the sender to the receiver.
SMTP works kind of like the internet’s postal service. It’s a protocol that detects when an email client, like Gmail, wants to send a message. Think of it like having a mail truck right next to your mailbox, ready to do an express delivery the second you seal the envelope. SMTP ensures the mail gets to the correct destination. And it can do this without being dependent on the sender or receiver’s hardware or software.
SMTP got its start back in 1982, when Jon Postel proposed it as a replacement for using the File Transfer Protocol, or FTP, for mail. FTP is great for sending large files between servers, but for emails it’s kind of the equivalent of using UPS to send a postcard. SMTP was faster, and much better suited for sending the lighter files that make up your typical email.
It wasn’t perfect, though. Originally, SMTP could only send plain text emails. That means that if someone got access to the message mid-transit (which is easier than you’d think) they’d be able to read, or even change it. So unless you and your friends were writing emails with decoder rings, SMTP wasn’t great for sending sensitive information. Today, SMTP is much more secure. Let me show you.
How SMTP Works
We’re going to get a bit technical here, but things are much simpler than they sound.
Steps Involved in SMTP:
- Connection initiation: First, the email client (AKA the mail user agent, or MUA) opens a TCP connection to an SMTP server, usually over port 25. TCP means Transmission Control Protocol, and it’s what your computer uses to connect with other computers and servers. A port is a number that your computer assigns to a packet of data so that other computers can tell what it’s supposed to be. So, in less geeky terms, your email program sends a message to an email server, saying “Hey, I want to send this email.”
- Mail transfer: All the information in the email, like your address, the receiving address, and the actual text of the email are sent to the SMTP server using software called a Mail Submission Agent (MSA). This is built into the email client, so you usually don’t need to worry about it.
- Recipient address verification: The MSA hands over the data to a Mail Transfer Agent, or MTA. If the MSA is like the mail carrier, the MTA is like the post office: it checks the recipient’s email address and then sends it on its way. If the sender and the recipient are from the same email domain, like gmail.com, the mail is just redirected to its destination. If they’re from different domains, the MTA uses the Domain Name System (DNS) to find the recipient’s domain. It’s kind of like when you go to a website by entering its address.
- Data transmission: If the recipient is on a different domain, the MTA sends the mail over the internet to the receiver’s MTA. Then, the MTA interacts with a Mail Delivery Agent (or MDA). This program translates the data back into something humans can read and then sends it to the recipient’s email client.
- Termination of connection: Once everything is finished, the clients and servers disconnect from one another until the next email needs to be sent.
Whew, that was a lot. If you’re more of a visual person, this diagram shows you the role SMTP plays when you send an email.
SMTP gets your email from your computer to your recipient’s mail server.
Technical Details
SMTP doesn’t see emails the way we do, with nicely formatted text and images. Instead, it uses a series of commands to transmit messages between servers.
Here’s a list of the basic commands used in a successful SMTP mail delivery:
- HELO/EHLO: This command begins the entire process. It’s kind of like the computer saying “HELLO!” to the SMTP server. With this command, the client identifies itself to the SMTP server, after which the server will send its own HELO command back to the client with its domain name and IP address.
- MAIL FROM: Once the client and server identify themselves, the client sends a code, that tells the server the email address that’s sending the message. Think of it like the return address on a piece of snail mail. Once the server gets this information, it sends back a 250 OK code, letting the client know everything is working.
- RCPT TO: The client then sends the recipient’s address. Like with the MAIL FROM command, the server will send a 250 OK code after it receives this information. There’s an RCPT TO command for every recipient, so one bad email address won’t kill the whole message.
- DATA: This command indicates that the data contained in the email is about to be sent. After the command is sent, the server will respond with a 354 reply code, after which the contents of the email will be sent to the server. Once the email contents are received, the server sends a final 250 OK code to the client.
- QUIT: The QUIT command tells the server, “alright, we’re done”, and terminates the connection. The server will reply with a 221 code to confirm the disconnect.
You don’t need to worry about these commands most of the time: your email client handles all of them. However, there are a few commands and codes that pop up if something goes wrong.
For example, the RSET command tells the server to scrap everything and start over, without severing the connection. If you’re using SMTP commands directly, this is what you’d use if you made a typo while entering the RCPT TO address.
You might also get a 550 “requested action not taken” code. That means the server can’t deliver the email to its intended destination. Usually, this happens if an email address doesn’t exist. Should have used the RSET command there, I guess.
Related Protocols
SMTP isn’t the only protocol used for sending and receiving emails; there are a number of others that you might have heard of.
Back when I got my first iPhone, I had to use POP3, or Post Office Protocol Version 3, to download emails to my phone. It was good for accessing mail while offline, but it wasn’t exactly easy for a teenager to figure out. You can still use it, but it’s not very common.
These days you’re more likely to use Internet Message Access Protocol, or IMAP, than POP3. IMAP is another protocol that allows client software like the email app on your phone or computer to access emails on a remote web server. All you have to do is log in and voila, email!
IMAP is more advanced and feature-rich than POP3, but it’s also more complex to implement, though these days most mail apps have no problem implementing IMAP. It not only allows client software to download and delete emails, but it also supports email flags, folders, and the ability to only download select portions of an email.
Another huge benefit of IMAP is that multiple clients can connect to the same mailbox. This means you can access your emails from all your devices. My dad likes to check emails on his TV, for reasons I cannot possibly comprehend.
These protocols all work together to make email a seamless experience. SMTP makes sure the mail actually gets sent, while POP3 and IMAP make sure those emails end up on your phone. Or TV, if you like reading your emails from across the room.
Authentication and Security
SMTP is way more secure than it was back in the 80s. Now there are plenty of security and authentication practices that help keep prying eyes out of your inbox.
Authentication Mechanisms
SMTP uses several authentication commands, which each start with the AUTH code, followed by a specific type of authentication. This sounds complicated, but it all ultimately boils down to sending a username and password to the server.
AUTH LOGIN is a basic authentication mechanism.
It encodes your username and password using base64, and then sends them separately to the server.
AUTH PLAIN is a lot like LOGIN, except it sends the username and password in a single encoded string.
It DOES NOT send them as plain text, because that’d be ridiculously unsafe.
Neither of these methods are very secure, since if you can intercept the string, you can use it to bypass the authentication. It’s kind of like making a copy of a key. Instead, you want an authentication method that’s different every time.
AUTH CRAM-MD5 is designed to solve that very problem. It’s a challenge-response authentication mechanism: that means that the client trying to log in needs to complete a task issued by the server, which is different every time.
For CRAM-MD5, this involves decoding a message, crafting an appropriate reply, and then encoding it in a specific way. Even if you managed to intercept the reply, it would only be valid for that one login attempt. The next time you tried to log in, there’d be a different challenge with a completely different response.
Encryption
Transport Layer Security, or TLS, is what SMTP uses to encrypt email data. Usually, SMTP servers start with an unencrypted connection, where they figure out whether or not to use TLS.
There are a couple of ways you can implement TLS. Obviously, you can choose not to use it at all (No TLS), which means the message is sent unencrypted. Alternatively, you could set your server to use TLS if it’s available, but to send the message normally otherwise (Opportunistic TLS). If you’re in a high-security environment, your server might be configured to refuse to deliver emails to servers without TLS (Forced TLS).
There are a bunch of different TLS versions, but the newer versions have more secure ciphers. Fortunately, servers don’t need to run the same version of TLS to communicate: they’ll settle on the strongest form of encryption both servers support.
Common Security Issues
I know what you’re thinking. “If SMTP is so secure, then why do I get so many spam emails?”
To be fair, that’s not entirely SMTP’s fault: a lot of emails end up on spam lists through data breaches and social engineering. However, that doesn’t mean SMTP is perfect. For instance, attackers can leverage an open relay to send emails without restriction, letting them spam to their heart’s content.
Or, they can do so with a Directory Harvest Attack, or DHA. Attackers connect to an exposed SMTP server to find your email address, and then use it to send spam and phishing emails. TLS encryption helps protect against this, since attackers won’t be able to read your email address on those messages.
Another common security issue is spoofing, which is when someone forges a sender’s address. Sometimes, this is as simple as using a similar-looking URL. However, in the most insidious cases, a scammer can actually fake an official-looking address.
Luckily, there are countermeasures that can catch these scammers in the act, like the Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and DMARC. These work using IP addresses and digital signatures to verify that the sender is who they say they are.
Configuring SMTP
Configuring SMTP is usually pretty easy. In fact, you probably won’t have to configure it at all! If you do need to, for some reason, here’s what to do.
Basic Configuration
We’re going to be using Thunderbird as the example software. It’s a free, open-source email client from the makers of Firefox, and it’s really flexible once you get it running.
To set up SMTP, you’ll need your email provider’s Server Name. You can get this from your email provider’s support documents: it’s usually the same for everyone.
Then you’ll need to set your port. SMTP usually uses port 25 or port 587. However, ports are arbitrary, so check your email provider’s documentation for more info. Once you set the port, you can turn on encryption, then enter your login details.
Setting up SMTP on Email Clients
The steps to configure SMTP vary depending on the email client, so you may find that the steps for configuring SMTP in your email client are a little different from what’s outlined below.
That said, in the Thunderbird software:
- Open the Tools menu.
- Select “Outgoing Server (SMTP).”
- Then, click “Add” to set up a new SMTP server.
- In the Description field, you can label the account whatever you want, like “work email”.
- Get the SMTP name and default port from your email service (like Gmail), and select the level of connection security you want (generally SSL), Then select the authentication method. The username is your email address.
Setting up SMTP on Servers
If you run your own server, you’ll probably want to set it up for email. You’ll need to install an MTA like Sendmail or Postfix first.
We’re going to run through the steps to configure Sendmail and assume that you already have Sendmail actually installed on a VPS or dedicated server. For other servers, it’s worth looking up their specific settings.
- You’ll start by logging in through SSH as a sudo or root user.
- After that, you’ll need to configure the MTA. To do that, you’ll need to edit “/etc/mail/sendmail.mc” and find this line:
dnl define(`SMART_HOST’, `smtp.your.provider’)dnl
- Then, replace that line with the following:
define(`SMART_HOST’, `smtprelay.snel.com’)dnl
define(`RELAY_MAILER’,`esmtp’)dnl
define(`RELAY_MAILER_ARGS’, `TCP $h 587′)dnl
- After that, you’ll have to rebuild the configuration file, which you can do with this command:
/etc/mail/make
- Then, restart the mail server with this command:
service sendmail restart
SMTP should then be installed on your Sendmail mail server.
Advanced Configuration
From time to time, you may need to tweak some advanced settings to get SMTP to work properly. Here are a couple of examples.
Relay Servers
An SMTP relay server is a service that lets you route emails through a third party. You usually want to do this if you’re sending a lot of emails, like for a marketing campaign.
There are a bunch of SMTP relay servers out there. Some, like MailChimp, are really easy to implement. Others are a bit more complicated. There’s no real step-by-step guide here: we recommend checking the documentation for whatever relay server you want to use.
Customizing SMTP Settings
There are a few settings that you might tweak in basic SMTP configurations. Perhaps the most commonly searched-for setting is the SMTP port.
You know how we said SMTP usually uses port 25? That’s not always the case. For instance, port 587 is used when you want to send messages with TLS.
Port 2525 is not an official SMTP port, but it can be used as an alternative If your SMTP setup isn’t working properly, it’s a good idea to get in touch with the email service that you use and request information about the ports you should use.
Along with the SMTP port, you’ll also want to set up security settings. Encrypted connections like StartTLS or SSL/TLS use dedicated ports for encrypted communication. It’s worth making sure you’re using these settings for more secure communications.
If you can choose your authentication method, you’ll probably want to use the most secure option available, like CRAM-MD5.
Troubleshooting SMTP Issues
Email not working? Here’s how to troubleshoot SMTP.
Common Problems
Can’t Connect to Server: This is the most common SMTP issue, and the most self-explanatory: your client can’t communicate with the server.
To fix this, open the SMTP settings for the email account that you are having issues with. Ensure that the username and password fields are filled in and that their information is correct. In the outgoing SMTP settings, find the outgoing port and change it to port 26 or 587.
Save the changes and test the connection. If that still doesn’t work, you could turn off security settings and try again. If that still doesn’t work, it’s probably a good idea to get in touch with your email provider.
Authentication Issues: Authentication issues usually occur when you enter the wrong username or password. Check to make sure that you’re entering the right credentials, and that you haven’t left capslock on or something.
If two-factor authentication (2FA) is set up and you’re using a less secure client, you might need an app password. This isn’t your normal password: it’s a special key that apps can use to bypass 2FA. This isn’t really recommended, but it might be your only option if your client doesn’t support 2FA. You can find app passwords in the settings of your main email account.
Delivery Failure: If your email didn’t arrive, that usually means you entered an invalid email address. If you’re sure you entered the right address, there might be an issue on the receiving end. Unfortunately, there’s not a lot you can do to fix that, so you’ll need to try again later or use an alternate method of contact.
Diagnostic Tools
If you’re still having SMTP issues, there are diagnostic tools that you can use to help fix the issue. If you’re particularly tech-savvy, you can use Telnet, which is built into most Windows systems but needs to be configured before you can use it. Otherwise, you can use online tools like MXToolbox to test your connection.
SMTP’s Role in Modern Email Systems
Despite being over 40 years old, SMTP isn’t going away anytime soon. It almost feels like infrastructure at this point: an indelible part of a functioning internet that you don’t even think about. Kind of like power lines or sewer systems; you rarely think about them, but you definitely notice when they’re not working.
Hopefully this article has helped you understand SMTP a bit more. Next time you send an email, you can appreciate just how fast, secure, and feature rich this invisible protocol can be.