Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have upgraded our internal corporate email server and the IP address has changed internal to our network. A second email server is used for sending bulk jobs for a mailing list service that we offer.

Since the switch of the internal corporate server IP we have been seeing problems when the bulk email server is trying to send email to our own domain. The log shows that it is still trying to hit the old corporate server instead of the new one. I have looked through all settings for the bulk email software and see nothing set there to send to internal mail servers, and I do not recall doing anything special to get this working when setup a couple years ago.

Is there a setting in Win2003 or on the network that enables the mapping of MX record external IPs to internal IPs so mail gets routed correctly?

share|improve this question
What mail server(s) are you using? – gravyface May 12 '10 at 14:28
Zrinity XMS Server – dmr83457 May 12 '10 at 14:33
So, you can't spam yourself! Am I the only one who thinks that ironic? – tomjedrz May 12 '10 at 16:50
up vote 2 down vote accepted

If you're using Exchange 2003 (I'm assuming you are as you indicated Windows Server 2003), you could just setup an SMTP Connector on the bulk mailing server with cost 1 (make sure your default SMTP connector has * cost 5 or it'll never match on the new send connector) and add your corporate mail server as the smarthost. This will ensure that gets routed through the corporate mail server; anyrecipient@*.tld will get routed out normally.


Has your firewall changed? MX records correct? From your bulk mail server, try this from the command prompt:

'nslookup' hit ENTER then set type=mx hit ENTER again, the type in and first make sure that the MX records resolve correctly and secondly, try to telnet to that MX record like so:

telnet <mx.record.tld> 25 if you get back a 220 Microsoft Exchange xxx (you can type quit to exit) then you can connect to your mail server via NAT reflection (going out and back in again) so the issue must be elsewhere in the bulk mail software.

If only your new mail server has changed, then it's likely your new Exchange Server is not allowing connections and/or you're trying to relay from, which will be denied by default. You can open up the Default Virtual SMTP Server and under Connections and Relay settings add to the "allowed" list for both relay and connections (or you can use SMTP authentication if the bulk mailer supports it).

If neither of these are the issue, and since you seem to be limited to configuration choices on your bulk mail server software, you could create a Zone in Active Directory (assuming you're using Active Directory for DNS internally) for and then add an MX record which resolves to your Exchange Server's internal IP address so that when your bulk mail server looks up the MX record for, it gets the internal MX record (which in turn needs to resolve to your internal IP address for your mail server). The only problem with this method (split DNS) is that you need to make sure your internal DNS zone is identical to your external/Internet DNS zone for, otherwise, if anyone tries to hit up internally or whatever you won't have any/the correct records to do that.

share|improve this answer
I'm using a different server (in my reply above) and there does appear to be a similar option that accepts an IP for "Redirecting mail to a local delivery SMTP server". However it isn't currently setup so I don't understand how this ever worked. I'll give it a shot – dmr83457 May 12 '10 at 14:38
Nevermind, that option is for incoming mail. – dmr83457 May 12 '10 at 14:41
edited question accordingly. – gravyface May 12 '10 at 15:11
It turned out to be an internal DNS setting that allowed this to work previously. I found and updated the MX record. This was my initial thought as to what might be going on but a consultant who helped us with the new server suggested it would be in the bulk server settings. I think there was just some miscommunication between the two of us about what was going on, probably due to my my lack of experience with AD/DNS. Thanks for your help! – dmr83457 May 14 '10 at 21:27

It sounds like you might need to setup an internal DNS server for your bulk mail server to point to.

On the internal DNS server you will assign your MX records for your domain to the new internal IP address. Then for all other domains the DNS server should be set to forward to a "regular" DNS server that will be able to resolve the addresses for mail recipiants outisde of your domain.

This allows you to control where your internal MX records for your domain point to, while allowing lookups to outside domains to be processed as normal.

share|improve this answer

Have you tried pointing the dns name and/or ip of the old mail server to the new one? It's slightly hack, but may help diagnose if nothing else.

share|improve this answer

First, I check the configuration for the mail server. Since you apparently don't have internal DNS overriding the external mail address, there is likely some exception built into the mail server configuration for your domain. I don't know specifically how to do it for your server.

Second, check the HOSTS file on the bulk mail server. That may be how the IP is overridden to the internal address. You may also want to clear the ARP cache on the bulk mail server.

Third, check the firewall .. there may be some screwy NAT rule for traffic from the bulk mail server.

Another alternative (which I like better and would likely do anyway) is to put the bulk server in a DMZ, at which point you should be able to setup the same NAT on the DMZ as exists on the outside world.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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