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
Aus meiner Sicht ist die folgende Konfiguration noch eine Steigerung der schlechten „Backup MX beim Provider“-Konfiguration. Im Prinzip ist die Ausgangslage die Gleiche wie oben schon geschildert, aber mit einer zusätzlichen Verschärfung. Der Backup MX beim Provider, stellt die Mails nicht an den bevorzugten MX zu, sondern speichert die Mails in eigenen Postfächern. Diese Postfächer werden dann mit POP3-Connector wie etwa POPcon oder Ähnlichem abgeholt und an den eigenen Mailserver zugestellt. So umgeht man also jegliche AntiSpam Maßnahmen des Unternehmens. Das Worst-Case Szenario ist schnell erklärt: Eine Malware Mail wird direkt an den Backup MX geschickt, landet via POP3 Connector direkt im Postfach des Anwenders, Anwender klickt auf bösen Anhang und die Ransomware breitet sich aus. Dies ist übrigens keine Fiktion, sondern leider genauso bei einigen Admins/Unternehmen passiert.
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
Ich dachte eigentlich, dass diese Konfiguration schon lange ausgestorben ist. Ich glaube diese Konfiguration hatte seine Hochzeit zu den „Windows Small Business Server Zeiten“. DAMALS wurde oft ein SBS Server als Eierlegendewollmilchsau in kleinen Unternehmen installiert. Da zu dieser Zeit kleine Unternehmen keine feste IP hatten und DSL Zwangstrennungen noch zum Standard gehörten, machte diese Konfiguration DAMALS noch einen gewissen Sinn. Diese Zeiten sind lange vorbei. Meiner Meinung nach handelt man sich hier nur Probleme ein, wie die beiden oberen Konfigurationen schon verdeutlichen sollten. In diesem Fall verlässt man sich komplett auf die AntiSpam Features des Providers und halst sich den Aufwand der Pflege der POP3 Postfächer auf. Die meisten Provider beschränken ihre AntiSpam Funktionalität auf das Nötigste, meistens sind dort nur ein paar Blacklisten konfiguriert. Ich habe in diesem Fall auch schon die wildesten Konfigurationen gesehen, diverse Umleitungen von einer Provider POP3 Mailbox zu einer anderen POP3 Mailbox und es war kaum noch festzustellen welche E-Mail Adresse denn nun wo an kommt. In diesem Fall kann ich nahezu dafür garantieren, dass halbwegs gut gemachte Phishing Mails oder Ransomware zugestellt wird. In dieser Konfiguration muss man als Admin nicht nur zwei Umgebungen verwalten (Provider und lokaler Exchange) und sich zusätzlich auch noch auf die AntiSpam Lösung des Providers verlassen. Es gibt hier auch Provider, welche scheinbar ein ganz einfaches Prinzip verfolgen: Lieber eine Mail zustellen, als sich auf eine False-Positive Diskussion mit dem Kunden einlassen. Ganz bitter wird es, wenn es dann auch CatchAll Postfächer gibt, welche einfach jede Mail annehmen. Hier befindet sich dann 99,99% Spam und oft gibt es dann auch noch eine arme Seele im Unternehmen, die aus 10000 Spam-, Phishing- und Malwaremails die eine Mail mit falsch geschriebenen Empfänger erkennen soll.
How to do it better
Die genannten schlechten Konfigurationen zu vermeiden ist eigentlich überhaupt nicht schwer. Wer aktuell noch eine der genannten Konfigurationen einsetzt, könnte beispielsweise recht einfach zu einem Cloud Spamfilter migrieren. Wer mal nach Cloud Spam Filter googled findet unzählige Anbieter und Lösungen. Bei einem Cloud Spam Filter zeigt der MX Eintrag auf den Anbieter des Spam Filters, der Anbieter sorgt dann für hoch verfügbare Systeme, sowie je nach Anbieter für moderne AntiSpam Features. Der eigene Server nimmt dann nur noch Mails via SMTP von den IP-Adressen des Anbieters an. In diesem Fall zeigt also kein MX Record mehr auf eigene Server. Ein Cloud basiertes AntiSpam System hat den Vorteil, dass man selbst keine eigenen Server mehr für das Filtern der Mails betreiben muss. Um die Hochverfügbarkeit muss man sich in der Regel auch nur wenig Gedanken machen, da dies der Anbieter übernimmt. Vom Prinzip her entspricht ein Cloud basierter Spam Filter dem Szenario „MX beim Provider“, es gibt allerdings wichtige Unterschiede: Ein Anbieter für Cloud basiertes AntiSpam betreibt E-Mail Security als Geschäftsmodell und nicht als „kleinen Service“ der wie bei einem Hoster oder Provider neben her läuft. Jedem der aktuell eine der drei genannten schlechten Lösungen betreibt, kann sich ja einfach mal bei folgenden Lösungen umschauen:
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:
Wie in dem Screenshot zu sehen ist, gibt es nur einen MX Eintrag welcher auf den Host „frankysweb-de.mail.protection.outlook.com“ zeigt. Der Host-A Eintrag für „frankysweb-de.mail.protection.outlook.com“ zeigt dann auf die beiden IPs 104.47.7.138 und 104.47.11.138. In kleinen Umgebungen könnten dies zwei redundante AntiSpam Appliances sein. In größeren Umgebungen könnten sich hier auch Loadbalancer zum Einsatz kommen, welche die Last auf viele AntiSpam Appliances verteilen und somit auch die Verfügbarkeit erhöhen.