Cant send email to one specific domain, times out during nslookup test also.

We can't send e-mail to one of our clients. It sits in the transfer queue and generates a delay, then failure eventually. The domain I am talking about is
Other email is flowing fine, and we can receive email from them.
It doesn't look to be making it to their end at all, so I don't believe it to be a spam filter issue.
Exchange queue states "The remote server did not respond to a connection attempt"
Message history shows the last external step to be- "SMTP: Message Routed and Queued for Remote Delivery"
nslookup with type=mx times out.
A tracert to times out after the hop at- []
I tried the tracert from a completely separate DSL connection we have here that doesn't touch my production network, and it timed out at the same point.
And nslookup from the DSL connection yields the same time out result as from my production network.

I am in the Chicagoland area. I had a friend at his work do an nslookup and his worked fine. He is located about 50 miles away from me. I am waiting for tracert results to see what his shows.

Looking for any idea's what this could be. The fact that from two separate ISP connections here it doesn't work seems strange to me.

Who is Participating?
Alan HardistyConnect With a Mentor Co-OwnerCommented:
That's correct - but it should point to as that is your FQDN and that FQDN resolves to the IP Address you are sending from.

Ask them to change it to - your problem should go away.
Alan HardistyCo-OwnerCommented:
Have you got any entries for this domain in your hosts / lmhosts.sam file?

Have you got a specific SMTP connector / Send Connector configured for that domain?

Have you got anything configured locally in DNs for this domain?

Their inbound mail uses Postini, so you should be able to see their Mx records happily.

You may also be using DNS forwarders for an old ISP and might need to update them to your existing ISP's DNs servers.
Josh-ITAuthor Commented:
I shouldn't have any entries in my hosts/lmhosts.sam since I tested it from two separate computers on two separate connections. I know I one of the machines has never so much as gone to their website or connected to my production network.

SMTP connecter / Send Connecter should be able to be ruled out since one of the machines is on a separate guest network and doesn't connect to my exchange or firewall.

Nothing locally in DNS for that domain on the DSL connected machine at least.

I will have to check into the DNS forwarder settings.
But on my guest DSL, that is just going from a linksys WRT-54G into the Covad DSL modem/router.
So I am not sure where the DNS settings would sit on that.

If you do a tracert, do you even see the last hop my end is able to make?

Thanks so much for the help and idea's so far!


Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

Well, tracert isn't a good option in fact to test a tcp connection.
Use a tcptrace to see if you can reach his host.

Now to fully analyze this issue, i would recommend wireshark.
Also, picking a packet crawler and crawling a DNS request would be good to see if you can acquire his DNS.(or using nslookup + wireshark would also work)
But in fact, you could also do some tests before digging into those tools.
Like trying to use his direct IP instead of his domain.

In fact, rackspace(the domain where your request stops) is his hosting service.
Interestingly it's the last loop before you reach his server.
I might have guessed that IT MIGHT BE his firewall.

Your ping requests are stopping there.
But ICMP requests don't prove enough.
You should try to use nslookup + wireshark or packet crawling.
Alan HardistyCo-OwnerCommented:
Can you check to see if you are RFC compliant (you have Reverse DNS configured and your FQDN is correct) and you are not blacklisted:
Josh-ITAuthor Commented:
Starting to read that article-

When I ran the reverse DNS check it came back with these results-

Non-authoritative answer: name =

Authoritative answers can be found from: nameserver = nameserver = internet address =

my MX Records show as-

MXLogic does our external spam filter on Inbound mail only, but they also archive any mail sent/received from my mail server. is my domain.
Alan HardistyCo-OwnerCommented:
This is what I see when I perform a reverse DNS check:

216.21.xx.xx PTR record: [TTL 10800s] [] *ERROR* A record for does not point back to original IP (A record may be cached).

Thus you are not RFC compliant because your Reverse DNS does nit resolve back to the same IP address that you are sending mail from.

Thus will be one BIG reason for mail-flow problems.

If you want to test on another domain, please ping me a test email to alan @ and see what my servers responds with.
Josh-ITAuthor Commented:
Could that be because of my MXLogic hosted email filtering service?
Since my mail flows through them before me with the MX Records as they are.
To my understanding-
Mail flows through them, gets filtered, goes to my Exchange Box, get's journaled then picked up by them for archiving.
216.21.xx.xx is my IP here.
Alan HardistyCo-OwnerCommented:
Okay - test message received - thanks.

Your sending IP is as above and as mentioned, Reverse DNS in incorrect.  Running an NSLOOKUP on returns an IP Address of and that's the problem.  If you have Reverse DNS configured as then you shouldn't have a problem.

Time to call your ISP and get Reverse DNS changed.
Josh-ITAuthor Commented: is the company hosting my Website.
So that is a valid address for

Could it be because my MX Records show as-

and not

Or would that not matter since it ends in anyways?
Alan HardistyCo-OwnerCommented:
That doesn't matter.

When a server receives a connection from your server, it checks your IP Address and finds 216.21.xx.xx - it then checks Reverse DNS on your Domain and find and then will perform a Reverse Lookup and it will find - these two MUST match for some mail servers to be happy.  As they don't match with your domain, some mail servers will reject you.
Josh-ITAuthor Commented:
Just received a reply from my ISP-

"You have one PTR record.   216.21.xx.xx   points at"

So I am not sure where this mixup may be happening...
Josh-ITAuthor Commented:
Thanks, I had the ISP make the change.
Hopefully it works. I will be back to follow up or finish off this question depending on my results.
Thanks again!
Alan HardistyCo-OwnerCommented:
Sure - no problems - will be keeping an eye out for the change.

Alan HardistyCo-OwnerCommented:
I can see the record change already.
Josh-ITAuthor Commented:
Can you also remove the domain from line 2 of the first posting?
Josh-ITAuthor Commented:
So, the day after the change was made my OWA was down, as well as mobile e-mail.
Typical step one, I had the previous change reversed.
Hours later, still no OWA/Mobile Email.
A reboot of the Exchange box got everything back in order.
So I am not even sure if the fix we discussed corrected my issue or not, I am going to have to have the ISP make the change again and see what happens.
Probably not going to be able to do it until this weekend, just in case it is in fact what killed all my mobile access to email.
Alan HardistyCo-OwnerCommented:
Reverse DNS won't have any bearing on problems with your server - it is like sticking a road sign pointing to a town.  Then as soon as the sign is up - the town has a power-cut.  Totally unrelated - just a coincidence that they happened one after the other.

QlemoBatchelor, Developer and EE Topic AdvisorCommented:
This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.