Wenn Sie für ein Unternehmen E-Mail-Konten umziehen, reicht das Vorgehen für einen einzelnen privaten Posteingang oft nicht aus. Post trifft weiter ein, Nutzer antworten, Aliasse leiten Nachrichten weiter und ein DNS-Fehler kann die Zustellung auf zwei Systeme verteilen. Planen Sie deshalb zuerst den Bestand, dann den Vorabimport und zuletzt die Umschaltung. Den größeren Zusammenhang erklärt dieser Leitfaden zu geschäftlicher E-Mail, bevor Sie DNS ändern.
Die Probleme sind bekannt: Jemand exportiert PST-Dateien, jemand zieht Ordner in Outlook hinüber, jemand hält jede Adresse für ein gewöhnliches Postfach. Am Montag empfängt sales@ nichts, ein großes Postfach synchronisiert noch und niemand weiß, welcher Server den maßgeblichen Datenstand enthält. Behandeln Sie die Migration als Umstellung laufender Infrastruktur, nicht als Dateikopie.
Dieser Leitfaden zeigt einen kontrollierten Ablauf, um E-Mail-Konten umzuziehen. Er behandelt manuelles IMAP, die Reihenfolge der Umschaltung, wichtige Fehlerquellen und TrekMails Verwaltungsablauf für Teams, Agenturen und MSPs. Eine Plattform kann Skriptpflege erleichtern, garantiert aber weder höhere Geschwindigkeit noch einen störungsfreien Umzug.
Was bedeutet der Umzug von E-Mail-Konten?
Sie kopieren Postfachdaten zwischen IMAP-Servern, richten Aliasse und Weiterleitungen separat neu ein und stellen gegebenenfalls den Empfang einer eigenen verwalteten Domain per DNS um. Für persönliche Anbieteradressen lässt sich deren Domain-MX nicht ändern; die Adresse wandert durch eine Kopie nicht automatisch mit.
Diese Unterscheidung ist wichtig, weil IMAP nur einen Teil der Arbeit abdeckt. Ordner und unterstützte Nachrichtenmarkierungen lassen sich kopieren. Nach RFC 3501 dient IMAP dem Zugriff auf Nachrichten und der Postfachverwaltung, nicht dem vollständigen Export einer geschäftlichen Identität.
Beim Kontoumzug erledigen Sie daher drei Aufgaben:
- Nachrichten und Ordnerstruktur kopieren und prüfen.
- Aliasse, Verteiler und Weiterleitungen mit den nötigen Berechtigungen wieder einrichten.
- Bei geändertem Empfang einer eigenen Domain DNS erst zum passenden Zeitpunkt umstellen.
Bleibt eine benötigte Aufgabe offen, ist der Umzug nicht vollständig geprüft. Das kann später Supportfälle auslösen.
Was IMAP überträgt und was nicht
IMAP kann Nachrichten, Ordner und häufig den Lesestatus übertragen, soweit Quellserver und Werkzeug dies unterstützen. Kalender, Kontakte, Aufgaben, Desktop-Signaturen und Client-Regeln werden nicht dadurch kopiert. Planen Sie diese getrennt, bevor Nutzer sie im Ziel erwarten.
Halten Sie den Umfang schriftlich fest. TrekMails dokumentierter Import basiert auf IMAP und ersetzt keine Groupware-Migration. Entsprechend geht es in den Anleitungen um Quellhost, Port, Benutzername, Passwort und Zielpostfach, nicht um Kalender oder gemeinsame Terminplanung.
Diese Übersicht hilft bei der Planung:
| Element | Über IMAP übertragbar? | Vorgehen |
|---|---|---|
| E-Mail-Nachrichten | Ja, bei geeignetem Zugang | Mit IMAP-Werkzeug kopieren und Integrität prüfen |
| Ordner | Ja, Zuordnung erforderlich | Nach dem Pilotlauf die Zuordnung prüfen |
| Gelesen- und Ungelesen-Markierungen | Häufig | In Pilotpostfächern testen |
| Kalender | Nein | Separat exportieren oder bisherigen Dienst behalten |
| Kontakte | Nein | Separat als CSV oder VCF exportieren |
| Aufgaben und Notizen | Nein | Außerhalb des Postfachimports behandeln |
| Serverseitige Weiterleitungen | Nein, keine IMAP-Kontokonfiguration | Berechtigt separat einrichten und testen |
| Aliasse und Gruppen | Nein | Vor der MX-Umschaltung vorbereiten |
Gerade der letzte Punkt wird leicht übersehen. Den Unterschied zwischen Alias und eigenem Postfach erklärt dieser Leitfaden zu Alias und Postfach. Eine klare Einordnung hilft, spätere Nacharbeiten zu vermeiden.
Vor dem Umzug den Bestand erfassen
Eine möglichst vollständige Bestandsaufnahme vor der ersten Synchronisation begrenzt Risiken. Ordnen Sie jedes Postfach, jeden Alias, jede Gruppe, Weiterleitung und Speicheranforderung einem Zielobjekt und einer Migrationswelle zu.
Ein Nutzerexport allein reicht nicht. Erfassen Sie auch wenig sichtbare Funktionen.
Prüfen Sie mindestens:
- Hauptpostfächer: aktive Nutzer, gemeinsame Postfächer und Funktionspostfächer.
- Aliasse: zusätzliche Adressen, die in ein anderes Postfach zustellen.
- Verteiler und Gruppen: Zustellobjekte, die keine gewöhnlichen IMAP-Postfächer sind.
- Weiterleitungen: serverseitige Wege wie info@ an owner@.
- Catch-all: bewusst entscheiden, ob diese Funktion bleibt, eingeschränkt oder abgeschaltet wird.
- Große Postfächer: früh starten und Grenzen prüfen.
Große Postfächer beeinflussen die Zeitplanung erheblich. Anbieter können IMAP drosseln, und umfangreiche Archive benötigen mitunter Tage statt Stunden. Versprechen Sie keinen Wochenendumzug für jahrelange Anhänge ohne gemessenen Probelauf.
Beispiel: Für Freitag ist die Umschaltung von 60 Nutzern geplant. Ein Leitungspostfach enthält 48 GB. Am Sonntag sind 59 Nutzer fertig, das große Postfach kopiert noch. Das ist eine illustrative Planungssituation, kein allgemeiner Zeitmaßstab; ihre Möglichkeit gehört in den Ablauf.
Wenn Sie zugleich die Kontoerstellung vereinheitlichen, kombinieren Sie den Umzug mit einer Bereitstellungs-Prüfliste wie diesem Ablauf zur Massenanlage von E-Mail-Konten. Unvollständige Bereitstellung kann ebenso Probleme verursachen wie DNS.
Mehrere Postfächer in Wellen übertragen
Planen Sie Wellen statt einer einzigen großen Umschaltung. Ein Pilot prüft Zugang und Ordnerzuordnung. Der Vorabimport kopiert ältere Post im Hintergrund. Weitere Abgleiche übernehmen Änderungen und werden mit der DNS-Umstellung koordiniert.
Eine praktikable Reihenfolge:
Welle 1: Pilot
Beginnen Sie mit einer kleinen Auswahl: IT-Mitarbeitende, Testkonten und ein gewöhnlicher Nutzer mit realistischem Postfach. Prüfen Sie TLS und Zertifikate auf Port 993 sowie die Zugangsdaten. Kontrollieren Sie Gesendet, Entwürfe, Archiv und eigene Ordner im Ziel.
Welle 2: Vorabimport
Starten Sie die umfangreiche Kopie vor dem geplanten Umschaltwochenende. Ältere Daten sollen bereits vorhanden sein, bevor MX tatsächlich wechselt, damit nicht erst dann jahrelange Post übertragen wird.
Welle 3: Differenzabgleich und Umschaltung
Gleichen Sie vor der Umstellung neue und veränderte Daten ab. Ändern Sie dann gegebenenfalls MX der eigenen Domain und prüfen Sie den neuen Empfang. Führen Sie danach wiederholte Nachläufe für verspätete Eingänge mit altem Datum, verschobene Nachrichten und Statusänderungen aus. Alter SMTP-Empfang, administrativer Abgleich und Rückfallmöglichkeit bleiben während Caches und Zustellwiederholungen nötig.
So lassen sich Drosselung, Wochenendarbeit und Nutzerfragen besser einplanen, statt auf einen ununterbrochenen Lauf zu vertrauen.
Manueller Kontoumzug mit imapsync
Für direkte Kontrolle kann ein IMAP-zu-IMAP-Werkzeug wie imapsync geeignet sein. Es unterstützt abhängig von Version und Einstellungen Wiederholungen, Ordnerzuordnungen und Statusmarkierungen. Das ersetzt nicht die Überprüfung des konkreten Ergebnisses.
Ziehen in Outlook, PST-Exporte und aus dem Gedächtnis eingegebene Befehle können schwer nachvollziehbare Ergebnisse erzeugen. Bei Client-Übertragungen sollten Sie Kopieren statt destruktivem Verschieben verwenden und lokale Daten sichern.
Wiederholbare Läufe mit Postfachprotokollen und geplanten Differenzabgleichen erleichtern die Kontrolle. TrekMails Ablauf kann entsprechende Schritte bündeln, ohne dass die Administration jede technische Komponente selbst pflegen muss. Weitere Praxis enthält der Betriebsleitfaden zu imapsync.
Das folgende Batch-Muster ist eine unverändert wiedergegebene Illustration, kein ausführbares, geprüftes Skript. Der Shebang ist ungültig. Korrigieren Sie eine eigene Arbeitskopie und prüfen Sie Passwort-, Log-, Schnell- und Größenoptionen anhand Ihrer installierten Version sowie den Ziel-IMAP-Host anhand der aktuellen Client-Dokumentation. --log aktiviert die Protokollierung und nimmt keinen Dateinamen entgegen; dafür ist die passende Dateinamensoption zu prüfen. Auch die eigenständige Schnelloption darf nicht ungeprüft übernommen werden. Der einfache Komma-Parser verarbeitet keine korrekt zitierten CSV-Felder mit Kommas, Anführungszeichen oder Zeilenumbrüchen. Echte Zugangsdaten brauchen geschützte Dateien und dürfen nicht unkontrolliert in Prozesslisten oder Protokolle gelangen:
#!$0
# users.csv format:
# source_user,source_pass,dest_user,dest_pass
while IFS=, read -r src_user src_pass dest_user dest_pass
do
echo "[START] $src_user -> $dest_user"
imapsync \
--host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
--host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
--automap \
--usecache \
--fast \
--skipsize \
--subfolder2 "Imported_Mail" \
--log "logs/${src_user}.log"
echo "[DONE] Review logs/${src_user}.log"
done < users.csvPraktische Hinweise:
Cache bewusst verwenden. Ein unterstützter Cache-Modus kann wiederholte Metadatenabfragen reduzieren. Er ist optional, muss zum Verfahren passen und macht UIDs nicht zu globalen Kennungen.
Bei Bedarf einen Zwischenordner nutzen. Getrennt abgelegte Importdaten können den Vergleich erleichtern, lösen aber keine Konflikte bei gleichzeitiger Nutzung beider Systeme. imapsync ist keine sichere bidirektionale Synchronisation aktiver Konten: Legen Sie einen aktiven Arbeitsserver fest und begrenzen Sie alte Nutzeränderungen. Der Zwischenordner verändert Zielpfade und ersetzt weder endgültige Systemordnerzuordnung noch die Prüfung von Inhalten, Verschiebungen, Löschungen und Flags.
Pro Postfach protokollieren. Entscheidend ist, welches Postfach an welcher Stelle scheitert. Die bedingungslos ausgegebene DONE-Zeile beweist keinen Erfolg: Prüfen Sie Exitstatus, bereinigte Logs sowie Anzahl, Inhalte, Anhänge, Datumswerte, Ordner und Flags. Beschränken Sie Dateizugriff und entfernen Sie Geheimnisse aus Diagnoseausgaben.
DNS-Umschaltung als eigener Prüfschritt
Bei geändertem Empfang einer eigenen Domain senken Sie MX-TTL frühzeitig, warten das Ablaufen alter Cachewerte ab und stellen dann auf das bereitstehende Ziel um. Entfernen Sie nicht mehr gewünschte alte MX planmäßig. Prüfen Sie den tatsächlichen Empfang und übernehmen Sie weiterhin Post, die wegen Caches oder Wiederholungen beim alten Server ankommt.
Der Kopierabschluss allein ändert keine Zustellung. Für eine eigene Domain steuert DNS den Empfang; bei persönlichen Anbieteradressen gelten deren Konten und gegebenenfalls erlaubte Weiterleitungen.
Eine unkoordinierte Umstellung kann Nachrichten auf beide Systeme verteilen. Beide sehen dann teilweise aktiv aus, während der Datenbestand auseinanderläuft. Deshalb gehören Nachläufe und eine klare Nutzerumschaltung zum Plan.
Prüfen Sie die erforderlichen Einträge anhand aktueller TrekMail-Dokumentation und Ihres Dashboards. Das folgende Beispiel darf nicht blind übernommen werden: Behalten Sie SPF-Autorisierung aller legitimen Versanddienste, veröffentlichen und testen Sie passende DKIM-Schlüssel samt tatsächlicher Signierung. DMARC benötigt erfolgreiche ausgerichtete SPF-Prüfung oder eine gültige ausgerichtete DKIM-Signatur; verschärfen Sie die Richtlinie nicht ungeprüft während des Umzugs:
@ MX 10 mail.trekmail.net.
@ TXT "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey TXT "<unique TrekMail DKIM value>"
_dmarc TXT "v=DMARC1; p=quarantine;"Kontrollieren Sie bei der Umschaltung:
- Nicht mehr benötigte alte MX planmäßig entfernt.
- Passende neue MX veröffentlicht.
- Eine SPF-Policy pro Name mit allen tatsächlich benötigten Versanddiensten; andere TXT dürfen bestehen bleiben.
- DKIM veröffentlicht und tatsächliche gültige Signatur geprüft.
- DMARC veröffentlicht und mindestens ein erfolgreicher, mit From ausgerichteter Prüfweg bestätigt.
- Testnachricht am neuen Ziel empfangen; mögliche alte Nachzügler weiter erfasst.
Beobachten Sie nach der Umschaltung Zustellung und Fehlermeldungen. Bei relevantem Gmail-Verkehr können Google Postmaster Tools zusätzliche, nicht vollständige Informationen liefern. Ein letzter Kopiervorgang allein reicht nicht: Empfang, Versand und der laufende Betrieb müssen ebenfalls geprüft werden.
Kontoumzug im TrekMail-Verwaltungsbereich
TrekMails dokumentiertes Werkzeug kopiert Post serverseitig aus geeignetem IMAP-Zugang. Das kann eigene virtuelle Server und Skriptpflege ersparen. Quellzugang, Fehlerkontrolle, passende Ordner und erforderliche Nachläufe bleiben dennoch Aufgaben der Administration.
Die möglichen Unterschiede im Überblick:
| Möglicher manueller Ansatz | TrekMail-Ansatz, aktuelle Unterstützung prüfen |
|---|---|
| Linux-System und Werkzeuge selbst bereitstellen | Import im Dashboard starten |
| Eigene Batch-Skripte sichern und pflegen | Unterstützten eingebauten Ablauf verwenden |
| Zugang und Ordner pro Postfach selbst untersuchen | Anbietervorlagen oder allgemeines IMAP nutzen und prüfen |
| Große Postfächer können andere Nutzerpläne erfordern | Gemeinsamen Speicher innerhalb geltender Kontogrenzen nutzen |
| Nutzerbasierte Kosten können mit dem Kunden wachsen | Tarifbasiertes Multi-Domain-Angebot prüfen |
Prüfen Sie den aktuellen Ablauf:
- Domain hinzufügen und DNS vorbereiten; MX erst nach geprüftem Vorabimport umstellen.
- Zielpostfach erstellen und Zugang testen.
- Migration im Dashboard öffnen.
- Quell-IMAP-Host, Port, Benutzername und geeignetes Passwort angeben.
- TrekMail-Postfach als Ziel wählen.
- Import starten, Status und tatsächliches Ergebnis prüfen.
Die aktuellen Anleitungen sind IMAP-Migrationsübersicht, Migration im Dashboard starten, Postfach erstellen und erforderliche DNS-Einträge. Der dokumentierte Direktimport nutzt IMAP-Benutzername und Passwort, nicht interaktives OAuth. Gmail-App-Passwörter hängen von Kontorichtlinien und Bestätigung in zwei Schritten ab; bei obligatorischem OAuth brauchen Sie einen anderen unterstützten Weg.
Die Quelle nennt Starter ab $3.50 pro Monat, Nano zu $0 und die Bezahltarife Starter, Pro, Agency und Enterprise. Kostenloses Nano ohne Karte und eine 14-tägige Testphase für Bezahltarife mit Kreditkarte sind historische Angaben, deren heutige Bedingungen Sie prüfen sollten. Gemeinsamer Speicher kann große Postfächer besser verteilen, bleibt aber durch den Tarif und einzelne Funktionsgrenzen begrenzt.
Zum Vergleich verwenden Sie die aktuellen TrekMail-Tarife.
Prüfliste für die Umschaltung im laufenden Betrieb
Eine letzte Kontrolle vor dem geplanten MX-Wechsel kann fehlende Aliasse, veraltete DNS-Werte, falsche Zugangsdaten und unvollständige große Imports aufdecken. Sie vermindert Risiken, garantiert jedoch keinen verlustfreien Ablauf.
Prüfen Sie vor der Änderung:
- Alle Zielpostfächer vorhanden und Anmeldung getestet.
- Aliasse, Weiterleitungen und Gruppen berechtigt eingerichtet und geprüft.
- Quell-IMAP-Zugang über TLS-Port 993 samt Zertifikatsprüfung funktionsfähig.
- Größte Postfächer frühzeitig vorab kopiert und kontrolliert.
- TTL rechtzeitig gesenkt und alte Cachelaufzeiten berücksichtigt.
- Alte MX dokumentiert, einschließlich des Rückfallplans.
- Differenzabgleiche vor und nach der Umschaltung geplant.
- Nutzer über das Ende von Änderungen im alten System informiert; lokalen nicht synchronisierten Bestand vor Profiländerungen gesichert.
- Ein Testpostfach für Empfang und Versand bereit.
- Verantwortliche für die Nachbeobachtung benannt.
Diese Routine ist unspektakulär, aber wichtig. Ein kontrollierter Kontoumzug versucht, Überraschungen vorab aufzudecken, statt erst bei Nutzerproblemen zu reagieren.
Fazit: Kontoumzug mit einem überprüfbaren Verfahren
Ob Sie für eine Domain oder fünfzig E-Mail-Konten umziehen, erfassen Sie Kontofunktionen, kopieren Sie Daten vorab, stellen Sie nötiges DNS kontrolliert um und prüfen Sie den Empfang danach. IMAP übernimmt die Kopie, ersetzt aber weder eine tragfähige Planung noch die Prüfung von Vollständigkeit und Funktion.
Der manuelle Weg bleibt eine Option, wenn Sie direkte Kontrolle und eigene Werkzeugverwaltung benötigen. Bei häufigen Umzügen können TrekMails tarifbasiertes Multi-Domain-Hosting, gemeinsamer Speicher, IMAP-Import und Verwaltungsbereich helfen. Ob diese Lösung wirtschaftlicher oder geeigneter ist, hängt von aktuellen Grenzen und Anforderungen ab. Prüfen Sie Nano oder die Tarife, wenn Sie Importfunktionen eines Bezahltarifs benötigen.