400 4.4.7 message delayed

Question

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:

[email protected] ([email protected])

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?

Answer 1

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 192.0.2.1, but it's behind the firewall that is 192.0.2.2 and a virtual IP is set up on the firewall to accept 192.0.2.1, then outbound traffic will be seen as 192.0.2.1, but RDNS will show 192.0.2.2 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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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