Immer wieder kommen Kunden auf uns zu, die ihre Emails mit einem externen Dienstleister (beispielsweise Office 365) oder einem externen Server (beispielsweise Exchange) verwalten wollen. Das ist grundsätzlich auch kein Problem. Das kann jeder Kunde schließlich selbst entscheiden. Es wird aber oft vergessen, dass dies in bestimmten (seltenen) Situationen zu Problemen führen kann.
Beispiel: Ein Kunde (nennen wir ihn mal beispielsweise Herr Meier) hat eine Domain und ein kleines Webhostingpaket für seine Webseite von G4W und lässt die MX Einstellungen der Domains auf seinen eigenen privaten Linux Server leiten, den er selber betreibt. Emails sollen also NICHT über die Server von G4W laufen, sondern lediglich die Webseite.
Problem Nummer 1: Viele der von Herrn Meier gesendeten Emails landen im Spamfilter der Empfänger, denn Herr Meier hat bei seinem kleinen Linux Server ja immer nur eine dynamische IP, die er von seinem ISP (Internet Service Provider), wie beispielsweise Telekom, bekommt. Emails von dynamischen IPs werden jedoch von den meisten Providern abgelehnt, da 99 Prozent des gesamten Spams im Internet von dynamischen IPs kommt. Um diesen Fehler auszuschließen, raten wir Herrn Meier nun, sich beispielsweise bei unserem Server anzumelden, um eine Email zu versenden. Dazu muss der Kunde natürlich vorher ein Email Postfach (via PLESK) angelegt haben. Das kann er machen, denn er hat ja schließlich ein Webhostingpaket bei G4W. Aber damit kommen wir auch direkt zu Problem Nummer zwei:
Problem Nummer 2: Um eine Email zu versenden, benötigt man prinzipiell nur drei Dinge. 1. Server, 2. Benutzer, 3. Passwort. Herr Meier bekommt nun eine Fehlermeldung „User unknown in virtual alias table“. Warum? Jeder Provider hat mit Spam und gekaperten Postfächern zu kämpfen. Spam verursacht sehr viel unnötigen Datenverkehr. Unsere Server sind so intelligent konfiguriert, dass sie vor dem Versand prüfen, ob die Emailadresse, von der gesendet werden soll, auf dem Server auch tatsächlich existiert. Es muss also nicht nur ein Postfach angelegt werden, sondern auch die Emailadresse. Im Falle des Herrn Meier muss die Emailadresse also sowohl auf dem G4W Server eingerichtet werden als auch auf seinem eigenen Server im Keller. Nun kann Herr Meier Emails versenden.
Problem Nummer 3: Neben den genannten Problemen gibt es aber auch noch Sonderfälle. Herr Müller (der Name ist ebenfalls fiktiv) hat seine Webseiten ebenfalls bei G4W und ist zufällig auch noch auf dem gleichen Server eingerichtet, wie die Webseite von Herrn Meier. Herr Müller möchte nun Herrn Meier eine Email senden. Diese Email erreicht Herrn Meier jedoch nicht. Warum? Die Server sind so konfiguriert, dass sie vor dem Versand prüfen, ob die Emailadresse, an die gesendet werden soll, auf dem Server existiert. Sollte sie existieren und es sich dabei um ein Postfach handeln, wird die Email effizient und direkt auf dem Server zugestellt, ohne Zeitverluste, ohne quer durch das Internet gesendet zu werden, ohne Datenverkehr zu verursachen. Folglich kommt die Email niemals auf dem externen Server an, obwohl die MX Einträge korrekt gesetzt sind und vom Kunden alle Emailadressen eigentlich korrekt eingerichtet sind.
Es gibt noch viele weitere Sonderfälle, die wir hier unmöglich alle auflisten können. Aber anhand dieser Beispiele können Sie sehen, dass man Email-Einstellungen, DNS-Einstellungen, MX-Einträge und Mailserver nicht einfach auf die „leichte Schulter“ nehmen sollte. Es gibt sehr viel zu beachten. Das ist auch der Grund, warum Endkunden in der Regel keinen direkten Zugriff auf diese Einstellungen haben. Wir bitten um Verständnis. Wenden Sie sich im Zweifelsfall an unser kompetentes Support Team.
Lesen Sie hierzu auch: http://de.wikipedia.org/wiki/SMTP-Relay-Server