Troubleshooting E-mail Problems

E-mail troubleshooting is one of the biggest challenges for IT professionals because e-mail is a distributed system making it difficult to isolate the source of a problem. The following steps will deal with the most common issues related to e-mail problems.

1. Manually connect to the SMTP server

   The best way to test SMTP connectivity is to manually run through the connection process. Manually connecting to a host will tell you a lot about where things are failing. The errors returned during the connection process are essential for further troubleshooting. This step can be used to troubleshoot inbound mail delivery or mail delivery to remote systems.
   
   Begin with at the command line, run the following commands:

   telnet
   set localecho to see the responses from the remote server
   open [mail server Fully Qualified Domain Name] 25
   HELO
   MAIL From: <[Your e-mail address]>
   RCPT To: <[Destination e-mail address]>
   DATA
   Subject: E-mail delivery test
   
   This is a test of the mail system, please reply to this message to provide confirmation of receipt.
   .
   QUIT
   

   Notes: The "<" and ">" in the MAIL FROM and RCPT TO lines are part of the RFC 2821 SMTP definition but only necessary for legacy or really picky systems. Most modern mail packages will accept input without the <> but some will not.
   Also, you must enter the period at the end of the message on a line by itself to end the message.

2. When troubleshooting delivery issues, it is best to run these commands from the outbound mail server, the one that is failing to connect to the remote host.

   Cannot receive mail

3. If mail is not flowing through the mail server, verify that the mail server is up and running using the manual connection steps outlined above. Any response is good, simply type Quit to end the SMTP connection. If the connection times out, then the SMTP service may be down. Finally, if there are errors returned, they provide a starting point for troubleshooting the error message.

   Mail returned as undeliverable

4. The most likely cause is that the mail server is not talking to the right host to deliver mail.

   Run nslookup to enter nslookup mode, then set type=mx to query for mail delivery records, and then type [domain name.domain suffix] to find the server mail should be delivered to for that domain. Open another command line window and try to connect to the destination mail server using the instructions above.

   If you cannot connect to that mail server, then you may be using stale DNS information; go to Network Tools and query DNS Records to find the authoritative name servers for that domain. Go back to nslookup and connect to one of the authoritative servers server [authoritative server FQDN] and rerun the MX record query. If the result is different from the original query, test the SMTP connection to the new host. If that works, flush the DNS cache on the servers the mail server is pulling DNS from and resend the message.

   If the remote host is dropping the connection, you may be listed as a sender of Unsolicited Commercial E-mail (UCE) a.k.a. Spam. Go to DNS Stuff and scroll down to the Spam Database Lookup to query for your mail server. If the result comes back ok, click the "Look up this host in non-ORDB RBL's" link to check other Real time Black hole Lists and make sure you are clear there.

   Still not getting through and you are not listed by any RBL? Make sure your ISP has a DNS reverse lookup PTR record for your mail server and that the name in the PTR record matches the name your mail server uses when sending mail out. You can check the name used by your server by looking at the message header from a message sent through your system to an outside account. Requiring proper reverse lookup information in DNS is a little extreme but some admins are doing it, even though it is not required in any of the SMTP standards.