1

My company uses an SBS 2003 server and makes use of Exchange to host our own email. We also have a linux server hosting domains for some of our clients. In order for us to send to those clients, we had internal DNS set up to shadow the client domains to provide "correct" MX records inside our network. For example, public DNS for a domain abc.com might point to 1.2.3.4, but internally we have MX records set up to route mail for abc.com to 172.16.0.4, which is the linux email server. This setup was entirely functional; this is just back story.

We've recently moved one of our client domains from our internal linux server to an external email provider. When we did that, we naturally deleted our internal shadow DNS records so our Exchange server would fetch correct (public) DNS records and route mail out to the new external host. This has NOT had any effect on Exchange though. Even after rebooting the Exchange server and completely flushing the DNS cache (nslookups on the Exchange machine itself correctly resolve to the new external address) Exchange still attempts to deliver messages for the domain to our internal server! Exchange correctly routes to all other internal and external domains when sending email.

Somehow Exchange is trying to deliver to a machine that by all accounts it has no business trying to use for just this one domain. Is there a DNS cache that Exchange uses internally? Is there a way to flush that internal cache? What else could I be missing?

6
  • 2
    You didn't happen to setup an SMTP connector with those client domains in the address space, did you? That's how I normally route mail between two different mail servers internally; it could be something overlooked.
    – gravyface
    May 17, 2010 at 15:05
  • No, there are only the default connectors across the board. The only other thing that occurs to me is that this SBS server was a migration from an older server. The ESM still lists the old Exchange server by name even though it doesn't exist on the network or DNS anywhere. I wonder if that's gumming things up at all.
    – beporter
    May 17, 2010 at 16:41
  • So you have done nslookup -q=mx abc.com from the Exchange server and it resolves to the correct external address?
    – smoak
    May 17, 2010 at 17:13
  • That's absolutely correct. It's the craziest thing. That's why I'm posting here: I can't figure out what's causing Exchange, and Exchange only, to continue to use the old internal DNS records to route outbound email for JUST that domain. In fact, we've moved other clients out from our internal linux server to external hosts before-- without this issue arising.
    – beporter
    May 17, 2010 at 18:46
  • Could there be an entry in your lmhosts / hosts file that points to the old IP address?
    – adamo
    Sep 11, 2011 at 11:24

1 Answer 1

2

To fix (or rather work around) this issue, configure an External DNS Server for your SMTP.

In Exchange System Manager:

Expand Servers -> [your server] -> Protocols -> SMTP

Select "Properties" for your SMTP virtual server and go to the Delivery tab. Click Advanced and then Configure. Now you are able to add external DNS servers to use for outbound mail routing.

I've used this a approach to remedy identical situations on both Exchange 2003 and 2007 with success

2
  • Ahh, that would have been an interesting thing to try. I would be curious to see what happens if I were to set this, then subsequently clear it. I can't rightly accept the answer without having tested it myself though.
    – beporter
    Dec 29, 2011 at 15:06
  • Well, there's no harm in trying, the only thing you do is ask the exchange server to perform a direct public DNS lookup, instead of having your internal DNS servers forward (or potentially answer with cached records) the request. This will only apply to outbound mail. Dec 29, 2011 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.