We’ve all ran into those problems where all of our sudden, we can’t send email and we don’t know why, and don’t know what to do, besides call our email provider. One thing I’ve been focusing on at work lately is empowering our customers to “take ownership” of their servers, to help them figure things out on their own. The way I put it, being a server administrator is like getting married; “through good times and bad.” The problem is most administrators (or wannabe administrators) only want to be the admin when the server is running. Once there’s a problem, they expect us to be the admin. Sorry folks, but that’s not how it works.

Troubleshooting Email Issues

By and large, the biggest problem I see day in and day out is email related. Now granted, their are plenty of legitimate issues, things like getting flagged by a relay server’s spam filter or the relay server not accepting communications from a server. Those aren’t things a customer can do anything about. However, it is my firm belief that if you have a problem, you probably aren’t the first person in the world who’s had that problem. If you are, lucky you…and that sucks. Throw the error message (or description of the problem) into google and see what you come up with. The answer is often on the first page. Spend 10 minutes looking for a solution in google, and you’ll probably find it. But most people would rather send in a ticket and wait 2, 3, 4, or more hours for us to fix it, or tell them how to fix it.

So how can you tell if your email is really broken or not? Let me first say this guide is for people who use a hosted email service, not a free email service like Hotmail, Yahoo Mail, or Gmail. It may not even work if you are using a shared mail server through a large email provider. This will work best for you if you are using a virtual dedicated (virtual private) or dedicated (private) server that utilizes it’s own mail service independent of other users.

Remove all variables from the equation

Let’s say you can’t send your email out through Thunderbird (or Outlook if you choose to go that route). Regardless of the error you’re getting, try your webmail first. If it works through webmail, this will tell you if your mail service is at least working. Your webmail is going to use the same SMTP service that your mail client will. Chances are if you can send through webmail, the problem is local, either with your mail client configuration, or your ISP. If this is the case call your ISP. Many ISP’s will block outgoing communications on port 25, the standard SMTP port. This was the case with my ISP so I had to configure my Qmail to use an alternate port (but that’s another post – look online for the time being). Assuming all your settings are correct in your mail client (you’d be surprised how often this is the problem), we know it’s not a local issue. So you can’t send at all. Is it your local server? Or does your provider make you go through a relay server and that’s the problem? The best tool to troubleshoot your email is telnet.

Sending email through telnet

The first surefire way to test your email is by sending email through a telnet to localhost. This means connecting to your server either via SSH for Linux or Remote Desktop for Windows. If you are using Windows, open a command prompt first. At that point, the process is the same for Linux or Windows. Now, a few people will try this on their own, but often fail. The reason is that their email headers are not RFC compliant. Here is how to send a test email through telnet. Note: Your output may not be exactly the same as below. The bold code is the end user input, the italicized code is variable input/output.
telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 servername ESMTP
HELO localhost
250 servername
MAIL FROM: email address on your server
250 ok
RCPT TO: email address your sending to (off your server)
250 ok
DATA
354 go ahead
from: from address
to: to address
subject: any subject
body of message

.

250 ok 1244530643 qp 9552

A few notes, the data entry should be in the specific order above. There should be an empty line before and after the body of your message. End your message with a period to send it. The 250 ok line at the end means that the message was entered into your local mail queue. Check your from address for a bouceback message. No bounceback message means the message delivered ok.

Was the message accepted or did you get a bounceback?

If the message comes back, the second surefire way to test your email is by sending email through a telnet to your relay server. The process is the exact same as above, however replace localhost with your relay server’s name and follow the same steps. If the message is not accepted, contact your hosting provider. If it is accepted, check your from address for a bounceback message.

Either way, if you get a bounceback message, the first thing you should do is look at the bounceback error code. The error code will tell you the problem. Take that error code and put it into a search engine for additional information. You most common codes will be 553 or 554 (more on these in another post).

The bottom line is, test your email server through telnet first before assuming there’s a problem. Telnet will connect directly to the server on the specified port and will eliminate all external factors in troubleshooting the issue. Email issues are not as complicated to troubleshoot as most people believe. They just take a bit of time and patience.

Check out these Related Posts