Is a Send Connector in Exchange a "work-around" or is it a fix?

We have (in the past 3 months) come across 3 domains we have had problems sending email to. Users try, get the "message delayed" bounce-back, then 2 days later get the dreaded "undeliverable" message.

We manually resolve the IP of their mail server using MXToolbox, then create a send connector on our Exchange server. With that, emails leave the building with no issue whatsoever. This points to a DNS issue, I think. There is some DNS server out there between our Exchange and theirs, that can't resolve properly. The DNS servers between MXToolbox and their Exchange obviously has no issue.

I have never had to do that up until recently, but it is averaging 1 per month since May. It isn't that big of a deal to me to create 1 send connector per month. It takes 30 seconds. I see this as a FIX. My boss sees it as a WORKAROUND. He suggests we need to open a paid support ticket with Microsoft to resolve it, but I happen to think it is a problem with something far out of our control.

So my question; Is a send connector a FIX or is it a WORKAROUND? I know in the grand scheme of things it is a workaround, but when the problem is out of your control, it's description gravitates closer towards the FIX designation, because it is all you can do on your end.

Any tips as to where the error might be (given the really vague details) would be welcomed, but that is not really what I am searching for.
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.

Mark GalvinManaging Director / Principal ConsultantCommented:

Is it possible for you to post the guts of the NDR?

BrianK007Author Commented:
This is after sitting in queue for about 48 hours, trying to re-send at some unknown intervals:

Diagnostic information for administrators:

Generating server: OUREXCHANGE
#550 4.4.7 QUEUE.Expired; message expired ##

Original message headers:

Received: from OUREXCHANGE ([::1]) by
OUREXCHANGE ([::1]) with mapi id 14.03.0235.001; Wed, 24 Jun
2015 08:48:48 -0400
Subject: Test
Thread-Topic: Test
Thread-Index: AdCufBzM4+d1p7pOQt+tIZQ/6DC5mw==
Date: Wed, 24 Jun 2015 12:48:48 +0000
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative;
MIME-Version: 1.0
Mark GalvinManaging Director / Principal ConsultantCommented:
I have seen this once before with Exchange 2010 (although I believe its DNS and not Exchange that was causing my issue). to resolve I:
On the Exchange server open an admin command prompt and see if you can resolve the MX records for the domain:
set q=mx

If it cant resolve the mx records its a dns issue. You have already mention that you have been able to verify using so that would indicate an issue with a DNS server/service at your end.

To fix my client's issue, i went removed all of the DNS forwarders and placed the ISP's DNS servers in the Root Hints TAB. Cleared the cache, stop & started DNS service.

Then clear the DNS cache on the Exchange server and it worked.

Bad DNS can cause so many issues!

Let me know.


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
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

I agree with Mark to some extent, however I have found dns issues using root hints in DNS also, I would not suggest removing root hints rather make sure the ISP DNS servers are set as the forwarders and yes certainly clear the cache and restart dns, make sure the servers network card is configured to use the correct dns servers.

If you enable protocol logging on the send connectors you may get more info on why the connection is failing.

Mark GalvinManaging Director / Principal ConsultantCommented:
Just to confine, I wasn't suggesting removing the root hints. You're gonna need those for sure!
Simon Butler (Sembee)ConsultantCommented:
I would probably classify this as an interim solution.

A lot of servers I work on will have two Send Connectors - one for direct delivery and one for delivery via a smart host. Then any troublesome domains are sent out via the Smart host - I just add the domains to the list.
Therefore if you don't find the solution for the DNS query, then look at adding them to a list of domains that you send out through a smart host - such as your ISPs SMTP server.

The problem with the solution you have now is that if the domain in question changes their host, you wouldn't know and would need to update the connector.

BrianK007Author Commented:
We didn't really figure out what the DNS issue is, but we gave up. We had Exchange set to use our internal DNS server for all external queries. While we could resolve those few domains from our DNS server using telnet, when Exchange made that poll, it failed. Only for a small handful of domains, which is why it was so puzzling.

Rather than chase that domain issue, we just set up forwarders directly on Exchange in the Server Configuration section of EMC to point to our ISP's DNS as well as and so now Exchange sends all queries for external addresses outside of our network. We understand there will be a slight increase in load incurred by Exchange, but the increase will be insignificant, and our rationalization is; it used to have to go outside of itself to resolve these anyway, so who cares. The response times of our ISP's DNS is only 20ms more, and in the grand scheme of things, will be transparent in every case we can think of. It actually reduces the load on our DNS server (which handles many roles) so we would categorize it as more of a trade, than a loss.

Thank you guys for your responses. Points have been awarded accordingly. Cheers.
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.