Delivery Status Notification (Delay)

I have several employees that are getting undeliverable messages due to delays such as:

-----Original Message-----
From: Administrator
Sent: Tue 5/16/2006 5:19 AM
To: xxxxx xxxxx
Subject: Delivery Status Notification (Delay)

This is an automatically generated Delivery Status Notification.



Delivery to the following recipients has been delayed.

and the status is 4.4.7

When I look at the Queues under the Default SMTP Virtual Server in the Exchange System Manager I notice that almost all are set to Retry and only about 5 of 50 are in a ready connection state and the rest alternate between active and retry connection state.  This problem just started yesterday and nothing has changed on the Server.  

Who is Participating?
SembeeConnect With a Mentor Commented:
If the problem was your blacklist error, then the message should bounce back immediately, not give a delay message.
Your reverse DNS doesn't match what the server is announcing itself as, and the server is announcing as something else other than what is in the DNS records. Again if that was causing a problem I would expect an immediately rejection - not a delay then timeout.

Timeouts are almost always down to connectivity or DNS. Everything else should result in immediate failure.


Cause: The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This NDR may also indicate that a message header limit has been reached on a remote server or that some other protocol timeout occurred during communication with the remote server.

Check this:
cvbgadminAuthor Commented:
Any insight as to why almost all of my queues keep retrying?
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

The delay message is close to useless. It just tells you that there is a delay without any reason for the delay.
You need to wait for the failure message to see what the NDR says.

Most common reasons for delay messages...

- the remote site is trying to use greylisting, but has bodged it.
- the remote site is trying to block your connection, but has bodged it.
- connection failure - that could also be a firewall causing a problem.
- DNS failure.

Any patterns to the messages sitting in the queues?
Do you use a smart host to send email, or try to send them directly?

cvbgadminAuthor Commented:
I'm not really seeing any pattern, there's just about 75 or so that are in retry status and some have several msg's that are needing to go out.  Also, we are trying to send them directly.  We don't use any type of smart host.  I just thought it was weird that so many of these couldn't send at once.
I would check your DNS configuration as the first step.

The DNS configuration is very simple.
All servers, including the Exchange servers should be pointing to domain controllers ONLY for DNS. No external DNS should be configured.
The domain controllers should be pointing to themselves.

The dns server applet on the domain controllers should be configured to use forwarders, which are your ISPs DNS servers.

If you are currently using that format, then check that the ISP hasn't changed their DNS servers. If they offer others, then try changing them.

You could also do an MX lookup test on the Exchange server to see if that throws up any errors.

For an external dns report on your domain, use and by the way, in the exchange queue, when you just click an email which states retry, is there a remark at the bottom of the queue window. Also check if you relay through
cvbgadminAuthor Commented:
I finally got a failed message but still no real help.  It just specifies # 4.4.7 which I already know that the reason is due to a delay.  I just don't know why or how to fix the problem.  I did go to and it showed our ISP as our parent DNS.  Here is a link of the results I received:  I'm not quite sure if some of the fialures have anything to do with our delay.  I also know that we are currently listed on sorbs, and our ISP is in the works of getting us delisted as it is an IP address range of theirs that we happen to fall into.  Although I think that if it were due to the sorbs listing then we would just be getting the rejections from the recipients server which we have gotten a few of and not just all getting delayed.  If anyone has any further insight as to how this can get fixed I would appreciate it.
cvbgadminAuthor Commented:
Oh, and the MX record is correct.
Hi Simon,

If the server is set to drop a connection should a name match an email address, wont this happen?

If the server has been set correctly to drop the connection, it should be seen as permanent failure and the message is NDR. My home Exchange server is on a residential internet connection and as such I see plenty of NDR messages when the message is blocked. I always get the NDR back immediately. I hardly ever have messages hang around in the queue, unless I have made a typo.

If something is interfering with the SMTP traffic, so that Exchange doesn't see the failure message, then that can cause messages to hang in the queues. It may not be the sending side that has the problem with SMTP interference. It could be the recipient. Firewalls are a classic cause.

The point is - messages in the queues means that the message hasn't been delivered - for some reason. If the message delivery had failed, then the message would not be in the queue.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.