Lessons Learned

First, you need to know how your Exchange server is delivering mail. It will either be using DNS to route e-mail directly to the recipients mail servers or it will be using a smarthost to handle all routing of e-mail for it. Hopefully, you already know how your mail server is set to send mail. But if you do not, here's a quick way to check:

1. Open Exchange System Manager.
   
2. Expand Servers, your server name, Protocols, and SMTP.
   
3. Right-click on the Default SMTP Virtual Server and select Properties.
   
4. Select the Delivery tab, and then click Advanced.
   

If a server name of IP address in brackets is listed in the Smart host field, you are using a smarthost for mail delivery. Otherwise, you are using DNS.

Whether you are using a smarthost or DNS for mail delivery, start your troubleshooting by attempting to make an SMTP connection to a known-good mail server. You'll do this using the telnet command from a command prompt. Open a command prompt on the Exchange server, and type the following command:

telnet mailservername 25

where mailservername is the name of your smarthost or another known good mail server. smtp.google.com and maila.microsoft.com are good test sites. Press Enter at the end of the command.

Ideally, you will see something like this after you hit Enter (this example uses smtp.google.com):

220 smtp.google.com ESMTP

This means that you made a successful outbound connection to an external mail server. More likely, however, you will not see a message like this if you have been having mail delivery problems. You may get the following response instead:

Connecting To mailservername...Could not open connection to the host, on port 25: Connect failed

There are basically three reasons you would get this message: DNS failed to find the server name, you cannot reach the server across the net, or the server refused connection on port 25. Testing for DNS failure is simple. Type the following at the command prompt and press Enter.

ping mailservername

If you have DNS lookup failures, you will get the following response:

Ping request could not find host mailservername. Please check the name and try again.

If that's the case, you have a DNS issue and can now troubleshoot that, which will likely resolve your mail delivery issues.

If you get a set of "Request timed out" messages from the ping command, you might have network routing issues that are keeping you from connecting to the remote site. You can test this by running the tracert comand, or you can try to telnet to a different mail server. If it works, you know you have a network routing problem (probably not through any fault of your own) getting to that site and probably others, and that should clear up "on its own." Unless, of course, the site you're trying to contact is your ISP's smarthost, in which case it's time to pick up the phone and call them.

If you're still having trouble at this point and you have not tried to connect to your ISPs mail server with telnet, try that now. If you get a "220" response similar to the one noted earlier, you may be involved in that special case where your ISP is blocking outbound SMTP traffic from their network. This is becoming more common as a way for ISPs to attempt to curb the spam problem. It's not a deal-breaker for you, it just means that you need to set up your Exchange server to deliver mail through your ISP's smarthost instead of direct delivery with DNS. But if you can't connect to you ISP's smarthost after failing to connect to other external mail hosts, you're dealing with a networking issue and need to troubleshoot at that level.

It's also worth noting at this point that a number of mail systems, most notably AOL, are beginning to reject incoming mail connections from systems that they have decided are "mail risks." There are a number of ways they use to determine if a site is a mail risk. Some use the Reverse DNS lookup -meaning that your "from" domain does not match the reverse DNS entry for your network connection. Others have decided to refuse connections from any dynamic IP address ranges. Unfortunately, these address ranges may still include static IPs for business-class DLS subscribers with some ISPs, simply because the addresses are in a "dialup" range as identified by the ISP. The best way to get around these problems is to configure your Exchange server to deliver all outbound mail through a smarthost. Doing so cuts down greatly on the chances that your mail is going to be refused by a remote mail system.

In summary, there are a few key mail flow problems that can be identified in a few simple steps. These are:

1. Run telnet to a mail server on port 25. If you can connect, you are likely being refused delivery for some reason and can resolve that by routing your mail through your smarthost.
   
2. If the telnet fails, try to ping the mail server. You may get a DNS lookup failure, which leads you to troubleshoot your DNS setup to resolve.
   
3. If the ping requests time out, you either have a network connectivity issue or your ISP may be blocking outbound SMTP traffic. you can test this by trying to telnet to another mail host or your ISP's mail host.

By no means is this an exhaustive troubleshooting process for outbound mail flow issues. But it does cover key issues that cause the majority of mail flow problems, especially when outbound mail flow stops working suddenly.