SMTP, or Simple Mail Transfer Protocol, is a standard method by which email clients handle message exchange. As with other protocols, SMTP includes a series of rules that permit the exchange of information between various accounts across email clients.
SMTP is one of the most commonly used protocols worldwide. In fact, SMTP is the only dedicated protocol used for sending emails between servers, and the majority of the world’s most popular email clients – such as Outlook and Gmail – use SMTP.
The complete
deliverability
handbook
Read the most significant, most organized volume of information written about email deliverability.
As such, it is helpful for email marketers to have a strong understanding of the purpose and functions of SMTP and SMTP relays.
So, how can one best define SMTP dialog?
In simple terms, SMTP dialog refers to a series of commands and responses that occur between two servers, and comprises a broader interaction between SMTP servers, known as the “SMTP conversation.”
When does the SMTP conversation occur?
There is a considerable amount that happens before the SMTP conversation commences.
First, an email user creates and attempts to send an outgoing mail message. Next, the user’s email client connects to a server that handles outbound emails.
The outbound server then agrees to deliver the mail on behalf of the client and attempts to determine the email’s destination using the email domain of the recipient.
Once it has done this, the outbound server makes a request to the Domain Name System (DNS) to provide a list of servers that accept email for that domain. From there, the outbound server attempts to establish a connection with the server that will accept the email on the recipient’s behalf.
When this has been achieved, the two servers can enter into a dialog of back and forths that comprises an SMTP conversation.
via email
By signing up you are agreeing to our Terms of Service
Your data will be handled in accordance with our Privacy Policy
How does the SMTP dialog function?
As previously explained, the dialog of an SMTP conversation consists of commands and replies between two servers. The commands in question are sent by the outbound mail server, and the replies are sent by the receiving mail server.
The commands issued by the outbound server are known as “verbs” and consist of a short sequence of letters, whereas replies from the receiving server consist of text messages preceded by short numeric codes.
By exchanging these commands and replies, the two servers can identify not only themselves, but also the details of email participants and the result of an attempt to send an email. This is why email users often encounter error messages containing SMTP codes when a failure to send occurs.
The SMTP dialog continues until all the receiving server has received and accepted all of the information being sent from the outbound server. Once this has happened, the outbound server sends its final command to end the dialog.
When the receiving server has accepted the email and the SMTP dialog has ended, the email is subject to anti-spam scanning and DMARC (Domain-based Message Authentication Reporting and Conformance) checks, after which it can finally be delivered to the inbox of its recipient.
Why it pays to know about SMTP dialog
As an email marketer, SMTP issues can be frustrating due to how they hinder the effectiveness of your work.
Analyzing SMTP conversation logs can help you understand what has gone on between two servers in the case of an error, helping you more quickly uncover the root of your problem.
To this end, it follows that you will want to be aware of the most common commands and responses given by clients and servers during an SMTP conversation.
The Email Marketing Activity Book for Kids
Basic SMTP commands to be aware of
The following are some of the most commonly used basic SMTP commands, all of which are mandatory elements of an SMTP dialog:
- HELO/EHLO
- MAIL FROM
- RECPT TO
- DATA
- QUIT
HELO/ EHLO
The HELO command is the first command issued in an SMTP session and begins the process of sending an email. The email client uses the HELO command to identify itself when connecting to the SMTP server. This is usually followed by the domain name or IP address of the SMTP client.
The EHLO command is an alternative that serves a similar purpose to the HELO command for servers that can support ESMTP (Extended Simple Mail Transfer Protocol).
MAIL FROM
Once the SMTP client has issued the first command, identified itself, and received a response, the sender will issue the MAIL FROM command.
This command shares information pertaining to the origin of the email being sent, such as the email address, and informs the SMTP of an impending exchange. If accepted, a 250 OK response code will appear.
RECPT TO
The SMTP client issues the RECEPT TO command following the receipt of the 250 OK code. The purpose of this command is to specify the recipient of the email being sent.
As with the previous command, the server responds to this with a 250 OK code to signify that it has accepted the data.
This process is then repeated the appropriate number of times according to how many email recipients there are.
DATA
The client sends the DATA command to the server to request permission to transfer the email data. In response, the server sends a 354 code which signifies that permission has been granted.
At this point, the client begins to transfer all the data contained in the email to the server. This data includes headers, dates, subjects, the message body of the email, and any attachments. Once the client has transmitted all of the data in the email, it ends with a final line that contains a period mark to signify the end of the transfer.
After this has taken place, the server responds with a further 250 OK code, indicating that the mail message has been accepted and is now en route to its intended recipients.
QUIT
Once the email has been sent successfully, the client issues the QUIT command. This command is the final part of the SMTP dialog. It signifies the end of the SMTP conversation between the client and the server and informs the server that it will terminate the connection.
When the server receives this command, it replies with a final 221 code, informing the client that the connection has been successfully severed.
Other SMTP commands
While each of these commands is a mainstay in any SMTP dialog, there are other commands which are used less frequently but are nonetheless useful to know when it comes to analyzing SMTP conversation logs. These include:
- VRFY
- EXPN
- HELP
- RSET
- NOOP
VRFY
The client sends the VRFY command to request verification that a specific email address or username exists on the server. Then the server responds accordingly with either a 250 code to signify that the address is local or a 251 code to indicate that it is not.
EXPN
The EXPN command exists so that the client can request verification of a mailing list that exists on the server. If it is present there, the server responds positively and provides specifications pertaining to the recipients on the mailing list.
HELP
The HELP command indicates that the client requires support from the server, and the server offers a list of supported commands in response.
The client may combine this command with an argument specific to what it requires from the server. If the command is supported, the server will retrieve the requested information.
RSET
The client sends the RSET command to the server to indicate that the mail transaction should be canceled for some reason. When this command is sent, the server will respond with a 250 code to confirm that a reset will take place.
When this occurs, the server erases any prior data about the mail transaction and email participants involved therein. However, the server does not sever the connection upon receipt of this command. Rather, it keeps it open so that a new mail transaction can begin.
This command is typically used in situations where the conversation must be restarted as a result of an error that has occurred at some point in the SMTP dialog.
NOOP
The NOOP, or “No Command,” command is sent from client to server in cases where no interaction is occurring in the SMTP conversation. It does not produce any result other than to elicit a 250 response code in order to keep an SMTP connection active.
Extended SMTP commands
Extended Simple Mail Transfer Protocol, or ESMTP, is an extension of SMTP which is intended to provide higher levels of functionality and security to help protect servers.
ESMTP has a wide range of useful features that includes SSL encryption, multimedia file attachment, and sender authentication.
There is also a selection of extended SMTP commands that are used in conjunction with those above. Below are some of the most common:
- STARTTLS
- AUTH
- ETRN
- BDAT
STARTTLS
The client issues the STARTTLS command to initiate a TLS (Transport Layer Security) handshake with the server. This commences a secure SMTP session between the two parties.
In response, the server will send a 2220 code, signaling that it is ready to begin an SMTP dialog. From there, the client will proceed with the HELO or EHLO command to begin the SMTP conversation as normal.
AUTH
The purpose of the AUTH command is to authenticate the client on an SMTP server. This enables the client to avail of certain privileges on the server. The AUTH command can include one of four keywords that provide specifications relating to security levels and login methods, including: LOGIN, PLAIN, MD5, and CRAM-MD5.
This command is subsequently followed by a request for a username and password. Once the correct information has been provided and the server has given a positive response, the SMTP session is considered authenticated.
ETRN
The ETRN, or ”Extended Turn”, command is an extended SMTP command. The purpose of the ETRN command is to enable the SMTP client to order a server to send all mail it may have.
Once the command is accepted, the server responds with a 250 OK code, at which point it will commence processing message queues.
BDAT
The BDAT command can be considered an extended alternative to the DATA command, as it is also a request to transfer email data.
Specifically, the BDAT command is used for the transfer of large MIME (Multipurpose Internet Mail Extensions) messages, which might include various types of data such as audio, video, images, or applications.
What do SMTP response codes mean?
As previously mentioned, SMTP response codes are codes sent from the server to the client in response to an issued command. In cases where emails bounce or are blocked, it is helpful to understand what makes up an SMTP response as this makes the troubleshooting process much simpler.
SMTP response codes are three-digit sequences, and each digit represents something different. Below are the numbers most commonly seen in SMTP codes, as well as a short run-down of what each digit represents.
The first digit
With few exceptions, the first digit typically ranges from 2 – 5 and indicates the status of a request as below:
- 2: Indicates a positive completion reply, meaning that the request has been accepted and completed.
- 3: Indicates a positive intermediate reply, denoting an accepted request for which more information is required.
- 4: Indicates a soft bounce, meaning the command was declined and not completed. This is also known as a transient negative completion reply. It is a temporary rejection, so a sender may attempt the command once more at a later point.
- 5: As with ‘4’ above, this indicates that a command was declined and the desired action was not performed. However, this is known as a hard bounce and represents a permanent issue. As a result, the command will not be attempted again.
The second digit
The second digit in an SMTP code indicates the nature of the response as follows:
- 0: Denotes a response related to syntax.
- 1: Denotes a response to an informational request.
- 2: Denotes a response pertaining to the status of the SMTP connection.
- 5: Denotes a response relating to the status of the inbound email server.
The third digit
The third digit can have a wider variety of meanings and provides more specific information related to the specific category indicated by the previous digits.
Understanding common SMTP error codes
As previously mentioned, SMTP response codes that begin with ”4” and ”5” denote temporary and permanent errors, respectively. In cases where an error occurs, it is useful to understand the specific issue associated with a given code, so below are brief explanations of some of the most common SMTP error codes:
SMTP 400 codes (transient errors)
- 421: The 421 code indicates a problem with the SMTP connection. This means that the mail transaction has failed and will be re-attempted at a later point.
- 450: This code indicates that the receiving mail server cannot locate the recipient’s email address. This may be due to a lack of permission, an address that has been input incorrectly, or a failure to pass a filter.
- 451: Error code 451 indicates that a server error has resulted in the abortion of a command. This may be due to authentication issues or the user exceeding the server’s mail limits.
- 452: Error code 452 denotes that the server lacks sufficient storage space, resulting in the abortion of a request.
- 455: The 455 code indicates that the server cannot accommodate the parameters of a given command, typically a MAIL FROM or RECPT TO command.
SMTP 500 codes (permanent errors)
- 500: This code signifies an error in the syntax of a command, meaning that the server cannot recognize it. This could be the result of an unsupported command. In some cases, it can also be due to conflict with antivirus software or a firewall.
- 501: Error code 501 indicates an error in the syntax of arguments or parameters associated with a given command. Typically, this results from an invalid recipient email address, but it can occur due to antivirus or firewall software.
- 502: This code indicates that the client has issued a command that has not been performed. This typically means that the command itself is valid, but that the receiving SMTP server does not support it.
- 503: Code 503 signifies that a bad command sequence has been entered. This means that while the command itself is valid, the associated parameters have been incorrectly ordered.
- 504: The code indicates that the client has issued a command whose parameters have not been applied. This typically means that while the command is valid, the server does not support the parameters associated with it.
- 541: This error occurs when the receiving mail server refuses to accept the email being sent. This can be a result of a spam filter or due to the sender’s reputation.
- 550: Error 550 indicates that the mailbox of the recipient is unavailable. This could be because the address does not exist, or because it has been input incorrectly.
- 551: This error denotes that the recipient of the email cannot be found on the server. This is a common spam prevention tactic, and the error may occur when the client lacks the correct SMTP authorization.
- 552: This code is given when an action is canceled due to the recipient exceeding its storage allocation. This means that the recipient’s email inbox is full.
- 553: Error 553 occurs when the recipient’s mailbox name is not allowed. This means that the sender has attempted to send a mail message to an invalid email address.
- 554: Error 554 typically results from a failed email transaction between the outbound server and the receiving server. This means that the server would not accept the mail being sent. There are a variety of possible reasons for this, such as an invalid address, a disabled account, or a blacklisted sender IP address.
Of course, there exist other SMTP codes which are not featured here, but those listed above are the most common ones you may encounter.
Summing up
Email marketers send a high volume of outgoing emails on a daily basis. Understanding how the Simple Mail Transfer Protocol (SMTP) works and what takes place throughout an SMTP dialog is important to trouble and resolve common issues that arise throughout this process.
To this end, it is highly beneficial to know the most widely used SMTP commands, as well as the response codes produced by receiving SMTP servers.
Login