What is the NDR that they get and what is the problematic domain? You can also try to telnet from your Exchange server to the MX record of this domain and see if you can submit a message. If yes, you should be fine - so check the SMTP log if you really connect to the MX record for this domain. It might be a DNS issue or you might need a PTR or.... So many possibilities... Ron
Usually they a few delay report, then the last one will be a failure report. Below are a copy of the NDR for the delay. This is an automatically generated Delivery Status Notification.
THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipients has been delayed.
Posts: 1
Joined: 22.Mar.2005
From: USA
Status: offline
Have you resolved this issue? I have the same problem with one company. It just happens to be FedEX so it is a major pain. But it has been that way ever since we install Exchange 2000.
I am having the same issues with Exchange 2003. We were using a 3rd party to host our email and switched over ot our own exchange server one month ago. We get about 90% of all email but several companies get a bounce back. I have checked everything from my router to hardware, this is becoming a big issue.
If anyne can suggest some things to look at please!
the following is the results from the .txt that the sender gets back.
Since you have a problem with only one domain I would look into a telnet to that specific domain's MX and try to send a message this way. See if you are successful and then you can go further, like nslookup to see if your DNS can resolve that MX. Enable SMTP logging and check for the line that shows the communication to that domain. See how it ends...also check additional info on the queue at the bottom in E2K3 when you highlight the queue or right click/Properties on the queue in E2K. You can also enable Diagnostic Logging for MSExchangeTransport in the Regedit from under HKLM/System/CurrentControlSet/Services/MSExchangeTransport/Diagnostic - set all the keys from the right pane (there are 9) to value = 7. You can only get a max of 5 from the server properties in ESM. Then check the application log for events pertaining to this domain. When you finish do not forget to set the keys back to 0 in the Registry or simply from ESM/Server Properties/Diagnostic Logging tab - MSExchangeTransport. For the NDR 4.4.7 -> Cause: Message in queue has expired. The sending server tried to relay/deliver the message but the action was not completed in its message expiry timeframe.
Solution: This message usually indicates a problem on the receiving server. Checking the validity of recipients address as well as whether the receiving server is configured to receive messages correctly. Resending the message will place it again in the queue, if the receiving server is up, message delivery will succeed. It might take a little bit of troubleshooting on this issue to see what is happening. Ron
I am having a similar problem. Email gets bounced back with a DNS error. The destination server for this recipient could not be found in Domain Name Service (DNS). Please verify the email address and retry. If that fails, contact your administrator. <wp2650.mhwb.com #5.4.0> I looked at the DNS server and found the DNS is not configured. However everything worked fine before and nothing has changed. If I reboot the server it works fine for a while. I have an ISAS server as a firewall. Could this be the problem?
I would not recommend to use the DNS forwarders in the Virtual server properties but rather in DNS. To check if you have a good name resolution, use nslookup - press enter. On the next line type set q=mx and press enter. Next line you type the name of the problematic domain (like hotmail.com). It should return the mx records for this domain like mx1.hotmail.com and so on. Then to check the other forwarders you can type on a new line "server IPForwarder" (you take it from DNS server properties/Forwarder tab or under VS properties in ESM/Advanced/Configure. Make sure that your forwarders work. One other option is to use www.dnsstuff.com and lookup the MX for the problematic domain(s) and then setup an SMTP connector with the address space of that domain like hotmail.com and smarthost to the MX - make sure that you put the IP between square paranthesis like in [1.1.1.1]. Restart Virtual server and check if messages destined to this domain go through. You can also enable SMTP logging in NCSA format on the Properties of VS/General page and make sure that when you try to connect to that specific domain you really connect to the correct IP address. Ron
RE: Cannot send email to a specific outside domain from... - 11.Apr.2005 10:38:00 PM
Guest
I had the same problem and solved by turning on Smart Host Forwarding. Basically, I send all the mail to my ISP's smtp server and let them handle moving it on to where it needs to go.
Posts: 1
Joined: 20.Apr.2005
From: UK
Status: offline
I am getting these #5.4.0 NDRs from only certain places, this is when exchange is set to Attempt direct delivery before sending to a smart host. When i uncheck this the messages seem to send but all internal mail stops! Can anyone help? Thanks
RE: Cannot send email to a specific outside domain from... - 20.May2005 5:47:00 PM
Guest
i have the same problem - but only ith microsoft servers (MSN Network). check out http://spf.pobox.com/ this is what some mail servers do to check the validity of your mail server - they also may perform a reverse dns lookup on the host name
I had a similar problem. Email to one external address hosted at register.com was piling up in my exchange queue. (Exch 2003 sp2)
Finally had to call MS for support.
Solution: The name of my SMTP virtual server (Exch sys mgr / Admin groups / Site / Servers / email server / protocols / smtp ... properties of server / Delivery Tab / Advanced button ) is an internal (to the company) dns name which is different from the email server's external dns name. I only have a dns entry for it's external dns name. So I needed to add a dns entry on the internet for it's internal name also. All other email systems were accepting email from us, so it is a rare case.
I had never set up an internet published dns zone for our internal domain.
When I tried to do a manual telnet session with the target server, I could connect as the external name, but not the internal name.
Like this:
telnet mxmail.register.com 25 220 inbound010.roc2.bluetie.com inbound010 ESMTP server ready helo sfmail.mydomainexternal.com 250 inbound010.roc2.bluetie.com hello [64.127.116.95], pleased to meet you
telnet mxmail.register.com 25 220 inbound010.roc2.bluetie.com inbound010 ESMTP server ready helo sfmail.mydomainINTERNAL.com (no reponse from server)
Once I published the servers internal name with the external ip it comes from I started getting a response and the email was accepted.
Hope that helps someone else.
< Message edited by rws70 -- 21.May2010 8:16:47 PM >