28 Apr Using Reverse Lookups to Reduce Spam

To the unfamiliar, the ‘Reverse Lookup’ might sound like something you’d see in one of Tom Daley’s diving routines.

However in email and DNS terms, it’s an essential security check which can dramatically reduce the amount of spam you’re seeing. It’s also one of those many tricky DNS areas that causes confusion so I hope this post will help demystify it a little.

What is a reverse lookup?

The reverse lookup is a simple verification check that helps your email server quickly differentiate between valid email senders and potentially compromised machines hijacked for the purpose of sending spam.

How do they work?

The simplest way of explaining the reverse lookup is that it’s basically just the exact opposite of your standard DNS ‘A’ record. With an “A” record you will configure a user-friendly name that forwards visitors to a public IP address.

In the case of a reverse lookup, your server already has the IP address, because that’s visible immediately in the message header when the mail arrives. A reverse lookup is simply checking the sender’s IP address against the information held at the ISP for that domain to check it’s genuine.

The idea being that if the session was coming from a compromised PC/ spammer, the reverse DNS lookup entry it’s checking against would be highly unlikely to exist – making it a very effective early check.

Note – you’ll need to set this up with your domain hosting provider/ ISP. It should be as simple as sending an email to their support team letting them know you’d like a PTR record set for your IP address that resolves to mail.yourdomain.com..

Other benefits

One of the great things about using a reverse lookup check to determine the legitimacy of a domain is that you don’t need to accept the whole message body to run the check.

The check only needs information in the message header which gets passed very early on in the SMTP conversation. It happens long before the body of the email message is actually accepted, so if it looks like spam, it’s simply refused, save your bandwidth and server resources.

Generic PTR records (set by your ISP)

Sometimes when a reverse lookup check is performed, a valid record is returned but it’s not pointing to a simple ‘A’ record such as ‘mail.yourdomain.com’, it’s pointing to a generic one set by the ISP.

As shown above, a good indication of a generic PTR record is the fact the host name ’33-35-12-100′ is actually the IP address in reverse, and punctuated with hyphens instead of using dots.

This format is technically a valid PTR record as it does point to a valid ‘A’ record, but they’re not suitable for reverse lookup checking because they’re generic nature so should always be updated as soon as possible.

To check your current PTR record you can visit MX Toolbox one of our favourite resources for all things DNS and email related.

To block or not to block?

Our recommendation is that you always block mail from servers without valid PTR records, as do all of the major email domains including Google, Microsoft, Yahoo etc.

There will of course be occasions when you’ll be blocking mail from some valid mail servers that don’t have PTR records but you can always whitelist those while you let the administrator know.

In our opinion this is a much better approach than allowing a large number of compromised servers to establish connections.

Other reverse checks worth knowing about

‘HELO/EHLO’  

The HELO statement is the first part of the SMTP conversation between mail servers, effectively when the remote server identifies itself.

Good practice is to configure your mail server to identify itself as it’s Fully Qualified Domain Name (FQDN), e.g mail.zensoftware.co.uk.

By doing this, receiving servers can check to see if there’s an ‘A’ record set for mail.zensoftware.co.uk.

In my experience, there are still plenty of genuine mail servers using poorly configured HELO statements such as ‘Mail-Server’ or ‘localhost’ instead of a valid FQDN, so in this case I would simply keep a close eye on the logs rather than refuse these outright.

‘MAIL’

Spamming servers tend to either spoof the ‘Mail From’ address, or use an invalid server name all together. So the last of the checks is an effective one.

Similar to the HELO/ EHLO example above, this check looks for valid domain names within the SMTP ‘Mail From’ command. So when a sending server sends this command it is used to acknowledge what the envelope sending address is.

I recommend you get fairly hardcore with these and block any senders with a ‘Mail’ command using a domain that is not valid. Again, you will stop some valid email senders with badly configured mail servers, but those administrators do need to be alerted and this will slash the amount of spam you see quite dramatically.

Get checking!

Hopefully that’s given you the inspiration to take a closer look at your own domain configuration – please feel free to let me know how you get on in the comments.

If you’re a Zen Software customer using either MDaemon Messaging Server or SecurityGateway for Exchange, you’re welcome to get in touch if you’d like any advice setting up these checks.