Link to home
Start Free TrialLog in
Avatar of danielevans83
danielevans83Flag for United States of America

asked on

Exchange 2007 Email "Delayed" to one specific domain - anyway to fix?

We have one user on our Exchange 2007 server that is reporting when they email a specific domain that the recipient never receives the message. Later that user will get an "email delayed" message from Microsoft Exchange. Is there anything we can do on our end or is this a problem on the other domain's server?
Avatar of briandunkle
briandunkle

What happens if other users send mail to that domain?
Does your exchange server have a reverse DNS entry that the other server can get to?
What exact message do people get?
If you have your exchange server send you NDR (non-delivery reports) what do they say? That can be set in the smtp server settings under echange.
Really nothing you can do.

Usually best thing is to stop sending emails to that domain for 24-72 hrs or so so that the ISP can process the emails waiting to be delivered.

After that you should be okay.


Avatar of danielevans83

ASKER

Where can I check to see if we have a reverse DNS entry for our exchange server? Would that be on the server or in Godaddy DNS settings?
For some reason I don't get an NDR for these delays. The message the user receives says this:

Delivery has failed to these recipients or distribution lists:
 
'xx@xxxx.com'
Microsoft Exchange has been trying to deliver this message without success and has stopped trying. Please try sending this message again, or provide the following diagnostic text to your system administrator.
ASKER CERTIFIED SOLUTION
Avatar of briandunkle
briandunkle

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Generating server: xxxxxxxx.xxx.local
 
xx@xxxxx.com
#550 4.4.7 QUEUE.Expired; message expired ##
 
Original message headers:
 
Received: from xxxxx.xxx.local ([xxx.xx.xx.xxx]) by xxxxxxx.xxx.local
 ([xxx.xx.xx.xxx]) with mapi; Mon, 6 Apr 2009 13:01:53 -0400
From: "Winn, Michael" <MWinn@xxxxxx.com>
To: "'xx@xxxxxx.com'" <xx@xxxxxx.com>
Date: Mon, 6 Apr 2009 13:01:52 -0400
Subject: FW: Purchase Agreement-PRIVILGEGD AND CONFIDENTIAL ATTORNEY-CLIENT
 COMMUNICATION-DO NOT DISTRIBUTE
Thread-Topic: Purchase Agreement-PRIVILGEGD AND CONFIDENTIAL ATTORNEY-CLIENT
 COMMUNICATION-DO NOT DISTRIBUTE
Thread-Index: Acmz1b5tCK1w55zfSNSgc7SNeix4RgAl9bOwAAT67HAAjpH1iwAHYSgA
Message-ID: <1327BDF078832343BA747F1C17CCC336CE52A220@xxxxxxx.xxx.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/mixed;
            boundary="_004_1327BDF078832343BA747F1C17CCC336CE52A220xxxxxxxxxxloca_"
MIME-Version: 1.0


I added the followng SPF record to Godaddy. Will this help?
v=spf1 a ptr ptr:mail.xxxxxx.com -all
The website you provided looks like it timed out and then provided this response.

Retrieving DNS records for h-xx-x-xxx-xxx-static.mclnva23.covad.net...Attempt to get a DNS server for h-xx-x-xxx-xxx-static.mclnva23.covad.net failed: h-xx-x-xxx-xxx-static.mclnva23.covad.net does not exist in the DNS
That's okay - if you put in the IP address, the fact that it comes up with blah-blah-static-blah means it got the reverse lookup. The stuff after is just in-depth.

There should be something after this:
Delivery has failed to these recipients or distribution lists: 'xx@xxxx.com'Microsoft Exchange has been trying to deliver this message without success and has stopped trying. Please try sending this message again, or provide the following diagnostic text to your system administrator.

...giving specific details about the rejection. "the following diagnostic text"
If there is anything, that would be helpful.

Doesn't the reverse DNS name have to match our mail servers name? The name that is returning is our ISP's name.
 
FYI, the diagnostic text is copied and pasted in my previous comment....
Oh, sorry, yeah, I see it now. Duh.

If it was a reverse DNS issue it should have said something to that effect (well, it does sometimes) and you should be getting fails from more places.

It might be that that static IP got on a blacklist somewhere...maybe just internal to that domain. Perhaps a previous customer of your ISP got a spambot or something. :)

Can you ask for a different static IP?
We have 5 I could use another. I'll put our IP into some spam lists see what I find.
If it's only the one server rejecting you, could be internal to them.
Or could be something else entirely. :/
Check out this article, could be of some use.

http://thebackroomtech.com/2008/03/28/troubleshooting-exchange-error-447-delivery-delay-and-failures/ 

Also, have you check to ensure the domain your sending to isn't on a black list?  Has your ISP created a PRT record for your domain?  You can also have the receiving server side Admin add your domain to their inclusion list in exchange.  I've had to do with othe companies who have an odd mail server that will randomly not route mail.
I added the SPF record to our Godaddy external DNS as I mentioned in my previous comment.
You're saying that I would also have to contact our ISP (Covad) and have them set up the RDNS for our Exchange email server?
The user experiencing this error successfully sent an email to the domain in question from an Earthlink webmail account.
Standard practice with our clients, is to contact the company providing the line to the office (comcast - verizon - integra - ectra) and have them create reverse dns entry to our static IP. Once this is done usually the issues usually go away.

-= Excerpt from posted URL =-
Troubleshooting: This code typically indicates an issue on the receiving server. Verify the validity of the recipient address, and verify that the receiving server is configured to receive messages correctly. You may have to reduce the number of recipients in the header of the message for the host that you are receiving this NDR from. If you resend the message, it is placed in the queue again. If the receiving server is on line, the message is delivered.

You can see the problem is usually on the recipients server. Common causes are the recipients mail server is offline or otherwise unreachable, possibly due to DNS problems.

One thing you can try on the originators mail server is to increase the SMTP Virtual Servers Delay Notification and Expiration Timeout settings.

Also note that setting up a Reverse DNS record is not the same process you would perform while creating a host name or other record. With forward (regular) DNS you setup your name servers with your domain registrar, like Network Solutions. With reverse DNS you must contact your ISP to have them create and host the record. The reason why is because the ISP is who is ultimately responsible for your IP address, and only they can verify that your mail server does indeed reside at that particular IP address.



Nice, thank you for that breakdown. This explains why when we upgraded to Exchange 2007 from SBS 2k3 and changed public IP's that this is happening. The ISP must still have the RDNS for the old public IP.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
You guys rock. Requesting a RDNS record to be made by our ISP for the public IP of the Exchange server worked perfectly!  All emails are going through now!  :)
Great news, glad you got it working.
Cool.
Had a nightmare at work last week, new exchange server went live and I hadn't put in a reverse record (99% of the DNS I do is for web sites on shared servers, so no reverse, ever). Then the trouble began - main campus had control of reverse DNS for the subnet, and when they tried to transfer control to my DNS server, it wouldn't take. Took a day and a half and 6 people to figure it out and get it fixed. :)
Meanwhile the record for the OTHER exchange server on the same subnet started expiring out of people's caches.  Good times. Had to use an SMTP connector and route mail through an old mail server to get it going in the meantime.