Wenn Sie E-Mail zu einem neuen Anbieter umziehen möchten, ist das Kopieren alter Nachrichten nicht die größte Hürde. Schwieriger ist es, den Eingang neuer Nachrichten aufrechtzuerhalten, während DNS-Einträge noch im Cache liegen, Nutzer weiterhin auf Senden klicken und alte Geräte noch den falschen Server ansprechen. Genau hier geraten Migrationen ins Stocken. Wenn Sie Ihre langfristige Lösung noch auswählen, beginnen Sie mit dem Thema geschäftliche E-Mail, damit Sie die Einrichtung nicht zweimal vornehmen müssen.
Viele Anleitungen lassen den Umzug einfach erscheinen: exportieren, importieren, MX ändern, fertig. In der Praxis greift das zu kurz. E-Mail-Systeme verwalten laufend veränderliche Daten. DNS-Antworten werden zwischengespeichert. IMAP-Übertragungen brauchen Zeit. Und Nutzer halten sich nicht immer an den Ablaufplan. Wer E-Mail wie eine Website umzieht, riskiert, dass Nachrichten im alten Postfach, im neuen Postfach oder auf einem Telefon verstreut liegen.
Der Ansatz ist überschaubar, aber nicht sofort erledigt: altes und neues System parallel betreiben, historische Nachrichten vorab übertragen, die DNS-TTL rechtzeitig senken, in einem kontrollierten Zeitfenster umschalten und vor der Abschaltung des alten Dienstes einen letzten inkrementellen Abgleich durchführen.
Dies ist eine praxisorientierte Anleitung, kein Versprechen von „null Ausfallzeit“. Sie beschreibt ein Vorgehen für die Rahmenbedingungen von 2025-2026.
Warum E-Mail-Migrationen scheitern
Für einen sorgfältigen E-Mail-Umzug müssen Sie die Übergangsphase einplanen. DNS-Änderungen werden zu unterschiedlichen Zeiten sichtbar. Einige Absender erreichen deshalb noch den alten Mailserver, während andere bereits den neuen ansprechen. Ohne einen Plan für diese Phase können Nachrichten übersehen werden.
Wenn jemand an Ihre Domain schreibt, fragt dessen Server die MX-Einträge ab. Rekursive Resolver, Mailgateways und andere Infrastruktur im Internet speichern diese Antworten zwischen. SMTP selbst ist in RFC 5321 beschrieben. Das praktische Problem liegt jedoch im Betrieb: Nicht alle sendenden Systeme aktualisieren ihre DNS-Daten gleichzeitig.
Dadurch entsteht eine Phase mit zwei Zustellzielen:
Absender A sieht noch den alten MX-Eintrag und stellt beim alten Anbieter zu.
Absender B sieht den neuen MX-Eintrag und stellt beim neuen Anbieter zu.
Ihr Nutzer prüft nur ein Postfach und glaubt, Nachrichten seien verschwunden.
Deshalb ist ein Umzug nach dem Motto „Freitagabend Einträge ändern und hoffen“ riskant. Wenn Sie Unterbrechungen beim Anbieterwechsel möglichst vermeiden möchten, brauchen Sie eine gestaffelte Migration und keinen einzelnen Umschaltvorgang.
Was Sie vor jeder DNS-Änderung erfassen sollten
Erstellen Sie vor dem Umzug ein vollständiges Inventar: Postfächer, Aliase, gemeinsam genutzte Adressen, Weiterleitungen, inaktive Konten und besonders große Postfächer. Die Nutzerzahl allein sagt wenig über den Aufwand aus.
Beginnen Sie mit den Postfächern, die häufig den größten Aufwand verursachen:
- Große Postfächer. Alles über 20-50 GB sollte gesondert geplant werden, da IMAP-Migrationen Zeit benötigen und Anbieter die Übertragung drosseln können.
- Gemeinsam genutzte Adressen. `info@`, `sales@` und `support@` sind häufig keine gewöhnlichen Benutzerpostfächer.
- Aliase und Weiterleitungen. Wenn `jane@` auch Nachrichten für `hello@` und `jd@` erhält, müssen diese Zuordnungen im Zielsystem von Anfang an bestehen.
- Postfächer ehemaliger Mitarbeiter, die noch Nachrichten empfangen. Solche unauffälligen Fehlerquellen fallen oft erst Wochen später auf.
Ohne diesen Schritt beruht der Migrationsplan auf Vermutungen statt auf einer belastbaren Bestandsaufnahme.
Google weist ausdrücklich darauf hin, dass intensive IMAP-Synchronisierung Schutzmechanismen für die Bandbreite auslösen kann. Die im Quellstand genannten Google-Workspace-Richtwerte liegen bei 2500 MB IMAP-Download und 500 MB IMAP-Upload pro Tag. Bei Überschreitung können Sperren bis zu 24 Stunden dauern; die geltenden Bedingungen sind beim Anbieter zu prüfen. Deshalb kann das Kopieren eines großen Postfachs Tage statt Stunden beanspruchen.
Bei TrekMail spielt auch das Kostenmodell eine Rolle. Laut Quellstand beginnen kostenpflichtige Tarife bei $3.50 pro Monat, nutzen gemeinsamen Speicher statt einer Abrechnung pro Nutzer und enthalten ab Starter ein serverseitiges Migrationstool. Je nach aktuellen Konditionen kann dies helfen, das Zielsystem früh bereitzustellen und lange Importe im Hintergrund abzuwarten, ohne parallel nutzerbasierte Lizenzen bezahlen zu müssen.
Ein bewährtes Vorgehen für den E-Mail-Umzug
Ein sorgfältig geplanter Umzug setzt auf Parallelbetrieb: zuerst das Zielsystem einrichten, alte Nachrichten vorab kopieren, die DNS-TTL vor dem Wechsel senken, MX in einem kontrollierten Zeitfenster umstellen und anschließend einen letzten inkrementellen Abgleich durchführen.
Der Ablauf sieht so aus:
1. Zuerst das Zielsystem aufbauen
Legen Sie Domain, Postfächer, Aliase und Weiterleitungsregeln auf der neuen Plattform an, bevor Sie MX ändern. Bei TrekMail bedeutet das: Domain hinzufügen, die DNS-Konfiguration auf Bereitschaft prüfen und die Zielpostfächer vor Beginn der Importe erstellen.
Hilfreiche Dokumentation: Domain hinzufügen, IMAP-Migration starten und IMAP-/SMTP-Einstellungen.
2. Alte Nachrichten vorab übertragen
Kopieren Sie ältere Nachrichten vor der Umschaltung. Ein verbreitetes Vorgehen ist, zunächst alle Nachrichten zu importieren, die älter als 30 Tage sind, und die jüngeren Nachrichten für den abschließenden Durchlauf aufzubewahren. So erledigen Sie einen großen Teil des Umzugs ohne unmittelbaren Zeitdruck.
Das Migrationstool von TrekMail übernimmt Nachrichten von externen IMAP-Servern, etwa Gmail, Outlook oder cPanel-basierten Anbietern, in ein bestimmtes TrekMail-Postfach. Aktivieren Sie das Überspringen von Duplikaten und prüfen Sie das Ergebnis, bevor Sie Aufträge erneut ausführen.
3. TTL bereits 48 Stunden vorher senken
Senken Sie die TTL der MX-Einträge und der zugehörigen DNS-Einträge etwa 48 Stunden vor der Umschaltung. 300 Sekunden können dafür ein praktikabler Ausgangswert sein. Sobald ältere Cache-Einträge abgelaufen sind, kann dies die Übergangsphase verkürzen. Aus einer niedrigen TTL lässt sich jedoch keine verlässliche Wirkung auf Spamfilter ableiten.
Wenn Sie auch die Versandkonfiguration ändern, prüfen Sie DNS besonders sorgfältig. Die DNS-Dokumentation von TrekMail nennt einen häufigen Fehler: einen zweiten SPF-Eintrag anzulegen, statt die Includes in einem einzigen Eintrag zusammenzuführen.
4. Änderungen am alten System unterbinden
Bitten Sie die Nutzer zum Umschaltzeitpunkt, keine Nachrichten mehr über das alte Konto zu senden. Bei besonders sensiblen Umzügen kann es sinnvoll sein, Anmeldungen alter Clients zu sperren, damit nicht weiterhin gesendete Nachrichten auf dem falschen Server entstehen.
5. MX ändern und anschließend extern prüfen
Aktualisieren Sie die MX-Einträge und prüfen Sie dann, welche Antworten von außen sichtbar sind.
dig mx example.com +short
nslookup -type=mx example.comVerlassen Sie sich nicht allein auf das DNS-Dashboard. Führen Sie Abfragen von außerhalb aus.
6. Den inkrementellen Abgleich ausführen
Starten Sie nach der MX-Umstellung einen weiteren Importdurchlauf. Er erfasst Nachrichten, die während der Übergangsphase noch beim alten Anbieter angekommen sind. Dieser letzte Durchlauf hilft, auch den eingehenden Verkehr aus den letzten Stunden des Umzugs zu übernehmen.
7. Alten Benutzerzugriff zeitnah abschalten
Sobald Sie geprüft haben, dass neue Nachrichten beim neuen Anbieter ankommen, deaktivieren Sie Benutzeranmeldungen am alten System. Alte Telefoneinstellungen sind eine konkrete Fehlerquelle: Sendet ein Telefon weiter über das alte Konto, landen Antworten im neuen Postfach, während gesendete Nachrichten auf dem alten Server verbleiben. Der Gesprächsverlauf wird dadurch aufgeteilt.
DNS-Einträge, die sich beim Wechsel gewöhnlich ändern
Beim E-Mail-Umzug sind MX für eingehende Nachrichten und meist SPF, DKIM und DMARC für authentifizierten Versand entscheidend. Unpassende alte Einträge können zu Problemen bei Zustellung und Absenderreputation beitragen.
Die konkreten Werte unterscheiden sich je nach Anbieter. Das Grundmuster sieht so aus:
; Incoming mail
example.com. 300 IN MX 10 mail.your-new-provider.tld.
; SPF - keep only one SPF TXT record
example.com. 300 IN TXT "v=spf1 include:your-sender.example -all"
; DKIM - provider-specific selector and key
selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
; DMARC
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Zwei Regeln sind besonders wichtig:
- Veröffentlichen Sie niemals zwei SPF-Einträge für denselben Hostnamen.
- Entfernen Sie alte Versandeinträge erst, wenn feststeht, dass nichts mehr über den bisherigen Dienst sendet.
Wenn Gmail für Ihre Empfänger relevant ist, beachten Sie die Anforderungen an Absender. Die im Quellstand zitierte Google-FAQ beschreibt Massenversender als Absender von ungefähr 5,000 oder mehr Nachrichten pro Tag an private Gmail-Konten. Sie müssen ihre Nachrichten authentifizieren; für November 2025 wurde eine strengere Durchsetzung angekündigt. Maßgeblich sind die jeweils geltenden Angaben in Googles FAQ zu den Anforderungen an Absender.
Was beim E-Mail-Umzug tatsächlich schiefgeht
Die meisten Migrationsprobleme sind keine spektakulären Ausfälle. Es sind unauffällige Unstimmigkeiten: doppelte oder übersprungene Nachrichten, falsche Ordnerzuordnungen, alte Geräte mit Versand über den bisherigen Server oder nur teilweise angepasste DNS-Einträge.
Dies sind die typischen Fehlerbilder:
IMAP-Drosselung
Der Import großer Postfächer kann mittendrin stocken, insbesondere bei Gmail. Wer einfach noch mehr parallele Übertragungen startet, kann zusätzliche Begrenzungen auslösen. Deshalb ist die Vorabübertragung wichtig.
Doppelte Nachrichten
Ungeeignete Wiederholungsdurchläufe oder schwache Einstellungen zur Duplikaterkennung können Nachrichten erneut kopieren. Nutzen Sie Optionen zum Überspringen von Duplikaten und prüfen Sie anschließend die Anzahl der Nachrichten.
Probleme bei der Ordnerzuordnung
Gesendete Nachrichten landen oft im falschen Ordner, weil ein System `Sent`, ein anderes `Sent Items` und ein weiteres einen Pfad mit Namensraum verwendet. Wenn Nutzer verschwundene Nachrichten melden, prüfen Sie zunächst, ob diese nur im falschen Ordner liegen. Der TrekMail-Blogbeitrag zu imapsync erläutert solche betrieblichen Details.
Weiterhin aktive alte Postfächer
Nach der Umschaltung können Nachrichten noch beim alten Anbieter ankommen, weil Cache-Einträge noch gültig sind oder irgendwo ein alter MX-Eintrag besteht. Genau dafür ist der inkrementelle Abgleich vorgesehen.
Alte Clients senden weiter über den falschen Server
Telefone und Outlook-Profile behalten ihre Einstellungen bei. Nach dem Umzug brauchen Nutzer aktualisierte IMAP-/SMTP-Einstellungen, sonst sprechen sie weiter das falsche System an. Wenn Sie dabei auch Zuständigkeiten für Postfächer und Zugriffsrechte neu ordnen, lohnt sich der Beitrag zur Verwaltung von Kunden-E-Mail-Konten.
Die Migration anhand belastbarer Daten prüfen
Nach dem E-Mail-Umzug sollten Sie sich auf konkrete Prüfungen statt auf einen guten Eindruck verlassen. Fragen Sie nicht nur, ob alles „richtig aussieht“. Vergleichen Sie die Nachrichtenanzahl der Postfächer, testen Sie die laufende Zustellung, prüfen Sie gesendete Nachrichten und kontrollieren Sie, ob der alte Anbieter noch Verkehr empfängt.
Nutzen Sie diese Checkliste:
- Vergleichen Sie für jedes Postfach die Anzahl der Nachrichten in Quelle und Ziel.
- Senden Sie Testnachrichten von einem externen Anbieter an mehrere Adressen, einschließlich Aliasen und gemeinsam genutzten Postfächern.
- Antworten Sie aus dem neuen Postfach und prüfen Sie, ob die Nachricht im Ordner für gesendete Nachrichten beim neuen Anbieter erscheint.
- Prüfen Sie, dass der alte Anbieter keine Benutzeranmeldungen mehr zulässt.
- Führen Sie externe MX-Abfragen aus mehreren Netzwerken durch.
- Prüfen Sie stichprobenartig ungewöhnliche Ordnernamen, Archive und verschachtelte Strukturen.
Vergleichen Sie nicht den Speicherverbrauch in Gigabyte zwischen Anbietern. Die Berechnung unterscheidet sich zu stark. Vergleichen Sie stattdessen die Anzahl der Nachrichten.
| Prüfung | Auffälliges Ergebnis | Häufige Erklärung |
|---|---|---|
| Nachrichtenanzahl | Im Ziel ist die Anzahl geringer | Nachrichten wurden übersprungen oder durch Drosselung noch nicht übertragen |
| Alias-Zustellung | Hauptadresse funktioniert, Alias nicht | Alias fehlt im Zielsystem |
| Gesendete Nachrichten | Versand funktioniert, Gesprächsverlauf ist aufgeteilt | Client verwendet noch altes SMTP oder altes Konto |
| Externe MX-Abfrage | Resolver liefern unterschiedliche Ergebnisse | Die TTL-bedingte Übergangsphase läuft noch |
| SPF/DKIM/DMARC | Nachrichten werden versandt, landen aber im Spam | Authentifizierungseinträge könnten unvollständig oder veraltet sein |
Bisheriges Vorgehen und Alternative
Beim E-Mail-Umzug besteht das Geschäftsrisiko nicht nur in Ausfallzeiten, sondern auch in den Kosten des Parallelbetriebs. Nutzerbasierte Plattformen können Zeitdruck erzeugen, weil beide Anbieter gleichzeitig bezahlt werden. Ein pauschales Kostenmodell kann es erleichtern, das Ziel früh vorzubereiten und die Migration sorgfältig durchzuführen.
| Merkmal | Bisheriges Vorgehen | Alternative mit TrekMail |
|---|---|---|
| Kosten während des Parallelbetriebs | Doppelte nutzerbasierte Lizenzkosten | Pauschaltarife können eine frühe Vorbereitung erleichtern |
| Speichermodell | Grenzen pro Nutzer | Gemeinsamer Speicher innerhalb des Tarifs |
| Migrationsverfahren | Externes Tool und manuelle Nacharbeiten | Laut Quellstand integrierte IMAP-Migration in kostenpflichtigen Tarifen |
| Versandkonfiguration | An die Vorgaben der Suite gebunden | Verwaltetes SMTP oder BYO SMTP, je nach Tarif |
| Betrieb mehrerer Domains | Auf eine Domain ausgerichtet | Für die Verwaltung mehrerer Domains konzipiert |
TrekMail ändert die Funktionsweise von DNS nicht. Es kann jedoch Kostenplanung und Arbeitsablauf verändern. Je nach geltendem Tarif lassen sich Domains und Postfächer vorab anlegen, Importe im Hintergrund ausführen und Nutzer per Einladung aufnehmen. So kann sich der Zeitdruck durch nutzerbasierte Lizenzen beim Umzug verringern.
Für Agenturen und MSPs ist das besonders relevant. Wenn Sie viele Kundensysteme betreuen, lesen Sie anschließend den Beitrag zu E-Mail-Hosting für mehrere Domains. Die Migration ist nur ein Teil der Aufgabe. Auch das Betriebsmodell nach dem Wechsel beeinflusst Ihre Marge.
Wann TrekMail für diese Migration infrage kommt
TrekMail kann für Migrationen geeignet sein, bei denen standardbasierte IMAP-Postfächer, die Verwaltung mehrerer Domains, gemeinsamer Speicher, integrierte Migration und verwaltetes SMTP oder BYO SMTP gewünscht sind. Es ist keine umfassende Office-Suite; dieser begrenztere Funktionsumfang kann die Einrichtung überschaubar halten.
Im Quellstand anhand der Preisseiten dokumentierte TrekMail-Tarifangaben; prüfen Sie die aktuellen Konditionen:
- Free: $0, bis zu 10 Domains, 5 GB gemeinsamer Speicher, BYO SMTP.
- Starter: ab $3.50/Monat, 50 Domains, 15 GB gemeinsamer Speicher, verwaltetes SMTP, Migrationstool.
- Pro: $10/Monat, 100 Domains, 50 GB gemeinsamer Speicher, API-Zugriff.
- Agency: $23.25/Monat, 1000+ Domains, 200 GB+ Speicher, API und MCP.
- Enterprise: individuelle Preise.
Laut Quellstand bieten kostenpflichtige Tarife eine kostenlose Testphase von 14 Tagen und erfordern eine Kreditkarte. Der Nano-Tarif wird dort als ohne Kreditkarte und ohne Ablaufdatum beschrieben. Prüfen Sie vor der Buchung die aktuellen Bedingungen.
Wenn Sie die Kosten des Parallelbetriebs vor dem Umzug kalkulieren möchten, nutzen Sie die TrekMail-Preisseite.
Die wichtigste Regel für die Umschaltung
Merken Sie sich vor allem dies: Betreiben Sie beim E-Mail-Umzug beide Systeme parallel, bis Sie die Zustellung geprüft, den inkrementellen Abgleich wiederholt und den Benutzerzugriff auf den alten Anbieter gesperrt haben. So verringern Sie das Risiko übersehener Nachrichten.
Der Ablauf bleibt derselbe: Bestand erfassen, große Postfächer vorab übertragen, TTL rechtzeitig senken, MX in einem kontrollierten Zeitfenster ändern, abschließend synchronisieren und anhand von Nachrichtenanzahlen prüfen.
Mit diesem Vorgehen lässt sich der Umzug besser kontrollieren. Ohne diese Schritte kann die anschließende Suche nach vermeintlich verschwundenen Nachrichten viel Zeit kosten. Oft wurden sie nicht gelöscht, sondern liegen an einem Zustellziel, das bei der Prüfung übersehen wurde.