Email being delayed to a single domain

We are all of a sudden having an issue emailing a single domain, all other email is flowing correctly out of our building. We use exchange 2010 and we do not have email going to a spam filter of any kind going out of the building. I have looked at the queue viewer and all messages are showing same delivery type. Any help would be greatly appreciated.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
reindeerautoAuthor Commented:
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: 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. 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?
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

reindeerautoAuthor Commented:
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.
reindeerautoAuthor Commented:

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 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.
reindeerautoAuthor Commented:
When I try to telnet into their server I get the following message.

C:\Windows\system32>telnet smtp
Connecting To 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 "" 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).
reindeerautoAuthor Commented:
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 "" lookup came from doing a DNS lookup from the server itself? i.e.
nslookup -querytype=mx

Open in new window

When I do this from here, I see listed as the mail exchanger, not

Are you also running telnet from the Exchange Server directly? This is best to avoid any firewall etc issues over outbound port 25.
reindeerautoAuthor Commented:
Ok got it to work finally, I am showing the results below.
Okay; did the recipient receive that test message?
reindeerautoAuthor Commented:
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.
The server itself therefore doesn't have any problems reaching their mail server.

I am still skeptical as to why Exchange is connecting to the wrong server. Seems it's pulling old details from a cache somewhere. I would ask that -- if able -- you schedule a period of downtime to restart the Exchange services; in particular the MS Exchange Transport service, but restarting all would not harm (unless you've already tried this to no avail?).
reindeerautoAuthor Commented:
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.
reindeerautoAuthor Commented:
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."
The next best step will be to enable protocol logging on your send connector, to log line-by-line the SMTP session as it takes place between your server and theirs.

Please follow the steps in this article under the heading "Enable protocol logging on a Send Connector" to configure this. It is listed as being for Exchange 2007, but the steps are identical.

Then browse to the location specified in the protocol log path (see the bottom of the article for paths; it is typically Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpSend under the Exchange install directory. Force a message exchange to take place between your server and the other party's, such as by sending a new one or opening the queues and attempting to retry a previous message which is sat waiting.

The logs are not written immediately; you either have to wait or force them to be flushed to disk by cycling the MS Exchange Transport service. I cannot from memory remember if enabling the verbose logging is picked up immediately; forcing the Transport service after enabling the verbose mode and before the SMTP session is forced to take place would not be a bad idea.

You will receive logs of all SMTP sessions going out to all recipients' servers; please isolate and post here the lines relating to the problem recipient, wrapping the relevant lines in code tags in the EE editor so the output is printed here in a monospaced font.

I have a hunch this might be based on problems with TLS; your server is most likely offering this, and in my brief tests a moment ago, their server appears to be refusing it. This should not cause a problem, unless their machine is not obeying the standards.

Let's see what the debug logs tell us.
reindeerautoAuthor Commented:
2015-03-25T11:10:26.052Z,outbound,08D235036DF333C3,2,,,<,220 ESMTP Symantec Messaging Gateway,
2015-03-25T11:10:26.052Z,outbound,08D235036DF333C3,3,,,>,EHLO RAREXCHANGE.reindeerauto.local,
2015-03-25T11:10:26.099Z,outbound,08D235036DF333C3,4,,,<,554 5.7.1 Delivery not authorized,
2015-03-25T11:10:26.099Z,outbound,08D235036DF333C3,5,,,>,HELO RAREXCHANGE.reindeerauto.local,
2015-03-25T11:10:26.255Z,outbound,08D235036DF333C6,0,,,*,,attempting to connect
2015-03-25T11:10:26.380Z,outbound,08D235036DF333C7,0,,,*,,attempting to connect

Open in new window

Hmm, this really does look like some issue which is going to require collaboration with the remote party's IT staff to figure out the specific fault their mail gateway is identifying. It is for sure your server not rejecting the transmission based on that "Delivery not authorized" error message.

To confirm: do you have proper forward-confirmed reverse DNS configured for the IP of your mail server? Do you have any SPF records in place which might be out-of-date?

Unlikely, since you can communicate with other mail servers just fine -- these types of checks are more and more prevalent so I would expect a problem in your configuration to cause problems with more than just one recipient.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
reindeerautoAuthor Commented:
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!]
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.