• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 737
  • Last Modified:

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 remotedomain.com
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 remotedomain.com times out after the hop at-
aggr116a.dfw1.rackspace.net [72.3.xxx.xxx]
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.

1 Solution
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!


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.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

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:
xx.xx.21.216.in-addr.arpa name = domain.com.

Authoritative answers can be found from:
56.21.216.in-addr.arpa nameserver = ns2.firstcomm.com.
56.21.216.in-addr.arpa nameserver = ns1.firstcomm.com.
ns1.firstcomm.com internet address =

my MX Records show as-
10      domain.com.inbound10.mxlogic.net
10      domain.com.inbound10.mxlogicmx.net

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

216.21.xx.xx PTR record: domain.com. [TTL 10800s] [A=173.161.xxx.xxx] *ERROR* A record for domain.com. 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 @ it-eye.co.uk 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 domain.com returns an IP Address of 173.161.xxx.xxx and that's the problem.  If you have Reverse DNS configured as mail.domain.com then you shouldn't have a problem.

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

Could it be because my MX Records show as-
10      domain.com.inbound10.mxlogic.net
10      domain.com.inbound10.mxlogicmx.net

and not mail.domain.com

Or would that not matter since it ends in mxlogic.net 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 domain.com and then will perform a Reverse Lookup and it will find 173.161.xxx.xxx - 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 domain.com"

So I am not sure where this mixup may be happening...
Alan HardistyCo-OwnerCommented:
That's correct - but it should point to mail.domain.com as that is your FQDN and that FQDN resolves to the IP Address you are sending from.

Ask them to change it to mail.domain.com - your problem should go away.
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 and DeveloperCommented:
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.

Join & Write a Comment

Featured Post

We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now