How to Troubleshoot SMTP Errors: Part 1

What is SMTP?

The Simple Mail Transfer Protocol (SMTP) is a communication protocol used to transmit email between corresponding email servers. Using an email client like Mac Mail, Outlook, Thunderbird, or web clients like Gmail or Windows Live, SMTP can send messages to an email server. Although SMTP was initially designed as an email transport and delivery system, it later encompassed the email submission protocols that are now in use by both the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP). The above-noted email clients use these protocols to retrieve email from an email server. When this system fails, it provides the means to identify and resolve SMTP errors.

How Does SMTP Work?

When an email is sent, the email client will authenticate itself to the email server by providing the username and password associated with the email account. If the credentials are valid, the user’s email is acknowledged, analyzed, and forwarded to the recipients' destination. If authentication falters, an SMTP error message is created and logged on the server and usually in the client’s email software.

What Happens if the Service Breaks Down?

We have all experienced problems with email. When this occurs, not only does the email not go through, but a failure message is sent, and a log entry is created on both the sending and receiving email servers. The log entry contains a considerable amount of information. One part of those log entries is called a status code.

SMTP Status Codes

A status code is a numerical designation provided by SMTP attached to each email message sent or received, denoting what was done with the message. We can reference this number to gather necessary information on why the failure occurred and what is needed to repair the issue. When we review that code, we can use the status code’s information to determine why the email failed to send. 

SMTP Response Codes

The first number listed in the general response code denotes whether the server’s response is good, bad, or incomplete. The general response code numbers range from one through seven and cover all of the problems incurred when an email failure happens. These codes are always seen in the server logs. These error messages contain broad meanings that are easily found online and referenced below.

General Response Codes

There are more than eighty sub-codes that further define the responses into more specific error categories. We can review these codes to determine how to troubleshoot our SMTP errors.

SMTP Status Code Meanings

Below are some of the most common status codes and their meanings

Troubleshooting SMTP

Below are the steps taken when an email error occurs. These steps are nearly identical in all circumstances. The only exception is when the issue is visible to the systems administrator. 

Gather Information

Our first step is to gather information. We begin by answering these basic questions.

• Am I connected to the Internet?
• Are my email client account settings correct?
• Is my antivirus software enabled? This can block emails from being sent.
• Is my firewall running? This can block emails from being sent.
• Have I seen any suspicious email messages in my mailbox?
• Are there problems sending or receiving emails? Or both?
• Is just one account affected or multiple accounts?
• What is the email address(es) experiencing issues? Or domain if multiple.
• Are there any bounces or error messages occurring?
• Was DNS for the domain changed recently?
• Can I connect to and send/receive emails from my webmail account?
• Which email client are you using?

Answers to these questions will allow our admins to deduce where the error is originating quickly. 

Locating the Authoritative Nameservers

If, by chance, any DNS records have changed in the preceding 24 hours, this could be the cause of the errors. Sometimes, the propagation of new records can be delayed if the nameservers’ owner has longer TTL (or Time to Live) times configured. To locate the authoritative nameservers, we need to run the whois command to find that information.

whois domain.com

This command will return a significant amount of info. The part we are interested in is below.

Domain servers in listed order:

NS1.DOMAIN.COM            210.60.130.21
NS2.DOMAIN.COM            65.81.241.154

Using this information, we can check to ensure that the nameservers are listed at the registrar. This also indicates that they are resolving correctly to the proper address. Again, we use the whois command to verify this.

root@host:~# whois ns1.domain.com
   Server Name: NS1.DOMAIN.COM
   IP Address: 66.96.142.147
   Registrar: Domain.com, LLC
   Registrar WHOIS Server: whois.domain.com
   Registrar URL: http://www.domain.com
>>> Last update of whois database: 2021-02-16T17:42:44Z <<<

If there is no IP address associated with this nameserver, we know the domain is not resolving correctly, and the email will not go through. 

Querying the Nameservers for MX Records

The MX records for a domain tell other servers on the Internet which hosts accept email for a domain. If your email is being hosted on a server at Liquid Web, that server’s hostname should be in the MX record. When we find this information, we use the dig command. This command looks up various types of DNS records. 

root@host:~# dig mx domain.com

; <<>> DiG 9.16.1-Ubuntu <<>> mx domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19270
;; flags: qr rd ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;domain.com.                    IN      MX

;; ANSWER SECTION:
domain.com.             0       IN      MX      10 mx.domain.com.
mx.domain.com.          0       IN      A       66.96.140.72
mx.domain.com.          0       IN      A       66.96.140.73
ns-166.awsdns-20.com.   0       IN      A       205.251.192.166
ns-2022.awsdns-60.co.uk. 0      IN      A       205.251.199.230
ns-683.awsdns-21.net.   0       IN      A       205.251.194.171
ns-2022.awsdns-60.co.uk. 0      IN      AAAA    2600:9000:5307:e600::1

;; Query time: 80 msec
;; SERVER: 172.29.80.1#53(172.29.80.1)
;; WHEN: Tue Feb 16 12:49:51 EST 2021
;; MSG SIZE  rcvd: 274

root@host:~#

As we can see in the answer section, the MX records are noted in response to that command.

mx.domain.com.          0       IN      A       66.96.140.72
mx.domain.com.          0       IN      A       66.96.140.73

Other commands besides dig, like host and ping, can provide this information as well. Other onlinetools that can resolve domain names will typically provide us with the data we need. 

Verifying Email Delivery

Using Telnet

If all of the above domain information is resolving correctly, we can then test the server. For this task, we use the telnet command. Using the telnet command, we can log into the server using port 25 (the default SMTP port). 

Note: It can take a minute or two for the server to return the 220 responses seen below. This is normal.

root@host:~# telnet 66.96.140.72 25
Trying 66.96.140.72...
Connected to 66.96.140.72.
Escape character is '^]'.
220-host.domain.com ESMTP Exim 4.94 #2 Tue, 16 Feb 2021 13:04:21 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.

Once connected, we will see a banner message similar to the one above. To interact with the server, we issue the “EHLO” command and our hostname. Typically, the hostname does not matter because the SMTP server we are connecting to will look up the RDNS (reverse DNS) info for the IP we are connecting to.

EHLO server.liquidweb.com
250-host.server.com Hello host.server.com [65.21.72.171]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-X_PIPE_CONNECT
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP

Define Message

Next, we tell the server who is sending the message by using the following command.

MAIL FROM: user1@liquidweb.com

The server should respond with "250 OK.”

250 OK

Now, we can enter the recipient's email address using the "RCPT TO:" command. The sender and recipient can have the same email address.

RCPT TO: user2@liquidweb.com

If the server can verify the sender, the recipient, and other info, it tells us that the message is accepted.

250 Accepted

Send Message

Next, we enter the message itself using the “DATA” command.

DATA

The server responds by telling us to enter the email message.

354 Enter message, ending with "." on a line by itself

Now, we enter the subject line of the email (this is not a server command). After we add this info, we hit Enter twice to signal the end of the headers and then enter the message's body.

Subject: test message

Hello, this is a test message.

.

Once the message has been typed, add a "." on a line by itself. This lets the server know our message is complete. The server then assigns the message an ID and says, "250 OK id=messagenumbersandletters.”

250 OK id=1JR2se-0201DI-Cq

Once we see the “250 OK” output, this indicates the email message has been sent. We can close the connection by typing the "QUIT" command.

QUIT
The server announces that it is going to close the connection and then does so:

221 server.liquidweb.com closing connection
Connection closed by foreign host.

We know our email went through as it used the 250 status code, so we know the issue is not with SMTP on the server. 

Using Webmail

We can also verify a working connection using the webmail client attached to our domain. If we visit https://host.server.com:2096/, cPanel will show us the webmail login screen. 

Once we login to webmail, send a test email to a secondary email address that is working. If the email is sent and received successfully, we know the outbound mail server functions as intended.

Now, reply to the email from the secondary email address. If we receive the email in the webmail interface, the inbound email server is working as well. This tells us the issue is not on our server. 

If for some reason, we are not able to send, our next step is to check the email log entries for error codes. We will review the steps to address this further down in the article.

Conclusion

We pride ourselves on being The Most Helpful Humans In Hosting™! Our Support Teams are filled with experienced Linux technicians and talented system administrators who have intimate knowledge of multiple web hosting technologies, especially those discussed in this article. Should you have any questions regarding this information, we are always available to answer any inquiries with issues related to this article, 24 hours a day, 7 days a week 365 days a year.

If you are a Fully Managed VPS server, Cloud Dedicated, VMWare Private Cloud, Private Parent server, Managed Cloud Servers, or a Dedicated server owner and you are uncomfortable with performing any of the steps outlined, we can be reached via phone at 800.580.4985, a chat or support ticket to assist you with this process.