Last week Exchange 2010 went live and I'm noticing in the queue viewer (in the exchange console) that it is coming up with a few emails that are having error 400 4.4.7 message delayed.

The kickback response that our members are getting is:

Delivery is delayed to these recipients or groups:

XXX@aol.com (XXX@aol.com)

Subject: test

This message hasn't been delivered yet. Delivery will continue to be attempted.

The server will keep trying to deliver this message for the next 1 days, 19 hours and 54 minutes. You'll be notified if the message can't be delivered by that time.

This is just one specific example and there are multiple for multiple domains that other email addresses work (for the same domain).

We are about to have our mail filtered through their filter and then come into the server but right now the MX record points directly into our exchange server.

Does anyone have any idea on how to resolve this? Or if moving to the filter (thus changing the address our MX record goes to ) will resolve this?


There are many possibilities that are involved with this error. Taken from this answer of mine on another question (but slightly modified):

First, try to establish an SMTP session with the remote mail servers using telnet to see if you can gain any more information.

It's also a possibility that some kind of oddball firewall rule has been set in place that drops, alters or otherwise tweaks packets to or from a domain or IP that is associated with the remote server. Unlikely, but I've seen stranger things. Check your gateway firewall as well as the Exchange server's software firewall for any rule that could have something to do with the remote SMTP server. Check for domains, IPs and any range of addresses that could be associated with the remote domain.

Another slim possibility is that the remote domain has DNS zone issues. Maybe their MX records are stale. Perhaps they performed a zone migration but never migrated everything to the new DNS server. Again, crazier things have happened.

Yet another possibility is that the receiving server is performing a reverse DNS lookup on your sending IP and it's not matching up with your MX records. If you MX record points to, but it's behind the firewall that is and a virtual IP is set up on the firewall to accept, then outbound traffic will be seen as, but RDNS will show as the mail server. That discrepancy can cause some receiving servers to reject the message in various ways (although I would hope the recipient email admin wouldn't suppress informative bounce messages, instead opting for generic failure messages).

(As a side note, RDNS checks like the above are foolish since many people have authenticated relays for outbound email and that, by necessity, will not match up to the inbound server. Email admins, don't be lazy!)

Lastly, but certainly not leastly, USE SPF RECORDS! DKIM too. You may find that many of your transient email problems just disappear after properly setting up those two things.

Of course, listen to Shane Madden and check your mail queue.

In the end, contact the remote domain's admins and work it out with them. You may have to work with them to figure the issue out.

  • Thanks for the answers! I've done the tests at testexchangeconnectivity.com and remember the reverse DNS lookup as coming back correct. – Lbaker101 Aug 18 '11 at 21:48
  • Until we get our email filter up (within the next day) the MX record points directly to our exchange server through a designated external IP. the ASA5505 does NAT Forwarding to point this into the correct internal address and the correct firewall ports have been opened to allow the email traffic through. I'll look into this more. Thanks for the advice! – Lbaker101 Aug 18 '11 at 21:50

Check your mail queue in the exchange management console's "Toolbox" section.

You'll be able to dig down into the specific errors that are being generated each time that the message is attempted to be delivered, which should shed some light on the root cause. Find a specific problem message in a domain queue, then right-click the message and open the properties; the "Last Error" section is what's of interest.

Likely causes are port 25/tcp connectivity and DNS resolution problems, but edit the errors you find into the question if you're still having issues and we can assist in determining the root cause.

  • Identity: XXX-XXX\4269\19930 Subject: XXXX Internet Message ID: <8485BDE284F83A4EB411BC822A8F564EA3F8EC@EFC-XXX.XXX.local> From Address: XX@XXX.com Status: Ready Size (KB): 11 Message Source Name: FromLocal Source IP: SCL: -1 Date Received: 8/18/2011 6:53:04 AM Expiration Time: 8/20/2011 6:53:04 AM Last Error: 400 4.4.7 Message delayed Queue ID: XXX-XXX\4269 Recipients: XXXw@XXX.com – Lbaker101 Aug 18 '11 at 21:33

Without further information this doesn't look strange. Some recipient's servers implement rate limit controls that prevent flooding their servers. Some messages go through straight away others have to wait (and tried again later).

If this issue is true for more than (let's say) 10% of your mails then you have problems with DNS resolution, your internal firewall or other strange network settings that prevent the mail flow on your site.

But this has absolutely nothing to do with your MX settings.


One other note, specifically for aol.com domains, if your company will be sending much mail to them (I don't know what the threshold is for them to start blacklisting you) you need to register your domain name with a postmaster contact on this website: http://postmaster.aol.com/Postmaster.Whitelist.php


The DNS the was setup on my Exchange server had been retired. I tried to ping a couple of the delayed mails domains and did not receive any resolution back.

I went into my networks settings on the server and update the Primary and secondary DNS.

Everything starting flowing fine again.

Hope this helps

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.