E-Mails mit möglichst geringer Unterbrechung zu einem neuen Hoster umziehen
Wenn Sie E-Mails auf die Infrastruktur eines neuen Hosters umziehen müssen, bedeutet das nicht zwangsläufig einen 24-stündigen Ausfall, bei dem Nachrichten zurückgewiesen werden oder verschwinden. Das gefürchtete schwarze Loch entsteht, wenn Administratoren die Laufzeit von DNS-Caches ignorieren und alles in einem Schritt erledigen wollen. Bei einem Parallelbetrieb bleibt das alte System erreichbar, während das neue im Hintergrund synchronisiert wird. Umgeschaltet wird erst, wenn Quelle und Ziel abgeglichen sind.
Dieser Leitfaden beschreibt den konkreten Umschaltplan, mit dem Administratoren E-Mails bei möglichst geringer Unterbrechung auf einen neuen Hoster übertragen. Die technischen Grundlagen der Migration erläutert unsere Anleitung zur IMAP-Migration.
Warum die Big-Bang-Methode scheitert
Beim Big-Bang-Ansatz wird am Freitagabend alles kopiert, DNS umgestellt und auf das Beste gehofft. Er scheitert, weil Übertragungsraten nicht konstant sind. Drosselungen wie HTTP 429 und Bandbreitenlimits können eine Migration mitten im Lauf ausbremsen. Am Montagmorgen ist dann nur die Hälfte der Postfächer gefüllt und der Support wird überrannt.
Der professionelle Standard für den Umzug zu einem neuen E-Mail-Hoster ist der Parallelbetrieb. Sie stellen die neue Umgebung bereit, synchronisieren ältere Daten im Hintergrund und ändern DNS erst, nachdem Quelle und Ziel sorgfältig abgeglichen wurden. Wie Sie dabei Ihre Absenderreputation schützen, sollten Sie vor dem Start ebenfalls lesen.
Der E-Mail-Umzug in 4 Phasen
| Phase | Zeitpunkt | Maßnahme | Ziel |
|---|---|---|---|
| Vorbereitung | T-7 Tage | E-Mails, die älter als 30 Tage sind, per IMAP synchronisieren | 90% des Speichers ohne hohen Bandbreitendruck übertragen |
| TTL senken | T-48 Stunden | TTL für MX und SPF auf 300 Sekunden senken | Bei DNS-Caches, die TTL beachten, ein Umschaltfenster von etwa 5 Minuten ermöglichen |
| Umschaltung | T-Zero (Freitagabend) | MX-Einträge auf den neuen Hoster ändern | Neue eingehende E-Mails zum neuen Server leiten |
| Delta-Synchronisierung | T+1 Stunde | Neuere Elemente der letzten 30 Tage synchronisieren | Während des Übergangs an den alten Server zugestellte E-Mails übernehmen |
Phase 1: DNS-Ausbreitung und die 300-Sekunden-Regel
Geteiltes Routing, bei dem einige Absender den alten und andere den neuen Server erreichen, entsteht durch lange TTL-Werte der DNS-Einträge. Rekursive Resolver speichern MX-Einträge entsprechend der TTL im Cache. Ein üblicher Wert beträgt 86,400 Sekunden (24 Stunden). Wenn Sie MX ohne vorherige Absenkung umstellen, können zwischengespeicherte Einträge E-Mails noch einen ganzen Tag an den alten Server leiten. Wer E-Mails zu einem neuen Hoster umzieht, sollte die TTL deshalb zuerst vorbereiten.
Das Verfahren ist einfach: Prüfen Sie die aktuelle TTL, senken Sie die TTL von MX und SPF auf 300 Sekunden und warten Sie anschließend mindestens die Dauer der ursprünglichen TTL. Wenn Sie diese Wartezeit auslassen, bleiben ältere Cache-Einträge im Umlauf.
Die Falle mit 10 SPF-Abfragen
Während der Migration liegt es nahe, das SPF-include des neuen Anbieters neben dem alten einzutragen. Seien Sie vorsichtig. RFC 7208 begrenzt SPF auf 10 DNS-Abfragen. Mehrere Anbieter wie Google, Outlook und der neue Hoster können dieses Limit überschreiten, was zu PermError und Zustellproblemen führt. Reduzieren Sie SPF-Abfragen nur mit einem Verfahren, das die zugrunde liegenden IP-Adressen laufend pflegt, oder entfernen Sie während der Umschaltung vorübergehend nicht benötigte Marketingdienste. Weitere Hinweise bietet unser Leitfaden zur SPF-Einrichtung.
Phase 2: Datensynchronisierung per IMAP
Beim Umzug von E-Mails auf einen neuen Hoster läuft die Migration über das IMAP-Protokoll (RFC 3501). Dabei handelt es sich nicht um eine einfache Dateikopie, sondern um eine Synchronisierung von Zuständen. Werkzeuge wie imapsync übernehmen die aufwendige Arbeit, doch das Verständnis des Protokolls bleibt wichtig.
Das Gmail-Problem mit dem Geisterpostfach
Wenn Sie bei Gmail den Ordner All Mail migrieren und Labels wie Ordner behandeln, können Nachrichten mehrfach am Ziel erscheinen. Gmail stellt Labels über IMAP als Ordner dar, sodass eine E-Mail mit 3 Labels in 3 getrennten IMAP-Ordnern sichtbar sein kann und ein ungeeignetes Werkzeug diese 3 Darstellungen als getrennte Elemente behandelt. Die Dokumentation von Google zur Datenmigration beschreibt dieses Modell. Konfigurieren Sie das Migrationswerkzeug so, dass Labels passend zugeordnet werden, oder schließen Sie [Gmail]/All Mail gezielt aus.
Drosselung und Fehlercodes
Beim Umzug zu einem neuen E-Mail-Hoster müssen Sie mit Einschränkungen des Quellservers rechnen. Google kann die Verbindungsfehler 11001/11002 zurückgeben, wenn IMAP deaktiviert oder durch eine Firewall blockiert ist. HTTP 429 weist auf Drosselung hin. Bei vielen Anbietern werden Verbindungen oberhalb von 2 GB/hour/user eingeschränkt. Verwenden Sie ein Migrationswerkzeug mit exponentiellem Backoff, das Drosselungen erkennt und automatisch pausiert.
Phase 3: Auswirkungen auf E-Mail-Programme
Nach dem Umzug der E-Mails zum neuen Hoster ist die Serverseite häufig der einfachere Teil. Unser Leitfaden zum Übertragen eines Postfachs erklärt die DNS-Umschaltung im Detail. Auf den Endgeräten droht dagegen die Supportwelle.
Zertifikatskonflikt: Bleibt Outlook während der DNS-Umstellung geöffnet, verbindet es sich mit mail.yourdomain.com, das nun auf den neuen Hoster zeigt, verwendet aber möglicherweise noch alte Zugangsdaten. Darauf können SSL/TLS-Zertifikatswarnungen folgen. Empfehlen Sie den Benutzern, das E-Mail-Programm am Montagmorgen neu zu starten und die Verbindung zu prüfen.
Mobiles OAuth: Moderne mobile E-Mail-Programme verwenden OAuth-Token, die an einen bestimmten Mandanten gebunden sind. Je nach Client und Anbieter lässt sich das Konto erneut autorisieren oder neu konfigurieren. Andernfalls müssen Benutzer das alte Konto entfernen und eine neue IMAP-Verbindung hinzufügen.
Interne Routingschleifen: Nach der MX-Umstellung kann der alte Server die Domain weiterhin als lokal betrachten. Wenn Benutzer A auf dem alten System Benutzer B ebenfalls dort schreibt, stellt der Server lokal zu und Benutzer B, der bereits das neue Postfach liest, sieht die Nachricht nicht. Konfigurieren Sie den alten Hoster so, dass verspätet eintreffende E-Mails sicher an den neuen weitergeleitet werden, bis alte DNS-Caches abgelaufen sind. Deaktivieren Sie die lokale Zustellung erst nach einer geprüften Umstellung.
Der Rückweg: ein Sicherheitsnetz für die ersten 15 Minuten
Da Sie die TTL auf 300 Sekunden gesenkt haben, kann ein Rollback bei vielen Resolvern schnell greifen. Diese Vorbereitung erfolgte in Phase 1. Scheitert der Umzug zum neuen Hoster etwa an einer Firewall, an Lizenzen oder an ausbleibendem E-Mail-Fluss über 30+ Minuten, setzen Sie die MX-Einträge auf den alten Anbieter zurück. Bei Caches, die TTL beachten, kann neuer Traffic nach ungefähr 5 Minuten wieder dort ankommen. Andere Caches benötigen länger, deshalb müssen beide Systeme erreichbar bleiben und überwacht werden.
Wie TrekMail den Umzug vereinfacht
Beim manuellen Umzug zu einem neuen E-Mail-Hoster müssen Sie imapsync-Skripte verwalten, kryptische Fehler wie 0x800CCC0E auswerten und die DNS-Ausbreitung überwachen. TrekMail enthält eine IMAP-Migrationsfunktion, die bei unterstützten IMAP-Daten die Ordnerzuordnung, den Backoff bei Drosselung und Delta-Synchronisierungen automatisiert. Eine abschließende Abstimmung mit der Quelle bleibt erforderlich.
| Tarif | Preis | Geeignet für |
|---|---|---|
| Free | $0 | Tests und persönliche Domains (keine Karte erforderlich) |
| Starter | $3.50/mo | Kleine Unternehmen mit einer Domain |
| Pro | $10/mo | Mehrere Domains und anspruchsvolle Benutzer |
| Agency | $23.25/mo | MSPs, die 50+ Kundendomains mit gemeinsamem Speicher umziehen |
Alle kostenpflichtigen Tarife enthalten eine 14-tägige Testphase (Karte erforderlich). Für den Nano-Tarif ist keine Karte nötig.
TrekMail konzentriert sich auf leistungsfähige E-Mail-Speicherung und -Zustellung und bietet zusätzlich Kalender und Kontakte pro Postfach über CalDAV und CardDAV. Wenn Sie außerdem E-Mail mit Ihrer eigenen Domain einrichten möchten, führt Sie unsere Anleitung durch alle Schritte. Die Migration selbst überträgt nur E-Mails. Exportieren Sie Kalender und Kontakte beim alten Anbieter und importieren Sie sie, sobald die Postfächer aktiv sind.
Für Agenturen, die regelmäßig Dutzende Domains gleichzeitig zu einem neuen E-Mail-Hoster umziehen, bietet TrekMail gemeinsamen Speicher, bei dem sich 200 GB auf alle Domains verteilen lassen, verwaltetes SMTP mit bereits aufgebauter IP-Reputation und Vorlagen zur Bereitstellung, mit denen sich DNS- und Migrationseinstellungen auf 100 Domains anwenden lassen.
Fazit: E-Mails ohne schwarzes Loch umziehen
Ein erfolgreicher Umzug zu einem neuen E-Mail-Hoster erfordert die gleichzeitige Steuerung des Zustandswechsels bei DNS, Daten und Clientzugriff. Jeder Administrator sollte diese Komplexität einplanen. Das Ziel sind möglichst keine Rückläufer, keine verlorenen Daten und keine panischen Supportanrufe. Bereiten Sie die TTL von 300 Sekunden vor, arbeiten Sie im Parallelbetrieb, gleichen Sie die Daten abschließend ab und halten Sie einen Rückfallplan bereit.
Weitere Hinweise zur Wahl der passenden E-Mail-Plattform und zum Schutz Ihrer Domainreputation während des Wechsels finden Sie in diesen Leitfäden.
Zahlen Sie nicht länger pro Benutzer für Funktionen, die Sie nicht verwenden. Testen Sie TrekMail kostenlos und sehen Sie, wie E-Mail-Hosting für Administratoren aussieht.
