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 Exchange 2000 Server Troubleshooting Outlook calendar errors on a BlackBerry device How to move Exchange 2000 to new server hardware Error 1053: Exchange System Attendant service could not start Solve server problems with the Exchange Troubleshooting Assistant tool Move mailboxes to Exchange 2007 after Windows upgrade Third-party tools that modify NDRs for oversized email IP address changes for an Exchange 2000 recovery server Exchange Server 2003 tips and tricks -- 7 tips in 7 minutes How to enable Exchange Server public folder logging Deciphering an 0xc103798a Exchange Server setup error code Microsoft Exchange 2000 Server Research Microsoft Outlook Stop personal calendar appointments from showing on Exchange Server Relocating Outlook email messages on a hosted Exchange 2007 server Creating Meeting Workspaces in MOSS 2007 and Outlook 2007 Control Outlook 2007 in cached mode settings with group policies Sending poll questions through Exchange to non-Outlook users Sort Microsoft Outlook email messages by original date Performing advanced search queries in Microsoft Outlook 2007 Synchronized Exchange mobile device showing deleted appointment Group policy settings for Outlook 2007 in cached mode Problems creating Microsoft Outlook profile in Windows Vista Microsoft Outlook Research

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary E2K  (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!