In this article I try to explain why you should avoid some special Backup MX configurations. The configuration of a Backup MX at the provider or hoster is outdated and should no longer be used.
Backup MX at the provider
I have often found the configuration with a backup MX entry for the provider. The MX records for a domain then look like this, for example:
frankysweb.de MX preference = 10, mail exchanger = MyServer.MyDomain.tld
frankysweb.de MX preference = 50, mail exchanger = BackupMX.MyProvider.tld
There is a preferred MX record (preference = 10), which points to your own Exchange server or your own AntiSpam gateway. Another MX record for the domain points to a relay at the provider (preference = 50). The idea behind this is as follows: If your own Internet connection or something in your own e-mail infrastructure fails, e-mails are no longer delivered to the preferred MX, but to the provider's backup MX. The provider temporarily stores the mails in its queue and delivers them when the function of its own e-mail infrastructure is restored.
Unfortunately, this configuration has a catch: as a rule, the backup MX entries are significantly less protected against spam and the like than the preferred MX entry. In most cases, there are no well-trained spam filters, sophisticated blacklists or other modern email security features. It is usually a very rudimentary relay that accepts almost any mail, puts it in the queue and delivers it to its own servers when they are available. Some providers even implement this so poorly that they do not even check whether the preferred MX is available or down and therefore simply accept everything that reaches the backup MX.
This configuration is particularly popular with spammers, because instead of sending the spam to the preferred MX, the MX with the highest preference is simply used. This MX accepts all the spam and forwards it.
You are not making things any easier for yourself here either, because your own spam filter can no longer perform some checks for spam if the mails are delivered via the supposedly trustworthy Backup MX. Blacklist, SPF and RDNS checks are the best-known checks that no longer work if the mail reaches your own AntiSpam solution via the Backup MX.
There is also another problem: mails to non-existent recipients, the Backup MX usually does not know which e-mail addresses exist and which do not. The Backup MX therefore first accepts all mails and forwards them. Only the own anti-spam solution or the own mail server performs the recipient check and replies to mails to non-existent recipients with an NDR. This is called BackScatter Spam, spammers generate spam with NDR messages by falsifying the sender and using them as recipients in the NDR. This spam is then also sent by the spammer's own mail server, as it generates the NDR. In the worst case, the spammer also attaches the spam to the NDR as an original message.
My opinion on the backup MX at the provider is as follows: Do not use it. Simply leave it out. I would say that in 99% of cases exactly one MX entry per domain is sufficient. To stick with the example from above, this MX would be sufficient:
frankysweb.de MX preference = 10, mail exchanger = MeinServer.MeineDomain.tld
As you can see, the MX refers to a Host-A record, so if you operate redundant systems, for example, you simply create two Host-A records in the DNS with different IPs. This way you also have simple load balancing via DNS Round Robin. If you only operate a small environment without redundancy, one Host-A with the IP is sufficient. If this fails, no more mails come in anyway and instead of the backup MX at the provider, the sender's mail servers now store the mails in the queues. Exchange, for example, keeps a mail that cannot be delivered in the queue for 2 days. That should be enough to get your own infrastructure up and running again.
Backup MX at the provider and POP3 mailboxes
In my view, the following configuration is an improvement on the poor "Backup MX at the provider" configuration. In principle, the initial situation is the same as described above, but with an additional aggravation. The backup MX at the provider does not deliver the mails to the preferred MX, but stores the mails in its own mailboxes. These mailboxes are then collected using a POP3 connector such as POPcon or similar and delivered to your own mail server. This bypasses any anti-spam measures taken by the company. The worst-case scenario is quickly explained: a malware mail is sent directly to the backup MX, lands directly in the user's mailbox via the POP3 connector, the user clicks on the malicious attachment and the ransomware spreads. Incidentally, this is not fiction, but unfortunately also happens to some administrators/companies.
Another reason to avoid this configuration is that the POP3 mailboxes at the provider must also be created and managed. The mailboxes at the provider must therefore be managed synchronously with the Exchange mailboxes to avoid backscatter problems or valid mails being rejected because a corresponding POP3 mailbox was forgotten to be created or deleted at the provider. In my opinion, this is twice the effort for a very limited benefit.
MX at the provider and POP3 mailboxes
I actually thought that this configuration had died out a long time ago. I think this configuration had its heyday in the "Windows Small Business Server times". Back then, an SBS server was often installed in small companies as the "egg-laying wool sow". Since at that time small companies did not have a fixed IP and DSL forced disconnections were still standard, this configuration still made a certain amount of sense back then. Those days are long gone. In my opinion, this only causes problems, as the two configurations above should make clear. In this case, you rely completely on the AntiSpam features of the provider and save yourself the effort of maintaining the POP3 mailboxes. Most providers limit their AntiSpam functionality to the bare essentials, usually only a few blacklists are configured there. In this case, I have already seen the wildest configurations, various redirections from one provider POP3 mailbox to another POP3 mailbox and it was almost impossible to determine which e-mail address was sent where. In this case, I can almost guarantee that halfway well-made phishing mails or ransomware will be delivered. In this configuration, the admin not only has to manage two environments (provider and local Exchange) and also rely on the provider's anti-spam solution. There are also providers who seem to follow a very simple principle: Better to deliver a mail than to get involved in a false-positive discussion with the customer. It becomes very bitter when there are also CatchAll mailboxes which simply accept every mail. There is then 99.99% spam and often there is also a poor soul in the company who is supposed to recognize the one mail with a misspelled recipient out of 10000 spam, phishing and malware mails.
How to do it better
Avoiding the bad configurations mentioned is actually not difficult at all. If you are currently still using one of the configurations mentioned, you could easily migrate to a cloud spam filter, for example. If you google cloud spam filters, you will find countless providers and solutions. With a cloud spam filter, the MX entry points to the provider of the spam filter; the provider then ensures highly available systems and, depending on the provider, modern anti-spam features. The provider's own server then only accepts mails via SMTP from the provider's IP addresses. In this case, no MX record points to your own server. The advantage of a cloud-based AntiSpam system is that you no longer have to operate your own servers for filtering emails. As a rule, there is little need to worry about high availability, as this is taken care of by the provider. In principle, a cloud-based spam filter corresponds to the "MX at the provider" scenario, but there are important differences: a cloud-based anti-spam provider operates email security as a business model and not as a "small service" that runs alongside it, as is the case with a hoster or provider. Anyone currently using one of the three poor solutions mentioned can simply take a look at the following solutions:
If no cloud solution is to be used, the MX record can of course point to your own servers. In this case, however, there should only be one MX record per domain. Different MX entries with different weightings are not necessary. If highly available servers are operated for mail reception, it is sufficient to create the Host-A entry to which the MX points with several IPs. Here is an example for my domain and Office 365:
As can be seen in the screenshot, there is only one MX entry which points to the host "frankysweb-de.mail.protection.outlook.com". The Host-A entry for "frankysweb-de.mail.protection.outlook.com" then points to the two IPs 104.47.7.138 and 104.47.11.138. In small environments, these could be two redundant AntiSpam appliances. In larger environments, load balancers could also be used here, which distribute the load across many AntiSpam appliances and thus also increase availability.
Es gibt auch POP3 Spam-Filter wie zum Beispiel bei der Sophos wenn man sich nicht auf den Provider verlassen will….
Die aber prinzipbedingt nicht so effektiv filtern können. Steht oben auch im Text.
Ich sag einfach mal danke. Ich denke den Grund gab die kürzlich geführte Diskussion im Forum. Ganz Hartnäckige wird auch das leider nicht überzeugen. Ich führe diese Diskussion schon seit Jahren in Foren und auch beruflich. Im letzteren Fall lässt sich das fast immer auf „dann müssen wir uns nicht um den Spam kümmern, sondern der Provider“ zurückführen. Und das unabhängig davon, wie gut oder schlecht das gemacht wird. ;)