Determining possible causes of an NDR

Determining possible causes of an NDR

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 andhttp://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.aspxand 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 andhttp://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

•