To make a long story short, some users at another company who I have a lot of email correspondence with started having problems sending me email, they would get a message from the mailer daemon at MessageLab (which hosts their email) that Delivery is delayed to these recipients or distribution lists:, etc. etc. Since the message was coming from their server and nobody else was having a problem sending me mail, I figured the problem must be on their end, but just to be sure I checked with Rackspace (who hosts our email). Sure enough, none of the affected emails had hit our server at any point, which isn't surprising at all because none of them ever actually left their server[s] at MessageLab as it turns out. According to what MessageLab is telling them, UltraDNS handles Rackspace's DNS and UltraDNS has blacklisted some of MessageLabs's IPs, with the end result that their server is unable to do a DNS lookup for our MX, which is why the mail is not getting sent, much less delivered.
My question is does this make any sense? My knowledge of the workings of DNS is high-level at best, but it seems unlikely that a) there would be a blacklist on doing DNS lookups,or b) that even if the authoritative nameserver did have such a blacklist that it would come into play all that much due to the distributed nature of DNS. I realize of course that there are blacklists of IPs used to filter spam and the like, but my understanding is that that's something that the server receiving email would use to do a lookup of the sender's IP, not something that would affect the originating server's ability to query the DNS system. But maybe I'm wrong?
Edit: In case it helps, here's an example of the message log that shows the failure; this is what was sent to me from the tech person at the other company — I think it's the output from an admin panel, but I don't really have any more info than what's below:
2013-01-23 06:13:25 Connection from: xxx.xxx.x.xxx
2013-01-23 06:13:25 Sending server HELO string: xxxxxxxxxx.xxxxxxx.com
2013-01-23 06:13:25 Message id:
2013-01-23 06:13:25 Message reference: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2013-01-23 06:13:25 Sender: xxxxx@xxxxxx.com
2013-01-23 06:13:25 Recipient: xxxxxx@xxxxxx.com
2013-01-23 06:13:26 SMTP Status: OK
2013-01-23 06:13:27 Delivery attempt #1
2013-01-23 06:13:27 Recipient server: 0.0.0.0
2013-01-23 06:13:27 Response: 421 4.4.0 [internal] no MXs for this domain could be reached at this time
2013-01-23 06:19:57 Delivery attempt #2 (final)
2013-01-23 06:19:57 Recipient server: 0.0.0.0
2013-01-23 06:19:57 Response: 421 4.4.0 [internal] no MXs for this domain could be reached at this time
I've replaced all of the identifying bits obviously, but just to make it clear, the bit about Recipient server: 0.0.0.0 is what's actually in the log.
Best Answer
Yes, it is possible to blacklist IPs for probing DNS. Imagine a scenario where an abusive user probes the DNS server million times a second (just figurative number). It would certainly cause a strain. Such are reasons for blacklisting IPs for DNS inqueries.
Ironically, this is a bit of a self-fulling scenario. You make a request because there is no entry in the cache. Then it denies the request and thus saves nothing in the request. Then you repeat the situation ending up making countless requests.
I (or we) cannot conclude how MessageLabs would have structured their DNS resolution. However, if they set it so that they are the last fetcher from UltraDNS for your MX records, this scenario can indeed occur.
The only resolution is to either 1) un-blacklist their IPs by ultradns. or 2) they use a different DNS system one way or another. or 3) make hard links for dns by attaching IP to hostname in the hosts file for the sender.