Whose Fault is It Anyway?

Unfortunately, even with the NDR codes to help and detailed SMTP logging turned on, there are a number of situations where it is still not obvious if the problem lies within your mail system or the destination domain's mail servers. That's where it helps to be able to be the mail server itself.

While to some extent that sounds crazy, it isn't actually that hard to pretend to be a mail server yourself because SMTP is a completely clear text protocol.
This should not be the first step in debugging an NDR. Other steps should be done first such as:

• Looking at the NDR code to determine the likely cause
• Verifying your mail servers are not on any black-lists (See below for instructions if you are not sure)
• Reviewing the SMTP logs
• Sending a small, unencrypted mail message

The basic process of simulating a SMTP session is laid out in MS KB153119, but it goes something like this:

Step 1: Lookup the mail server to use

At a command prompt, type NSLOOKUP. When nslookup returns with its prompt, type SET TYPE=MX. This will instruct NSLOOKUP to look for mail server records. At the prompt, type the domain name you wish to "send" the message to. This will be what appears after the "@" in the mail address (yahoo.com, gmail.com, etc) NSLOOKUP should return with a listing of all of the incoming mail servers for that domain and their preferences. In SMTP parlance, a lower preference number equates to a higher priority. i.e. messages should always be sent to the server with the lowest preference number that is available. In the example below, mail should be sent to the gmail-smtp-in.google.com host first.

Step 2: Connect to the host on port 25

At a command prompt, type telnet host 25, where host is the hostname determined in Step 1. Note: if using Windows 7 or Server 2008, there is not a telnet client installed by default, so you may need to substitute a different command such as Putty.

Step 3: Say HELLO

Upon successfully connecting, type EHLO domain, where domain is your domain name.

Step 4: Who is the mail message from

Upon accepting the domain name, one needs to explain who the message is from. This is done by typing the command MAIL FROM: address, where address is the from address. Note: some mail servers want the address enclosed in brackets. These servers usually give a clear text response indicating as such.

Step 5: Who is the message going to

Upon accepting the from address, one needs to explain who the message is going to. This is done by typing the command RCPT TO: address, where address is the to address. Note: some mail servers want the address enclosed in brackets. These servers usually give a clear text response indicating as such.
At this point if you haven't gotten any error responses from the remote server, the problem is likely within your own mail system. The only other explanation is there is something within the contents of the original messages that was blocking the message, which should have been flagged by sending the small, text only, test message. Ideally, you should have also put their mail domain in the connector properties of your TLS exempted send connector, so you can rule out mail encryption problems as well.
If you do get errors from the remote server (they should be very similar to those returned in the NDR messages), you don't have to just throw your arms up and say there is nothing you can do. Many organizations post a "Contact Us" form or phone number on their websites that can be used to explain the situation and help you get in contact with appropriate staff.

Note: To see if your mail server is on any of the common blacklists, simply navigate to mxtoolbox.com and use their Blacklist tool. Just enter the public IP address of your mail server, click on the Blacklist Check button, and in a few moments you will see whether that address is listed on any of roughly 100 public blacklists. If you find that your mail server address is blacklisted, don't panic. Simply browse to the main website of the blacklist your server is listed on and read for instructions on how to request to be removed. Many times, they will provide you with greater detail on why you were blacklisted in the first place, such as an open relay, unsolicited bulk email, etc. Simply correct that issue, request the delisting, and unfortunately wait. It often takes roughly 1 business day to get delisted.