A reverse DNS (rDNS) query aims to identify the domain name for a given IP address. The query is fed with an IP, which is looked up at the DNS. If the IP has been published correctly through a DNS PTR record, the query returns the domain name for this IP.
This type of lookup is referred to as a reverse DNS query since it performs the inverse operation of a typical (forward) DNS query, where the IP address is retrieved for a given domain name.
Here we want our servers to pass the anti-spam rDNS tests, so we are considering the case where the tests are performed by foreign servers when we send out emails.
DNS MX, A, and PTR Records
We already mentioned PTR records, so let's expand further on this point. This article is not intended for DNS gurus or those aspiring to become one, so I don't plan to delve into any complex DNS discussions. We just look at a simple scenario that helps us explain how rDNS based anti-spam tests work.
You will be certainly aware that whenever setting up an internet facing email server for public consumption, it is required to create the necessary MX and A records at the DNS. These allow foreign senders to perform forward DNS queries and discover the IP of our servers, responsible for receiving incoming emails. In this case the need for MX and A records is almost impossible to overlook. Without these, we won't receive any emails from outside.
As an example this is what our MX and A record could look like. These are created at our external DNS server.
exchangeinbox.com. IN MX 10 mail.exchangeinbox.com.
mail.exchangeinbox.com. IN A 123.123.123.123
Here the MX record is identifying the host handling inbound emails for exchangeinbox.com. The A record is identifying the IP for this host. It is possible to have multiple MX records for failover, in which case the MX preference value (here set to 10) comes into play. The inbound server with lowest numeric preference value is the one a sender should try first. I am not going to delve much into multiple MX records. Let me just say that spammers will target your inbound email server irrespective of the MX preference value. Indeed they sometimes target servers with higher preference hoping that these are not protected by a spam filter.
In comparison to MX and A records, the need for PTR records is initially less obvious. Without it, emails will still flow in and out. However because of the wide adoption of the rDNS anti-spam tests, missing a PTR record causes the rejection of many outgoing emails.
In this discussion I emphasized two keywords, incoming and outgoing. The PTR record for our mail server has an impact on our outgoing emails. Missing, or even worst incorrectly configuring the PTR, may cause our emails to be classified as spam.
PTR records are created for us by the ISP providing the fixed IP and internet connectivity to our email server. We need to request the ISP to create a PTR so as the IP identifies our outgoing email server. This also means that the PTR is not located on the same DNS server as our MX and A records.
Most likely you will only have one email server handling both inbound and outbound emails. So if we continue on the MX and A records examples shown earlier, the PTR record would identify the name mail.exchangeinbox.com.
In more complex scenarios you may have more than one email server, one of which might be dedicated exclusively to deliver outgoing emails. This is a case worth watching out for because it is easier to get it wrong. Let's say we have an inbound server named mail.exchangeinbox.com and an outbound server named mailout.exchangeinbox.com. In this case, we need both a PTR for the outbound server IP pointing to mailout.exchangeinbox.com and also an A record such as:
mailout.exchangeinbox.com. IN A 222.222.222.222
The rule here is that our outbound server must have both a PTR and an A record. Starting from the host name we have to be able to get the IP through a forward DNS lookup. Starting from the IP we have to be able to get the host name through an rDNS lookup.
The Anti-Spam rDNS Test
We now see how the result of an rDNS query is employed in spam filtering. In practice there exists more than one method to employ rDNS in spam filtering. However here we discuss the most common type, the one that we should make sure our server never fails. This test goes like this:
The receiving server determines the IP of the sender. This could be obtained directly from the connection or extracted from the email Received headers.
Through an RDNS query the host name for this IP is retreived.
Next the host name is fed to a forward DNS query, obtaining the IP from the A record.
The test is successful if the sender IP matches the one returned by the forward DNS query.
This type of cross verification tests whether all DNS records are consistently identifying the same sender uncovering spoofing attempts.
Consider the case where a spammer legitimately obtains a fixed IP and gets the ISP to create a PTR record for him, pointing to mail.exchangeinbox.com. The spammer can also forge the email content including the 'From' header to make it look like it is a true exchangeinbox.com email. What the spammer cannot do, is create the A record, since the exchangeinbox.com DNS is controlled by its legitimate owner. Thus despite all his efforts the spammer will still fail the test.
Another example is the case involving infected machines that are suddenly transformed into an email server for spam distribution. In this case spoofing is even easier to identify since the spammer has no ability to create any of the DNS records.
Final Tips
Today we discussed a very common test used in spam filtering, targeting one of the key weaknesses in the spam distribution chain, the sender Identity.
The test is independent of email content. It also does not depend on information from external providers as in RBLs and other reputation services. It simply relies on the email server DNS configuration, something the sender is supposed to have control on.
This type of filter can cause some headaches to inexperienced administrators who too often overlook the need to create PTR records. Indeed some do question whether it is correct to block emails based on this criterion especially in the light that legitimate senders sometimes are caught in the trap. The counter argument is that accepting emails from incorrectly configured servers opens a window for spammers to exploit. The benefit of closing this window justifies the loss of some legitimate emails.
In all cases what really matters is that many are already employing such a filter so we did better have all necessary DNS records in place. Once we have the peace of mind that our emails aren't being blocked we can quietly decide whether or not we also want to filter emails in the same manner.