Spam Dunk DNSRBL Blues - Everyone's a Spammer

Posted: 14/01/13

Debugging DNSRBL: setting your DNS server to always return a result is an epic FAIL

I sent one of my clients an email this morning, and was rather surprised to find that it bounced back. Since I'm responsible for maintaining their email system, it was my problem, not theirs.

The message was being returned with a 55X hard error code, and the reason given was that the sending server was listed in one of the DNS Realtime Block Lists that their mail system uses.

My initial reaction was complete paranoia, the implication being that one of my servers which I used to relay the mail, had got itself on a block list. I checked out the remove options on the site, and there was no listing for the server in question. A few more Google searches for blocklist check sites gave my server a clean bill of health. Odd, but reassuring.

While trying to sort this out, I removed the reject_rbl_client portions of the postfix configuration.

Next step was to manually debug the DNS RBL lookup process, since I was highly suspicious that something, somewhere was telling a lie. In order to use the RBL, you invert the octets of the IP address, and append the block list host and do an "A" record lookup.

So if your IP is, you would use:

host -t a

Trying that on the client's server, returned an IP address - which indicates that the IP is listed. However, when I tried it on several other servers, the response was NXDOMAIN, indicating that there was no DNS entry, and therefore that the IP was not listed.

Specifying a specific DNS server to use, e.g.:

host -t a

Yielded the NXDOMAIN result. Google's DNS would appear to be playing ball.

The finger then points at the DNS servers used by the client's server. I removed the offending server from the /etc/resolv.conf file, and inserted Google's DNS and followed up by reinstating the RBL check int the Postffix configuration. A test message was received OK, and I reported the malfunctioning DNS server to the hosting company.