@Hagen2000 Danke. Solche Art Einwände in so einer Form gewinnen immer mein Herz [sic!].
Und auch wenn ich das bereits wusste, sehr verständlich in der Intention. Daher hier gerne meine Mühe, meine Sichtweise auf Deine Argumente auszuführen:
1. Strato erlaubt im MX-Konfigurationsdialog explizit primäre + Backup-Mailserver.
Du kannst Deinen eigenen Server als Primär (niedrigste Priorität) eintragen und Stratos eigene Backup-Server (bx-ob.rzone.de / bxt-ob.rzone.de etc.) als Sekundär.
Wenn der Primär (Deine dynamische IP) nicht erreichbar ist, liefert Strato die Mail garantiert und stellt sie später garantiert zu, sobald Dein Server wieder online ist.
Das ist kein Zufall, sondern genau das Feature, das Strato für „eigenen Mailserver“-Nutzer anbietet. Die Backup-Server haben feste IPs (u. a. 81.169.146.152–159), die Du bei Bedarf whitelisten kannst. Damit entfällt das „Hoffentlich läuft sie in den Backup-MX“ fast komplett.
2. Die „fremder Kunde nimmt die Mail an“-Gefahr ist extrem gering – und der Backup greift trotzdem.
Ja, theoretisch könnte die alte IP nach Reassignment an einen anderen Kunden gehen, der zufällig Port 25 offen hat.
Aber:
- Die allermeisten ISPs (egal ob Telekom, Vodafone, O2 oder wo auch immer Deine dynamische IP herkommt) reassingen IPs nicht sofort und nicht an Mailserver-Betreiber.
- Ein korrekt konfigurierter fremder Server lehnt die Mail mit 5xx ab („relay not permitted“ / „no such domain“).
Moderne MTAs (Postfix, Exim, Gmail, Outlook, Microsoft 365 etc.) behandeln einen solchen 5xx nicht als endgültiges Scheitern, sondern probieren den nächsten MX-Eintrag (also Stratos Backup).
Genau das Gegenteil von „wird auch nicht dem Backup-MX zugestellt“. Das Verhalten ist seit Jahren Standard.
- Der echte Open-Relay-Fall (fremder Server nimmt einfach an) ist heute praktisch ausgestorben – solche Server landen sofort auf allen Blacklists und sind für den Betreiber selbst ein Albtraum.
In den letzten ~10+ Jahren gibt es praktisch keine öffentlich bekannten Fälle, in denen genau dieses Szenario bei einem Strato-Kunden mit dynamischem MX passiert ist.
3. Strato selbst geht davon aus, dass Du das machst. Strato hat extra eine eigene Anleitung „Eigenen E-Mail-Server einrichten mit MX-Record“ und dokumentiert das Backup-Verhalten detailliert.
Sie warnen nicht vor dynamischen IPs – sie bieten nur an, dass Du bei Problemen ihre Backup-Server nutzen kannst.
4. Praktische Mitigations, die das Risiko noch weiter senken (besser als „gar nicht machen“)
- TTL auf 60–300 Sekunden stellen → Änderungen der IP sind extrem schnell propagiert.
- Guter DynDNS-Client (z. B. der Synology DDNS-Client aktualisiert bei jeder IP-Änderung deines Providers, und zusätzlich regelmäßig (alle paar Minuten) der fast sofort nach IP-Wechsel updated.
- Die Propagation bei Strato ist schnell, weil Du den MX nicht auf eine Strato-interne A-Record zeigst, sondern direkt auf Deinen Synology-Hostnamen. Viele Nutzer betreiben genau dieses Setup (Synology MailPlus + Strato + DynDNS) seit Jahren stabil. Es gibt keine öffentlichen Fälle, in denen eine Mail wegen Reassignment an einen fremden Strato-Kunden ging. Das ist eine theoretische Falle aus meiner Sicht.
- Optional:
Strato Mail Basic oder Domain .de Paket mit vollwertigem Backup nutzen oder einen günstigen externen Backup-MX-Dienst (z. B. ImproveMX, Mailcheap) zusätzlich eintragen.
Fazit (konstruktiv):
Die Warnung „keinen MX ohne feste IP betreiben“ ist für paranoide oder geschäftskritische Setups verständlich, aber für ein typisches Strato-Mail-Basic- oder Domain-.de Szenario mit eigenem Server übertrieben vorsichtig.
Stratos eigener Backup-MX macht das Ganze robust, die Wahrscheinlichkeit eines echten Problems ist verschwindend gering und die Mitigations sind einfach.
Nochmals danke für Deinen Beitrag. Du wirst damit gerne verfolgt von mir. Hab einen schönen Sonntag und eine gute Woche!
