Email being delayed to a single domain

What status does the queue viewer report for mail being delivered to that domain?
You will find status messages to indicate the error(s) Exchange is encountering in delivering the mail.

Since outbound email to other domains is functional, this behavior would typically be caused by Exchange being unable to reach that domain's mail server (perhaps it is offline for maintenance, or DNS changes have been made but are yet to reach you) OR if the recipient's system is rejecting your mail due to considering your messages to be spam, by an IP address being on some blacklist or individual content filtering of the messages.

Tigermatt, the "Last Error" was 400 4.4.7 Message delayed

That is typically indicative of the receiver's environment being down. You can double check this via a simple telnet test: https://technet.microsoft.com/en-us/library/aa995718%28v=exchg.65%29.aspx. You will need to perform an MX record lookup to determine the hostname(s) of the server(s) responsible for receiving mail for the recipient's domain.

Is the receiver's domain a "major" domain which is unlikely to be down (e.g. @gmail.com) or is it a private system hosted on their own servers?

It could, of course, be an indication of a problem at your end, but this is unlikely. To be doubly sure, I would check for correct DNS functionality, any errors in firewalls and/or any other hardware between the server and your outbound Internet connectivity, but if other mail is flowing, it really does point to the recipient's part and there is little you can do in that case.

Can you contact the recipient out-of-band to determine whether they are receiving mail from others or if they have a problem?

Tigermatt, they can also send to us just fine.

they can also send to us just fine.

Email is a unidirectional service, so the ability to send confirms their environment is up and connected to the 'net, but doesn't tell us much more. There may be systems between you and them which intercept and filter mail, such as overzealous spam filters on their ingress path.

I would suggest carrying out the telnet test I have documented above, and sending a test message to an address at the recipient's side.

If mail is successfully delivered via that route, then we can focus on troubleshooting the issue within Exchange.
If mail is not successfully delivered via a telnet test, it should provide a better explanation of the problem which we can use for troubleshooting.

Tigermatt,

As I am trying to run the telnet every "rcpt" address I try and send to I get "550 5.7.1 unable to relay" .

Okay, so just to check a couple of points:

In the telnet test, did you do the following two things?

a) Connect to their mail server (as noted in their MX records), and
b) In the RCPT TO field, are you entering an email address at their domain?

If the answer to both of the above is "yes", then their mail server is incorrectly refusing email sent to their domain, and the problem lies at their end.

I expect from the error that either you connected to your own mail server in the telnet test, or you are using a RCPT TO address which is not at the other company's @company.com domain. The mail server is hence working correctly according to best practice configuration, since to accept the email in such circumstances would cause the server to be an open relay.

When I try to telnet into their server I get the following message.

C:\Windows\system32>telnet mail.laricktowing.com smtp
Connecting To mail.laricktowing.com...Could not open connection to the host, on
port smtp: Connect failed

I've never used the syntax "smtp"; what happens if you type 25 as the port number?

FWIW, I cannot resolve the hostname "mail.laricktowing.com" here; it doesn't exist in the DNS. Is it possible their mail server has moved recently, and your server has yet to observe the updates to the DNS? (since it has a time to live of 86400 secs = 1 day).

when I use "25" I get the same response. This problem started last week, we have been sending emails to this domain for quite some time then it just stopped. I would think the DNS would have resolved itself by now. I am just trying to prove that they are blocking us and that it is their problem. We have no problems sending email to any one else.

Okay. I presume the "mail.laricktowing.com" lookup came from doing a DNS lookup from the server itself? i.e.

nslookup -querytype=mx laricktowing.com

Select allOpen in new window

When I do this from here, I see gateway1.1800envision.com listed as the mail exchanger, not mail.laricktowing.com.

Are you also running telnet from the Exchange Server directly? This is best to avoid any firewall etc issues over outbound port 25.

Ok got it to work finally, I am showing the results below.
telnet.PNG

Okay; did the recipient receive that test message?

Ok so I had to do it again, the email address I used is invalid. I have attached the results of the second attempt and they did receive it.
telnet.PNG

I restarted the server and sent another email from my Outlook to this address. The email still gets caught in the queue and they are not receiving them.

Now it is giving a last error of "451 4.4.0 Primary target IP address responded with: 421 4.4.2 Connection dropped due to SocketError."

2015-03-25T11:10:26.052Z,outbound,08D235036DF333C3,2,192.168.2.4:28516,204.186.82.6:25,<,220 gateway1.1800envision.com ESMTP Symantec Messaging Gateway,
2015-03-25T11:10:26.052Z,outbound,08D235036DF333C3,3,192.168.2.4:28516,204.186.82.6:25,>,EHLO RAREXCHANGE.reindeerauto.local,
2015-03-25T11:10:26.099Z,outbound,08D235036DF333C3,4,192.168.2.4:28516,204.186.82.6:25,<,554 5.7.1 Delivery not authorized,
2015-03-25T11:10:26.099Z,outbound,08D235036DF333C3,5,192.168.2.4:28516,204.186.82.6:25,>,HELO RAREXCHANGE.reindeerauto.local,
2015-03-25T11:10:26.114Z,outbound,08D235036DF333C3,6,192.168.2.4:28516,204.186.82.6:25,-,,Remote
2015-03-25T11:10:26.255Z,outbound,08D235036DF333C6,0,,54.246.113.150:25,*,,attempting to connect
2015-03-25T11:10:26.380Z,outbound,08D235036DF333C7,0,,66.196.118.33:25,*,,attempting to connect
2015-03-25T11:10:26.411Z,outbound,08D235036DF333C7,1,192.168.2.4:28520,66.196.118.33:25,+,,

Select allOpen in new window

Well by some miracle it all of a sudden started working last night, so I guess they finally solved their problem since I made no changes to anything. Thank you for all of your help.

Great, glad to hear they fixed it. At least it wasn't you after all...

[Don't forget to switch protocol logging on that send connector back off, if you haven't already, otherwise your disk is going to fill up with logs very quickly!]