- Reason: “Unable to bind to the destination server in DNS” - I am running in a front-end / back-end Exchange 2003 environment. On my back-end Exchange server in Queues when I clicked on SMTP Routing, I received a message (below in “Additional Queue Information”) that read: “Unable to bind to the destination server in DNS”.
Several weeks ago on my front-end Exchange server under SMTP Virtual Server (Delivery -> Advanced), I defined a fully qualified domain name as mail1.mydomain.com (this corresponded with my Internet FQDN and PRT record).
So that my internal DNS could resolve this FQDN, hence route mail I added a Host (A) record to my internal (AD) DNS for this FQDN. This resolved my problem.
- Reason: "The remote server did not respond to a connection attempt" - We had this problem because of an MTU size setting being incorrectly configured on the destination Exchange Server. It only showed when we started migrating multiple mailboxes to the new Exchange Servers. We set all MTU sizes to their default to resolve the issue. See ME314825
for a hotfix applicable to Microsoft Exchange 2000.
- Reason: "The remote server did not respond to a connection attempt" - See ME824054
- Reason: "SMTP protocol error" - This behavior occurs if the destination server cannot resolve the domain that you are using as your return address. For example, if your server's domain is "nonexistentdomain.com", and you are trying to deliver a message to a domain called "destinationdomain.com", and this domain has Reverse Lookup enabled on its SMTP server, mail delivery will fail. See ME300171
to solve this problem. Also, see the link to "SMTP communication problem" for additional information on this issue.
- Reason: "Unable to open the message for delivery" - See ME815759
- Reason: None - See ME812292
- Reason: "The handle is invalid" - See ME899392
- Reason: "The connection was dropped by the remote host" - This problem can be caused by the firewall installed on the system. See ME895857
for information on fixing this problem.
for more details.
From a newsgroup post: "As it turns out, I did not have my NIC at the top of the binding order. Changing this cleared my queues".
These were filling up the event log more than once per day. The SMTP server had authentication turned on. Apparently a spammer had cracked one of our passwords and was using it for delivering spam.
Have seen this caused by incorrect DNS server entries in the properties of the Exchange SMTP Virtual Server. Prevented mail from going out as it tries to resolve DNS via these servers rather than the normal DNS forwarders.
The sender incorrectly typed the domain name, However, in the majority of cases this is caused by a the exchange postmaster non-delivery reply to a non-existant domain or Spammers mail server that refuses deliveries. I.e. spam sent to unknown users. You can check your Exchange Ques to freeze messages to the domain, however, upon reboot of the Exchange server, the frozen connections will no longer be frozen.