Richard van Looijen
To deliver emails from A to B, virtually all emails in the world use SMTP. This Simple Mail Transfer Protocol ensures that all mail servers speak the same 'language' to understand each other when transferring messages. In this article, we'll explain how this works.
The Simple Mail Transfer Protocol is a relatively simple - hence the name - text-based protocol for sending emails. It specifies the message's sender, followed by its recipient(s), sending details, and content. With this data, the receiving email client knows who to send the message to and what to display. Although SMTP is not the only way to send emails, it is the de facto standard for email communication.
The fact that SMTP is the standard for email delivery ensures that almost all mail servers understand each other. As a result, you can assume that an email you send to a German customer will arrive in the same fashion as an email you send to someone in the UK.
However, SMTP is a protocol that assumes the recipient is always online. Since most of your customers aren't online 24/7, SMTP needs some assistance. POP3 and IMAP ensure that the recipient can retrieve the email (Gmail, Outlook, etc.). Put simply: with SMTP, you upload your email to 'the cloud', where POP3 or IMAP downloads that email.
SMTP is a protocol that works according to a client-server model. The client C takes the initiative to communicate with the server S, which is always available and reactive. The client is the sending party, and the server is the receiving party—the communication between the two looks somewhat like this:
Suppose you want to deliver an email to a client who uses Gmail. The client is going to connect to smtp.gmail.com. After establishing the connection via telnet (telnet smtp.gmail.com 587), the server (S) opens with a greeting:
S < 220 smtp.gmail.com ESMTP
C > HELO flowmailer.net
S < 250 Hello
Next, the client introduces itself by telling who the sender is. The server checks if the sender is OK.
C > MAIL FROM: firstname.lastname@example.org
S < 250 Ok
Now that the server has approved the sender's address, the client tells who the recipient is. Again, the server approves this.
C > RCPT TO: email@example.com
S < 250 Ok
Now that the server is familiar with the client, the sender, and the recipient, the client can start sharing data. This data consists of the subject line, the sender, the recipient, and the message's content. It looks something like this:
C > DATA
S < 354 Enter message, finish with '.' on a line by itself
C > SUBJECT: Your order is confirmed!
C > From: firstname.lastname@example.org
C > To: email@example.com
C > Contents of e-mail
C > .
After transferring the data, the client's job is done. After receiving a 250 OK response from the server, the connection terminates, and the email queues for delivery.
You'll notice two senders and recipients in the example above ('MAIL FROM' & 'RCPT TO,' versus 'From' & 'To'). This situation is similar to a regular envelope, where a mailman only sees the envelope ('MAIL FROM' & 'RCPT TO'), and the addressee reads the letter ('From' & 'To'). The mailman doesn't check the contents of the letter. That poses a problem. What if the envelope has a different sender on it then the letter itself?
SMTP is a somewhat insecure and spam-prone protocol. Since the old-fashioned protocol doesn't check the validity of the email per se, it is possible to fake your way to the customer's inbox. You can use a different name at the MAIL FROM and the 'From'-header, otherwise known as spoofing. Over the years, however, security measures were developed to protect both the MAIL FROM and the 'From'-header.
To protect their MAIL FROM address, domain owners can use the Sender Policy Framework (SPF). With SPF in place, the server s can now check if the MAIL FROM is valid. It checks if the sending IP address is authorized to send emails on behalf of the proposed sender.
DKIM, on the other hand, protects the From-header. Using a cryptographic signature, DKIM ensures the sender address and email content are valid. It makes sure that what the recipient sees is what they're supposed to see.
With SPF and DKIM in place, you can ensure that your domain is protected. With DMARC you prevent domain spoofing for good. DMARC tells the receiving server what should happen to emails that do not pass the SPF and DKIM checks.
All these measures would not have been possible if SMTP hadn't extended its functionality. To have more functionality than 'just send and receive emails,' ESMTP (E for Extended) was created in 1995. This variant of SMTP offers the possibility of email authentication and performance improvement.
SMTP is one of the oldest, but still the most common way of delivering emails. Though there have been massive improvements to the protocol over the years, it's not perfect from the start. You will need to authenticate your domain, get your IP reputation in order, and make sure the path to the inbox is as fast and secure as possible. By using Flowmailer's SMTP relay, you're removing the headaches of the email sending process. Try it yourself!