What to Check When Exchange Cannot Send Email to Certain Domains

[Today's post comes to us courtesy of Shawn Sullivan]

“Unable to send email to certain domains” is a top call generator for Exchange issues on SBS. Due to its nature and the fact that all domains are not affected, the problem rarely lies with the SBS server. Several factors exist outside of the server configuration that can cause delivery failure to a remote mail server. This post is meant to be a quick guide to assist you in troubleshooting some common scenarios. It is not a comprehensive guide to SMTP troubleshooting.

First of all, **BE SURE TO READ THE NDR**. This is the most readily available piece of information that you have. It will tell you which mail server issued the notification and why, often leading you to the answer or at least in the right direction.

Who generates the NDR?

If the remote server accepts our message and then finds out after the fact that it cannot be delivered to the user’s mailbox, the remote server then must generate an NDR to notify the sender of the delivery failure. An example of this could be:

Your message did not reach some or all of the intended recipients.
Subject: test
Sent: 12/6/2007 3:35 PM
The following recipient(s) could not be reached:
User1 on 12/6/2007 3:49 PM
The message could not be delivered because the recipient's mailbox is full.
<contoso.com #5.2.2>

If the remote server does not accept our mail, it will issue an SMTP error, at which point our SBS server is responsible for generating the NDR. The NDR will include the SMTP error code. Here’s an example:

Your message did not reach some or all of the intended recipients.
Subject: test
Sent: 12/6/2007 4:14 PM
The following recipient(s) could not be reached:
user1@contoso.com on 12/6/2007 4:14 PM
The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address.
<adventureworks.com #5.1.1 smtp;550 5.1.1 User unknown>

If the message sits in the queue because the SBS server cannot connect to the remote server, then SBS will issue an NDR according to the expiration timeout configured on the SMTP virtual server. An example of this could be:

Your message did not reach some or all of the intended recipients.
Subject: FW: test
Sent: 12/4/2007 9:29 AM
The following recipient(s) could not be reached:
user1@contoso.com on 12/4/2007 9:35 AM
Could not deliver the message in the time limit specified. Please retry or contact your administrator.
<SERVER1.adventureworks.local #4.4.7>

This is important because the generation of NDRs by the SBS server does not automatically mean that the issue is with SBS.

Determining possible causes of an NDR

You can view the following Technet link for NDR diagnostic codes and troubleshooting tips:
http://technet.microsoft.com/en-us/library/bb124840.aspx

Common Scenarios

The following are common scenarios we see in support calls. As stated before, this list does not cover all possibilities, but provides a guide you can use to troubleshoot your incident.

• Blacklisting
• If your server has been reported sending spam, either directly or through unauthorized relay, then your server is probably blacklisted. If so, you will need to take the appropriate steps to secure your environment and contact the individual block lists to be removed. Microsoft has no control over 3^rd party blacklists.
• You can check your server’s status in several places. Examples include http://mxtoolbox.com/blacklists.aspx and http://openrbl.org
• Some blacklists may block by entire IP address ranges. Your server may be included in the range.
• An alternative is to relay your company’s email through a 3^rd party provided smart host. Email for your domain will not originate from the blacklisted IP address.
•  Connection Filtering
• Your email domain or individual IP address may be explicitly blocked by the remote server without the use of online blacklists.
• You will need to contact that organization to find out why.
• You can relay mail through a smart host if available.
• Improper DNS resolution of Remote Server
• It is possible that the remote domain is not blocking you at all, but that you are not even connecting to the correct server in the first place.
• You may be using a forwarder with a bad MX record for the remote domain. This can be configured in both the DNS management console under the server properties and on the SMTP virtual server properties in Exchange.
• You may be hosting an improper MX record for that domain (i.e. you may have created a zone in your DNS environment to hold it)
• You may have cached an invalid response. Flush your DNS cache and try again.
• Make sure that your hosts file is clean of invalid mappings to the remote server.
• You can verify the actual MX record for the remote domain by using http://www.checkdns.net/quickcheck.aspx and http://dnsstuff.com/
• You determine the IP address you are trying to connect to either in the SMTP logs or through a netmon trace.
• Port 25 blocked at the remote site
• Test this with a telnet to the remote IP on port 25
• For information on how to do this, see: http://technet.microsoft.com/en-us/library/aa995718.aspx
• Telnet will also tell you where you are failing in the SMTP communication, assuming the issue is not regarding TCP/IP connectivity
• Maximum Transmission Unit (MTU) and Black hole Routers
• A black hole router may exist between the SBS server and the remote mail server.
• If the SBS server is sending traffic that must be fragmented, but no ICMP control packet reaches SBS to let it know, then the traffic will be dropped without our knowledge.
• This can be proven with a simple ping test: ping remoteserverip –f –l 1472
• For more information on using ping to test MTU, see: http://support.microsoft.com/default.aspx?scid=kb;EN-US;159211
• PTR Record
• If the PTR record does not point your server’s IP address to its properly registered name, certain organizations checking for this will drop your connection.
• If you are planning on hosting multiple email domains from the same Exchange server on a single public IP, make sure you are allowed by your ISP to have multiple PTR records for the same IP address. If not, then the domain missing the record may be blocked occasionally.
• PTR records are created by and typically maintained by your ISP. They own the IP address that you have been assigned and should be the first point of contact if you are having problems with a record.
• Unlike A records, PTR records are not hosted by your DNS registrar; nor are they hosted by you even if you manage your own DNS namespace.
• Web sites you can use to check your PTR record include http://www.checkdns.net/quickcheck.aspx and http://dnsstuff.com/
• Sender ID
• If you are participating in the Sender ID Framework and have registered an improperly configured SPF (Sender Policy Framework) record, then you may be rejected by any mail server that checks this.
• If you are unsure of an existing SPF record or need to create a new one for your domain, visit the Sender ID Framework SPF Record Wizard: http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard
• Grey Listing
• If your queues are building due to incompatible retry intervals with the remote mail server, try adjusting the glitch retry interval: http://technet.microsoft.com/en-us/library/aa998772.aspx

Other Resources:

KB 256321 Enhanced Status Codes for Delivery - RFC 1893 http://support.microsoft.com/default.aspx?scid=kb;EN-US;256321

For SBS Monitoring Alerts not being delivered, see: http://blogs.technet.com/sbs/archive/2006/03/13/421943.aspx

For troubleshooting mail flow and transport related issues in Exchange, try the Exchange Troubleshooting Assistant: http://www.microsoft.com/downloads/details.aspx?FamilyID=4bdc1d6b-de34-4f1c-aeba-fed1256caf9a&DisplayLang=en

The Microsoft Exchange Team Blog: http://msexchangeteam.com/