Link to home
Start Free TrialLog in
Avatar of cynkan
cynkanFlag for Sweden

asked on

Exchange 2007 Internal IP and Public IP


We have a Exchange 2007 Edge and one Hub server.
Both has been moved to another location and at last location all servers had the public IP on the network card. Now its changed to internal IP while we need to have a VPN to the servers and grows in the server farm.

The problem are now when the Hub sends emails for us sometimes it gets errors and cant send the mail. They are stucked in the mail que and we cant understand why. It has to be something with our internal IP numbers while we saw a delay message from the Exchange who presented the internal IP in the message.

Our PTR are correct ->
The internal IP we use is
The Send Connector has the www (hub) as Source Server

Is there any settings in Exchange to say what IP it should present to connecting server?

Avatar of David Atkin
David Atkin
Flag of United Kingdom of Great Britain and Northern Ireland image

Does it happen with all messages or just a few?

Have you checked the Exchange Tracking Center?

Can you give us a copy of the NDR?
You mentioned an Edge Server and a Send Connector.

1. Are you using the Edge Server to send and receive email?

2. Is the Edge Server behind the firewall?

4. From the Hub Server, open a web browser and navigate to:
... record the IP address that is reported.

5. Repeat #4 above, but from the Edge Server.
record the IP address that is reported.

6. The server that is responsible for sending the email (either the Hub or Edge) needs to have a reverse DNS record (PTR record) that matches the IP address you recorded in steps 4 or 5 above.
Avatar of cynkan


1. The Edge server just receive email and all spam filters are there.

2. Both servers are behind a firewall. The Edge is not in the AD.

4. IP on the Hub is (internal

5. IP on the Edge is the same (internal

6. The Hub, with the Send Connector and the Source Server when sending email, has above public IP at a PTR 

I am still confused :(
The PTR record should match the "SMTP host name" that your hub server uses in its "HELO" or "EHLO" SMTP handshake.

Open the properties of your send connectors and confirm that the name used in the field labeled "Specify the FQDN this connector will provide..."

Make that field match your PTR record, either by changing that field, or updating the PTR record. Usually the FQDN of an email server is in the form of - usually it's more like  or something like that. It's not necessarily wrong to use www.  -just unusual.
Avatar of cynkan


Thats the strange, the FQDN is and if I check our PTR record it give me the public IP that the machine has and present when connecting with SMTP.

I dont find it now but there was a automatic Exchange delay message sent to me where I could see the internal IP in the message " (" witch feels wrong.
Good, the FQDN and the PTR match. The PTR also matches the IP results from the site. So it looks like we're all matched up there.
Check the queue again, and report back what the "Last Error" was.
Avatar of cynkan


In attached picture you see the error and problem.
Make sure you're not listed on any spam lists:
Avatar of cynkan


I am sure we are not. Checked you links and also use DnsStuffs Member tools.
Avatar of cynkan


Feels more like its a DNS problem like I wrote that Exchange delay message had our internal IP in the message body, should be the public IP!

Could it be something with our internal network and DNS.

We have one AD machine at as also handles our internal domain. It that DNS there is no public IP, only internals.

The Hub server ( is also our public DNS server where the domain is located. That DNS has no internal records, just public and we dont allow forwarders (disable recursion).

All our servers is asking the internal AD machine with the internal DNS. Seems correct but perhaps you have some idea.
Have you thought about specifying a smarthost in Exchange rather than using DNS?
Avatar of cynkan


I cant, we have SPF records and only our server is allowed to send mail for our domain so it will fail if destination email server checks the SPF record. Thats why we use MX delivery...
check the DNS lookup settings on the send connector.
Avatar of cynkan


How to check this?

The checkbox "Use the External DNS Lookup on the transport.." is not checked. Where can I change what DNS server that is used for external lookup?
Couple of things to look at.

Possibly change the send connector to HELO, See here:

What Anti-Virus do you have on the Servers? McAfee can apparently cause this:

Can you give us the header of the delay message?
server | hub transport | send connector

just ere-read through the above, are you hosting an externally accessible DNS server on your hub transport ?

Please do not do this. There are plenty of free DNS hosting providers, I use Hurricane Electric, but don't host your domain on your internet connection, if your connection goes down, you can't be resolved...

What DNS server settings do you have on the hub transport NIC ?
Avatar of cynkan


The Helo message is correct (, same as the PTR at

The expired/delay message looks like below and like you see, it presents the internal IP.

Diagnostisk information för administratörer:
Genererande server:
#550 4.4.7 QUEUE.Expired; message expired ##
Received: from ([]) by
 ([]) with mapi; Wed, 16 May 2012 21:25:45 +0200

The Send Connector use External DNS Lookup at my internet providers DNS servers so the Send Connector should not talk to our internal Active Directory DNS, just with an external DNS outside our network.

Our public DNS for the domain at the hub server has worked perfect in all years and should not be any problem as I can see. None of our servers are talking to this DNS, its just for external DNS to check the settings for our domain

The NIC on the Hub server has the Active Directory DNS ( as first DNS and our internet providers DNS as alternative DNS.
I would check that the external DNS server that you have listed on the send connector is actually responding correctly to the server.

I would suggest running Wireshark, either on the server, or conected to a span/mirror port, using a capture filter to restrict to traffic that is to or from the external DNS server and ensuring that the response you are receiving is correct.

If you restart the transport service with the capture running, you should see MX record lookups followed by A record lookups for the MX records for each domain in the queue.
Avatar of cynkan
Flag of Sweden image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of cynkan


The solutions was to disable the send connector and create a new one by the shell command. Obvisly the GUI has some bug.