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!

Subscribe to blog highlights mail

7 thoughts on “Why we tend to recommend NOT having a secondary MX these days

  1. I agree that using a backup MX does invite spammers to use this service to get around other protection systems you have in place. This is why you need to choose a backup mx service that is also a Anti Spam system. You then get the best of both worlds; a backup to your primary mail server and an anti spam filter anti virus system.

  2. I have another reason. When the receiver does a SPF check the sending domain is no longer correct. I have noticed correct incoming mail that was marked as spam because it arrived from a backup server causing a hard-fail on the SPF check. Mail can even bounce for this reason.

  3. I find that a good fallback arrangement is to use a hosting company’s POP3 account set as a domain catch-all. It needs to be of the type that provides an Envelope-To header identifying the true recipient. MDaemon’s DomainPOP feature can be set to retrieve this mail at less frequent intervals than the main mail cycle, say once very 15min, and deposit it in the correct mailboxes.

    Thus although this needs a backup MX record, it is one which points to a well-protected server and which does not allow improperly addressed mail through.

    • Hi Ian, thanks for sharing this advice.

      You’re right in that this process of providing a backup MX record that points to a catch-all mailbox (collected by POP3) works, however we’ve found this can actually serve to attract spammers. Typically the provider won’t offer the same level of spam detection and so more spam is detected via this path even when the primary MX record is active.

      For our typical customer, the work required to set up a backup MX server with the required level of protection outweighs the original issue of short term downtime.

      It’s certainly not the wrong thing to do, but it can be difficult thing to get right if you’re not in full control of this service. As you correctly pointed out, only a few good quality mail providers will add the correct ‘Envelope-To’ header which is a must for correct routing of email.

      Historically, one trick we have used is a third MX record that is in effect a carbon copy of the primary record pointing directly to the SMTP mail server. We used to do this as spamming servers tended to target the MX record with the lowest priority, and ignore the mid servers. Its not 100% effective but can help a little to reduce spam attacks against backup MX servers.

      Thanks again for the contribution!

  4. While it may be true a sending email server may make multiple attempts to send its email to your email server, if you regularly shutdown your email server during certain hours (the same hour each day) then I believe you run a strong chance of losing email you want. I receive email from a business that regularly sends its email during a time in the middle of the night when I may typically have my email server down. For months I have not been receiving this email even though I have a MX Backup Email server which is also a server on s third party service which does spam filtering. I thought perhaps the MX Backup Email Server was detecting it as SPAM erroneously but that wouldn’t seem to be the case as this same type of email comes to me using the same email address as recipient with the only difference being the company it references in an alert to me. The message body of the email is pretty much identical except for the company name it refers to. I have send using one of my own email ids the same email to the same email id with my email server down. The MX Backup Email Server catches the email and delivers it to me when my email server is brought back up. So it seems unlikely the MX Backup Email Server is filtering it as SPAM. The normal sender of this particular email indicates to me as well that they got bounce backs on the email and so they stopped trying after three attempts. So the theory that an email server will retry and eventually get the email to you isn’t foolproof either.

  5. Sorry I have to disagree, this recommendation sounds like total nonsense to me.
    A secondary MX with a different configuration or with less spam filters than the primary one is *not* a real secondary MX, it’s just a toy system and should not be used in a professional context.

    The secondary MX must be completely identical to the primary, with the same softwares, same versions, same checks, same configurations, same of everything, and if you do your homework correctly it will not pass any more spam than the primary.

    As for Briolet’s comment: you are speaking about outgoing email, which is a completely different topic. An MX server does not *send* email from you to the outside world, it receives mail from the outside world for you. Many people deploy a single server for MX and outgoing SMTP, and if that’s the case it’s just like I said above for the MX: you simply have to do everything equal for your primary and your secondary servers. If you put your primary server IP in an SPF record, just put in the same record the secondary server IP too and you’re good to go.

    I do recommend having more than one MX server if they are completely identical and correctly set up. I do not recommend having more than one MX server if the sysadmin is not good enough for its job.

    • Hi Luca,
      Yes I do agree with you , and in an ideal world Having two MS records pointing to too identical mail servers that have the same security and antispam detection setup is the best solution. But in my experience. This is very rarely the case, and What we actually see is the second MX record is setup as a Backup MX record pointing to an ISP’s mail platform. This typically has very little if no Anti-Spam setup often accepts email for any address on the domain and is simply a store and forward service for the primary server. In this scenario, the additional issues caused by having the Backup MX far outweigh the benefit of a store and forward feature and we don’t think it’s worth doing.

Let us know what you think....

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s