I read a tip just recently that advocated the use of fake MX records as a spam deterrent.  The solution was apparently devised after struggling with the server load that was being generated by spam emails.

As we all know, spam makes up as much as 90% of global email traffic, so it is not unusual for spam load to be a serious issue for email server performance.  The natural instinct is to prevent that load from being applied to the server in the first place.  Fake MX records are not the best way to do this.

MX records are the DNS records that tell email servers where to send email that is addressed to a particular domain.  For example, if I send an email to john@company.com my email server will look up the MX record for company.com, determine the associated IP address, and transmit the message over SMTP to that IP address.

To maintain redundancy most organizations will use multiple MX records that point to multiple email servers, so that if one is unavailable the others can still receive incoming email.  MX records are given a priority, an arbitrary number that is only relative to the priority of other MX records for that domain.  The lower the number, the higher the priority.

So for the same example as above, my email server looks up the MX record for company.com and gets the following response.

company.com MX preference = 10, mail exchanger =
 maila.company.com

company.com MX preference = 20, mail exchanger =
 mailb.company.com

It knows then to send to maila.company.com first, and then try mailb.company.com if the first try is not successful.

The idea of fake MX records is to create multiple MX records (usually at least 3) of varying priority, and have the highest and lowest priority MX records be pointing to non-existent servers.  The theory is that spammer’s botnets will only try to send to the highest or lowest priority MX, and then when they get no response will give up and move on to the next victim.  Some email administrators use as many as 10 MX records with only one real one among them.

The theory has some merit.  Spammers want to send out as much email as possible so usually won’t waste time and resources by having their bots try multiple MX records for a targeted domain.  However the technique impacts legitimate senders as well.If my email servers are sending hundreds of thousands of outbound emails per day (this is not unusual for larger organizations), and the recipient domains are making use of fake MX records for spam prevention, then each time my server attempts to connect to a fake MX record it needs to wait for the time out period to elapse, store the email in its queue, and retry again.

In effect this means that while the receiving organization is trying to reduce their server load, they are increasing mine.  If enough organizations are doing this, they are increasing my server load by a very large amount.

This leads us to the second issue with this technique.  It only works if hardly anyone tries to use it.  If we all populated our DNS zones with fake MX records the spammers would quickly catch on and reprogram their bots to send spam to multiple MXes instead.

Now we’re back at square one, having invested time, effort, and server resources into a technique that is at best a short lived success.

Advocates of this technique seem to miss an obvious alternative.  Connection filtering, or IP filtering, is a much more effective method of blocking spam sent by botnets.  When an IP address is a known or likely source of spam it is blacklisted by organizations such as Spamhaus.  Email servers can be configured to check a sender’s IP address against these lists, and the check is performed at the earliest stage of an SMTP connection, making it fast and efficient.

Bad IP addresses are blocked, often resulting in as much as 90% of spam being blocked immediately with minimal server resource usage.  Good IP addresses are allowed to send the email message through for more thorough inspection.

And the best part of all is that it does not penalise legitimate senders by forcing them to try sending to multiple MX records before they are able to get through.