Email Deliverability


Simple Mail Transfer Protocol (SMTP)

A comprehensible explanation of the standard email protocol

Richard van Looijen

Managing Director



Tom Blijleven

Marketing Manager



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.

Published in:

May 2021

What is SMTP?

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.

One language for all email traffic

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.

The SMTP protocol displayed where Sasha sends mails to Tom, Alice, and Mike

The technical operation of SMTP

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:

Example of the SMTP client-server communication

Suppose you want to deliver an email to a client who uses Gmail. The client is going to connect to After establishing the connection via telnet (telnet 587), the server (S) opens with a greeting:

S < 220 ESMTP
S < 250 Hello

Next, the client introduces itself by telling who the sender is. The server checks if the sender is OK.

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.

S < 250 Ok

The email content

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:

S < 354 Enter message, finish with '.' on a line by itself
C > SUBJECT: Your order is confirmed!
C > From:
C > To:
C >
C > Contents of e-mail
C > .

Closing and terminating SMTP connection

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.

The analogy of the mailman

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?

Limitations of SMTP

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.

The DMARC protocol checks for DMARC alignment for the sending domain - checking SPF and DKIM alignment


Simple Mail Transfer Protocol (SMTP)

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!

Richard van Looijen

Managing Director



One of the founders and currently Managing Director of Flowmailer, Richard is a tech geek by heart and loves to spread his ideas and views on how email works and should work.

Tom Blijleven

Marketing Manager



With years of experience in the email (marketing) industry, Tom currently manages the marketing department at Flowmailer. In this role, he mainly writes about transactional email, email deliverability, and the API-first economy.

Want to stay up to date on Flowmailer resources?