How to troubleshoot problems receiving external e-mail

We continue to accumulate logs, and the databases grow in size. We can send and receive e-mails in the network (a T1 with a firewall), but we are unable to receive outside e-mails, although we can send. Since we accumulate logs daily, the implication is that the mail comes in, but is not accessible via Outlook (the queue is empty). The system was working fine, and there have been no changes made in the last two years. The domain host was contacted, and a non-technical person responded with, "It's us, not them."

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT David Sengupta: Server Administration Changing email address formats in Exchange Server 2003 Should you remove .STM files from Exchange Server 2003? Exchange users receiving email addressed to legacy users Pushing a public calendar out from a private Exchange account Import and export .PST files in Exchange Server 2007 Editing Exchange Server public folder permissions Search and index Microsoft Outlook 2007 public folders Troubleshooting Microsoft Exchange Server Event ID error 6009 Can't delete old Microsoft Outlook public folders Can't create mailboxes after virtualizing Microsoft Exchange Server Microsoft Outlook Outlook 2007 shut-down problems and fixes Microsoft Outlook and SharePoint calendar dos and don'ts Free tools facilitate large-scale Outlook and SharePoint integrations Exchange Mailbag: POP3 settings and Outlook issues Pros and cons of Outlook 2007's storage engine redesign Fix Outlook 2007 and SharePoint synchronization breaks Email issues after configuring hosted Exchange server on laptop Avoid Outlook 2007 performance issues during repairs A behind-the-scenes look at Outlook 2007 and SharePoint integration When to use a self-signed certificate with Exchange Server 2007 Microsoft Outlook Research Microsoft Exchange Server Performance Remove Exchange 2003 objects from AD to install Exchange 2010 Outlook 2007 shut-down problems and fixes Is your Exchange 2007 hub transport server healthy? OWA 2007 configuration tricks to boost performance Pros and cons of Outlook 2007's storage engine redesign Avoid Outlook 2007 performance issues during repairs Monitor Exchange 2007 with disk- and RPC-related counters Track Exchange 2007 mailbox server health using database counters Monitoring Exchange 2007 Client Access Server role-specific counters Exchange Performance Monitor tracks domain controller communication

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary bacn  (SearchExchange.com) email bankruptcy  (SearchExchange.com) offline folder file  (SearchExchange.com) OST file  (SearchExchange.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

You didn't explicitly state this, but based on the two years of operations you allude to and your call to the domain host, I'm assuming that until recently your system accepted mail fine.

So, that said, I would start by doing some tests from outside your corporate network. For all intents and purposes, this could be a home machine connected to the Internet over a cable modem or similar. For the purposes of this discussion, I'll call your SMTP domain "company.com."

First, launch a command prompt and use NSLookup to check the public DNS record associated with your domain. See the following example:

> set query=mx
> company.com
Server: ns.myisp.somewhere.com
Address: 207.4.64.23

Non-authoritative answer:
company.com MX preference = 10, mail exchanger = aslan.company.com

Note that the first thing I did was use the SET command to scope the query to return only Mail Exchanger records. I then ran the query against the SearchExchange.com domain. I see that one MX record is listed, aslan.company.com. I also note that the record returned is "non-authoritative" since I'm pointing to my local ISP's server.

Now find the authoritative server:

> set query=ns
> company.com
Server: ns.myisp.somewhere.com
Address: 207.4.64.23

Company.com nameserver = caspian.narnia.com
caspian.narnia.com internet address = 207.7.1.1

At this point, just double-check the MX record held on the authoritative server to confirm it is also listed as aslan.company.com. You can do this using the same set of commands I used earlier. If there is a discrepancy, go to the hosting provider that looks after your public DNS record, and ask it why it made a change to your MX record.

Assuming there is no discrepancy, try telnetting to port 25 of the server listed in the MX record.

>telnet aslan.company.com 25

This pops you into a telnet session, and should display some sort of SMTP banner similar to the following:

220 aslan.company.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.211 read
y at Wed, 21 Sep 2005 19:15:48 -0700

If, for some reason, you don't manage to establish a telnet session, then this is where your problem lies. The server that 'the world' thinks is your public mail gateway is not, in fact, accepting connections on port 25, which is the port used for SMTP traffic. This is bad. (It is sort of like not having a mailbox out front of your house -- nowhere to put the mail!) This could be caused by server a misconfiguration or a firewall somewhere between the outside world and your mail gateway.

If you did manage to connect to the server, the next step is to issue telnet commands manually to send yourself a test message. The steps to accomplish this are outlined in Microsoft Knowledge Base article 153119, XFOR: Telnet to port 25 to test SMTP communication.

(I actually recommend that *anyone* who regularly works with Microsoft Exchange memorizes and practices the steps required to send a message via telnet. It's pretty simple to learn and this is an invaluable skill when it comes to troubleshooting.)

At this stage, it's quite likely that you'll get an error during the process of trying to send an inbound message. In that case, you need to take the specific error message (i.e., "relaying denied," etc.) and troubleshoot further from there. The server you're connected to (either your server or your ISP's, depending on your set up) is misconfigured.

I suspect that, by now, you have found your problem, and are well on the way to determining root cause. Once you have resolved the issue, you should be able to send yourself a message through the telnet session, just to confirm things are working.

If all of this still doesn't solve your issue, try using the Message Tracking Center to see where the message is going in your environment. Let me know how it goes, and if you have further questions!