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
|1.X.X||Addressing Status||The address status reports on the originator or destination address. It may include address syntax or validity. These errors can generally be corrected by the sender and retried.|
|2.X.X||Mailbox Status||Mailbox status indicates that something having to do with the mailbox has caused this DSN. Mailbox issues are assumed to be under the general control of the recipient.|
|3.X.X||Mail System Status||Mail system status indicates that something having to do with the destination system has caused this DSN. System issues are assumed to be under the general control of the destination system administrator.|
|4.X.X||Network and Routing Status||The networking or routing codes report status about the delivery system itself. These system components include any necessary infrastructure such as directory and routing services. Network issues are assumed to be under the control of the destination or intermediate system administrator.|
|5.X.X||Mail Delivery Protocol Status||The mail delivery protocol status codes report failures involving the message delivery protocol. These failures include the full range of problems resulting from implementation errors or an unreliable connection.|
|6.X.X||Message Content or Media Status||The message content or media status codes report failures involving the content of the message. These codes report failures due to translation, transcoding, or otherwise unsupported message media. Message content or media issues are under the control of both the sender and the receiver, both of which must support a common set of supported content-types.|
|7.X.X||Security or Policy Status||The security or policy status codes report failures involving policies such as per-recipient or per-host filtering and cryptographic operations. Security and policy status issues are assumed to be under the control of either or both the sender and recipient. Both the sender and recipient must permit the exchange of messages and arrange the exchange of necessary keys and certificates for cryptographic operations.|
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
|200||(nonstandard success response, see rfc876)|
|211||System status, or system help reply|
|220||<domain> Service ready|
|221||<domain> Service closing transmission channel|
|250||Requested mail action okay, completed|
|251||User not local; will forward to <forward-path>|
|252||Cannot VRFY user, but will accept the message and attempt delivery|
|354||Start mail input; end with <CRLF>.<CRLF>|
|421||<domain> Service not available, closing transmission channel|
|450||Requested mail action not taken: mailbox unavailable|
|451||Requested action aborted: local error in processing|
|452||Requested action not taken: insufficient system storage|
|500||Syntax error, command unrecognized|
|501||Syntax error in parameters or arguments|
|502||Command not implemented|
|503||A bad sequence of commands|
|504||Command parameter not implemented|
|521||<domain> does not accept mail (see rfc1846)|
|530||Access denied (???a Sendmailism)|
|550||Requested action not taken: mailbox unavailable|
|551||User not local; please try <forward-path>|
|552||Requested mail action aborted: exceeded storage allocation|
|553||Requested action not taken: mailbox name not allowed|
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.
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.
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 126.96.36.199 NS2.DOMAIN.COM 188.8.131.52
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: 184.108.40.206 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 220.127.116.11 mx.domain.com. 0 IN A 18.104.22.168 ns-166.awsdns-20.com. 0 IN A 22.214.171.124 ns-2022.awsdns-60.co.uk. 0 IN A 126.96.36.199 ns-683.awsdns-21.net. 0 IN A 188.8.131.52 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 184.108.40.206 mx.domain.com. 0 IN A 220.127.116.11
Verifying Email Delivery
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 18.104.22.168 25 Trying 22.214.171.124... Connected to 126.96.36.199. 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 [188.8.131.52] 250-SIZE 52428800 250-8BITMIME 250-PIPELINING 250-X_PIPE_CONNECT 250-AUTH PLAIN LOGIN 250-STARTTLS 250 HELP
Next, we tell the server who is sending the message by using the following command.
MAIL FROM: firstname.lastname@example.org
The server should respond with "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: email@example.com
If the server can verify the sender, the recipient, and other info, it tells us that the message is accepted.
Next, we enter the message itself using the “DATA” command.
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.
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.
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.
Our Sales and Support teams are available 24 hours by phone or e-mail to assist.