02 Jul Why we tend to recommend NOT having a secondary MX these days
I often speak to users of Exchange alternative MDaemon who are wondering why they’ve suddenly started receiving a larger volume of spam than usual.
When I take a look at their installations it’s not uncommon to find a secondary mail server in place with its own MX record.
It’s this second delivery path that can be the root cause of the problem and it’s not unusual for the customer to be blissfully unaware either, as quite often they’re configured by the DNS provider or their ISP automatically.
What is an MX Record
Short for mail exchange record, an MX record is an entry in a domain name database that identifies the mail server that is responsible for handling e-mails for that domain name. Multiple MX records can be created and are assigned a priority, which a sending server uses to determine which server is responsible for receiving the email for a specific domain.
Why would you have more than one MX record?
A common worry with using SMTP for email delivery is what happens in the event the SMTP server is offline and therefor unavailable to receive email. The typical response to this is to set up a backup path and to use a secondary server to accept and queue the messages, delivering them when the primary server returns.
This is configured by creating a secondary MX record pointing to the backup SMTP server and assigning it a lower priority. The idea is that the primary server should receive the email if available and only if this server is off line should the secondary one be used.
Why is it not a good idea to use secondary MX records?
Unfortunately spamming servers make use of this configuration and target the secondary MX record even when the primary is available, turning them into what we refer to as spam “honeypots”. They do this as secondary records usually point to email servers that deploy little or no security checks such as those you’d find at some ISP’s for example. This encourages the spamming servers to keep sending even more as they can see it’s being accepted and so the vicious circle continues.
MDaemon includes spam detection so won’t it just delete all the spam?
Well yes and no! MDaemon has an impressive array of antispam technologies, particularly when combined with the SecurityPlus plug-in. Some work by looking at the contents of the message and these will still help detect for spam messages arriving via the secondary MX.
There are however, many other detection methods in MDaemon that work by detecting the sending server IP address, frequency or connection – even what destination addresses have been attempted or failed authentication attempts. These are all valid methods to help detect spam that will become completely useless if all the messages arrive from a single “known” mail server. In effect you can only deploy about 20% of the security checks to messages that arrive in this way.
Even the Commtouch Outbreak Protection module in MDaemon is compromised in this mode as you’re not seeing the original sender’s details in the message header. This is why so much additional spam arrives at the user’s mailbox when using secondary MX records.
Conclusion
We generally don’t recommend the use of secondary MX records as the more astute of you will have gathered! The only benefit really is the ability to continue to receive and queue messages that are sent to your domain when your server is unavailable. As a sending server would typically queue these messages for many days anyway, retrying regularly – in my opinion the negative impact of the additional spam you are likely to receive far outweighs this small benefit.
If you’re unsure of how your domain is configured, why not visit mxtoolbox.com, enter your domain and see how many MX records you have and where email for your domain actually goes, you may be surprised!
