Some companies, including Microsoft, have decided to block any inbound email messages originating from a dynamic IP address in an effort to prevent spam. Unfortunately, while almost every large company uses a static IP address for its Exchange servers, smaller companies are often forced to use dynamic IP addresses.
Fortunately, you can configure Exchange Server to route mail through your ISP's SMTP server, so it appears to recipients as if the message came from the ISP's static IP address instead of your organization's dynamic IP address.
How to route Exchange Server email through an ISP's SMTP server
How to configure Microsoft Exchange Server to route mail through your ISP's SMTP server varies depending on the versions of Exchange Server that you are running. In Exchange 2000 and Exchange 2003, the SMTP connector replaces the Internet Mail Service used in earlier versions of Exchange Server.
For the purposes of this tip, I will assume that your Exchange Server deployment is running in mixed mode, and that you will need to create an SMTP connector. If you already have an SMTP connector in place, you can modify your existing connector rather than creating a new one.
- Open Exchange System Manager.
- Navigate to Administrative Groups -> your administrative group -> Routing Groups -> First Routing Group -> Connectors.
- Right click on the Connectors container and select New -> SMTP Connectors to view the new connector's properties
- Go to the General tab and enter a descriptive name for the connector into the space provided.
- Just below the Name field, you are given the choice of using DNS to route messages to each address space on the connector, or to forward mail through a smart host. Choose the smart host option and then enter the IP address of your ISP's SMTP server into the space provided.
- At this point, you must designate an SMTP virtual server to act as a local bridgehead server. To do so, click the Add button and then select the server that you want to designate as the local bridgehead.
- To define an SMTP address space, select the Address tab and then either the Entire Organization or the Routing Group option to set the scope of the address space that you are about to define.
- Click the Add button, select the SMTP option, and click OK.
- You will now see a dialog box asking for an email domain and a cost. Go with the defaults and click OK to be taken back to the Address Space tab.
- Verify that the "Allow Messages to be Relayed to these Domains" checkbox is not selected -- otherwise, the entire world may be able to relay mail through your Exchange Server.
- Go back to the Advanced tab and click the Outbound Security button to view the Outbound Security dialog box.
- Most ISPs require the Outbound Security option to be set to Anonymous Access, but you should check with your own individual ISP to see what settings they want you to use.
- Click OK repeatedly until all of the open dialog boxes are closed.
- Now verify that the SMTP virtual server you designated to act as a local bridgehead is configured to listen on TCP port 25 by navigating to Administrative Groups -> your administrative group -> Servers -> the server that's hosting the designated SMTP virtual server -> Protocols -> SMTP -> the designated SMTP virtual server.
- Right click on the designated SMTP virtual server and select Properties.
- Go to the General tab and click on the Advanced button.
- Verify that the SMTP virtual server is configured to listen on TCP port 25. If the designated port is something other than 25, you can use the Add button to add port 25 to the list of ports.
- Your Exchange Server should now be configured to route outbound SMTP email through your ISP's SMTP server. To complete the process, simply restart the Microsoft Exchange Routing Engine service and the server's SMTP service.
Make sure your ISP isn't on any spam blacklists
Routing email through an ISP's SMTP server may not be enough to prevent your organization's email from being treated as spam.
There are numerous spam blacklists, and your ISP's SMTP server could potentially be listed on any of them. In the past, it has been a very tedious process to search through all of the blacklists to see where a block was coming from.
I recently discovered a handy Web site called DNSstuff.com that makes the process of searching the spam blacklists a lot easier. The site isn't solely dedicated to searching spam blacklists, but the front page offers an option to enter your (or in this case your ISP's) mail server's IP address. It will then check all of the spam blacklists to see if the IP address appears on any of them.
In all likelihood, your ISP's mail server isn't blacklisted, but it's still good to check to be sure. Running a quick scan of the blacklists up front can save you hours of pointless troubleshooting if your ISP is blacklisted and causing email delivery issues.
If you've verified that your ISP's SMTP server is not on a spam blacklist, but your organization's email still isn't being delivered, it's possible that the domains rejecting your email are using extremely restrictive spam filters.
Some filters will not only block all dynamically assigned IP addresses, but also email from any organization whose DNS server is not configured to meet the service's specifications.
One example of an overly restrictive spam filter is the SORBS Dynamic User and Host List (SORBS DUHL), which was originally intended to be a list of dynamically assigned IP address ranges. The idea was that organizations could reduce spam by blocking inbound email from any IP address within a listed range.
But as I outlined above, there is a simple technique that circumvents detection of your organization's IP dynamic IP address by routing mail through your ISP's SMTP server, which has a static IP address.
Spammers know this trick too. So if the absence of a dynamic IP address were the only criteria that SORBS used for blocking spammers, the list of dynamically assigned address ranges would quickly become useless. That being the case, SORBS came up with some additional requirements:
- The MX record of a domain needs to contain a host name that maps to the IP address involved. The "Time to Live" of the MX record needs to be at least 43,200 seconds.
- The A record for the host name needs to have a TTL of at least 43,200 seconds.
- The reverse DNS PTR record for the IP address involved needs to map back to the name given in the MX record, and to have a TTL of at least 43,200 seconds.
- If there are multiple MX entries, these rules apply to them all.
Organizations that filter email based on the SORBS-DUHL exclusion list are bound to reduce the amount of spam they receive, but they also risk making themselves inaccessible both to clients and potential clients, so I personally think this practice is a bad idea.
Even though I disagree with using the SORBS-DUHL exclusion list to filter spam, you can't ignore its requirements. Microsoft is only one of many companies now filtering inbound email using the SORBS-DUHL standards. So you might want to think about configuring your domain's DNS records to match the SORBS-DUHL requirements as a precaution.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Please let others know how useful this tip was via the rating scale below. Do you have a useful Exchange Server or Microsoft Outlook tip, timesaver or workaround to share? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank-you gift.
This tip was originally published by SearchExchange.com.
This was first published in August 2006