Drei Postfächer, null Zusatzlizenzen: Plesk-Mail nach Microsoft 365 umziehen

Du kennst das: Die Hauptadresse liegt längst in Microsoft 365, aber auf dem Webserver dümpeln noch ein paar Postfächer aus alten Zeiten vor sich hin. Eins für den Blog, eins namens info@, eins, von dem keiner mehr weiß, warum es existiert. Sie werden per IMAP abgeholt, irgendwohin weitergeleitet und bei jedem Server-Update heimlich mitgepflegt. Höchste Zeit, jedes Plesk Postfach nach Microsoft 365 zu holen.

In meinem Fall waren es drei Postfächer auf zwei Domains, alle auf einem Plesk-Server. Für jede Adresse eine Lizenz bezahlen wollte ich aber nicht. Die Lösung heißt freigegebenes Postfach: Es kostet nichts, solange es unter 50 GB bleibt und du mit einem lizenzierten Konto darauf zugreifst.

Der Umzug selbst ist kein Hexenwerk. Die Reihenfolge ist es, die zählt. Und ein paar Dinge, die in keiner Anleitung stehen, haben mich einen Nachmittag gekostet. Die bekommst du hier mit.

Ziel

• Jedes Plesk-Postfach wird ein freigegebenes Postfach in Microsoft 365, mit den alten Mails.
• MX und SPF der Domain zeigen auf Microsoft 365.
• Auf dem Plesk-Server ist der Maildienst für die Domain aus. Der Server hostet nur noch Webseiten.
• Keine zusätzliche Lizenz.

Voraussetzungen

• Ein Microsoft-365-Mandant mit mindestens einem lizenzierten Konto, das Exchange Online enthält. Bei mir: Business Basic, eine Lizenz.
• Admin-Zugriff auf das Microsoft 365 Admin Center und das Exchange Admin Center. Das sind zwei getrennte Anmeldungen.
• Root-Zugriff per SSH auf den Plesk-Server.
• Zugriff auf die DNS-Verwaltung der Domain. Bei mir liegt die beim Hoster, nicht in Plesk.
• Eine ruhige Stunde. Microsoft braucht zwischendurch Zeit, in der du nichts beschleunigen kannst.

Was du wissen musst, bevor du anfängst: Ein freigegebenes Postfach hat kein eigenes Passwort. Du öffnest es über dein lizenziertes Konto. Ein Abruf per IMAP mit eigenen Zugangsdaten geht danach nicht mehr.

Plesk Postfach nach Microsoft 365: die Reihenfolge

1. Bestandsaufnahme auf dem Server
2. Domain in Microsoft 365 hinzufügen
3. Freigegebene Postfächer anlegen
4. Alte Mails sichern und kopieren
5. MX und SPF umstellen
6. Maildienst in Plesk abschalten

Die Reihenfolge ist nicht verhandelbar. Wer den MX vor Schritt 3 umstellt, schickt Mails ins Leere. Wer Schritt 6 vor Schritt 4 macht, hat keine alten Mails mehr.

Schritt 1: Bestandsaufnahme auf dem Server

Erst zählen, dann anfassen. Welche Postfächer gibt es, und wie groß sind sie?

plesk bin mail -l
du -sm /var/qmail/mailnames/*/*

Dann die Frage, die ich zu spät richtig beantwortet habe: Wer meldet sich an diesen Postfächern an?

grep -E "(imap|pop3)-login: Logged in" /var/log/maillog \
  | grep -o "user=<[^>]*>" | sort | uniq -c

Hinweis: Achte auf den Wortlaut. Mein Dovecot schreibt Logged in, ältere Versionen schreiben Login:. Ich habe zuerst nach dem falschen Muster gesucht, null Treffer bekommen und daraus geschlossen, dass niemand die Postfächer abruft. Tatsächlich hingen mein Telefon und mein Notebook mit über 300 Anmeldungen pro Woche daran. Dazu gleich mehr.

Schritt 2: Domain in Microsoft 365 hinzufügen

Im Microsoft 365 Admin Center unter Einstellungen → Domänen → Domäne hinzufügen trägst du die Domain ein und wählst die Überprüfung per TXT-Eintrag. Microsoft zeigt dir einen Wert wie MS=ms12345678.

Den trägst du beim DNS-Anbieter als TXT-Eintrag für die Domain selbst ein, ohne Präfix. Danach prüfen, bevor du im Assistenten auf Überprüfen klickst:

dig +short TXT example.org

Den Assistenten kannst du nach der Bestätigung schließen. Die Domain steht dann auf „Setup unvollständig“. Das ist in Ordnung, MX und SPF kommen später.

Ab diesem Moment gilt die Domain im Mandanten als bekannt. Mails von deinen eigenen Microsoft-365-Konten an Adressen dieser Domain bleiben jetzt in Microsoft 365 und kommen als unzustellbar zurück, solange es dort kein Postfach gibt. Mach also zügig mit Schritt 3 weiter.

Schritt 3: Freigegebene Postfächer anlegen

Im Admin Center unter Teams und Gruppen → Freigegebene Postfächer → Freigegebenes Postfach hinzufügen: Name vergeben, Adresse eintragen, die neue Domain auswählen. Danach dich selbst als Mitglied hinzufügen. Als Mitglied darfst du lesen und unter der Adresse senden.

Bei meiner ersten Domain war das in drei Minuten erledigt. Bei der zweiten kam fünfzig Minuten lang nur: „Wir können im Moment leider keine freigegebenen Postfächer erstellen.“ Dahinter steckte, dass die neue Domain im Exchange-Teil von Microsoft noch nicht überall angekommen war. Beschleunigen lässt sich das nicht. Du kannst aber von außen zusehen, wie weit es ist. Wie, steht in Schritt 5.

Nach dem Anlegen einmal nachsehen, ob die Mitgliedschaft wirklich drin ist. Bei mir stand erst nur „Senden als“, der Lesezugriff kam ein paar Minuten später nach.

Schritt 4: Alte Mails sichern und nach Microsoft 365 kopieren

Zuerst ein Archiv auf dem Server. Das ist keine Fleißaufgabe, sondern deine Lebensversicherung für Schritt 6.

tar -czf /root/backups/mail-info@example.org-$(date +%Y%m%d-%H%M).tar.gz \
  -C /var/qmail/mailnames/example.org info

Für die Kopie nimmst du die IMAP-Migration im Exchange Admin Center unter Migration → Migrationsbatch hinzufügen. Die will pro Postfach ein Passwort. Ich habe dafür Einmal-Passwörter gesetzt, die niemand zu Gesicht bekommt:

umask 077
f=/root/imap-migration.csv
echo "EmailAddress,UserName,Password" > "$f"
for u in info blog; do
  p="$(openssl rand -base64 36 | tr -dc 'A-Za-z0-9' | head -c 24)-aZ9"
  PSA_PASSWORD="$p" plesk bin mail --update "$u@example.org" -passwd ""
  echo "$u@example.org,$u@example.org,$p" >> "$f"
done

Die Datei holst du dir auf den Rechner, lädst sie im Assistenten hoch und löschst sie danach an beiden Stellen. Im Assistenten:

• Migrationstyp: IMAP-Migration
• Neuer Endpunkt: dein Server, Verschlüsselung SSL, Port 993
• Unter Konfiguration die Ordner ausschließen, die du nicht mitnehmen willst. Bei Dovecot mit INBOX.-Präfix hat bei mir INBOX/Trash und INBOX/Spam funktioniert.

Beim Servernamen bin ich gestolpert. Mein Zertifikat gilt für example.org, nicht für mail.example.org. openssl s_client meldet in beiden Fällen brav „Verify return code: 0“, weil es nur die Kette prüft und nicht den Namen. curl ist da ehrlicher:

curl -sS --url "imaps://mail.example.org/"
# curl: (60) SSL: no alternative certificate subject name matches target host name

Nimm den Namen, bei dem curl nicht meckert.

Knapp 700 MB waren bei mir nach drei Minuten kopiert. Danach im Batch auf die Details schauen: Microsoft listet dort übersprungene Elemente auf. Bei mir waren es drei. Eine Mail mit 50 MB Anhang, denn die IMAP-Migration nimmt höchstens 35 MB pro Nachricht. Und zwei mit dem Hinweis „MissingItemInTarget“, ohne nähere Begründung. Die habe ich einzeln aus dem Maildir gefischt und als .eml gesichert.

Schritt 5: MX und SPF umstellen

Den MX-Wert liest du im Domänen-Assistenten ab, unter Einrichtung fortsetzen → DNS-Einträge. Rate ihn nicht. Ich hätte auf example-org.mail.protection.outlook.com getippt. Tatsächlich hingen bei beiden Domains zwei zusätzliche Zeichen am Namen, und die geratene Variante löste gar nicht auf.

Bevor du den MX umstellst, frag den Microsoft-Mailserver, ob er die Adresse schon annimmt. Das geht ohne Testmail:

mx=example-org.mail.protection.outlook.com   # deinen Wert einsetzen
exec 3<>/dev/tcp/$mx/25
read -t 8 -r l <&3
printf 'EHLO example.org\r\n' >&3
while read -t 3 -r l <&3; do [[ $l == 250\ * ]] && break; done
printf 'MAIL FROM:<>\r\n' >&3; read -t 8 -r l <&3
printf 'RCPT TO:<info@example.org>\r\n' >&3; read -t 8 -r l <&3
echo "$l"
printf 'QUIT\r\n' >&3; exec 3>&-

250 2.1.5 Recipient OK ist gut. 551 5.5.1 Unable to relay non-accepted domain heißt: Dieser Server kennt die Domain noch nicht. Führ das ein Dutzend Mal aus. Hinter dem Namen stecken viele Server, und bei mir kannte anfangs nur einer von vieren die Domain. Stellst du den MX in diesem Zustand um, gehen Mails von außen mit einem harten Fehler an den Absender zurück.

Erst wenn alle Proben durchgehen, die DNS-Einträge setzen:

• MX: der Wert aus dem Assistenten
• TXT (SPF): v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all

Die beiden IP-Adressen sind die deines Webservers. Ohne sie landen die Benachrichtigungen deiner Webanwendungen im Spam, denn die verschickt weiterhin der Server selbst.

Schritt 6: Maildienst in Plesk abschalten

Solange der Maildienst für die Domain in Plesk läuft, hält sich der Server für zuständig. Alles, was er selbst an diese Adressen schickt, stellt er weiter lokal zu, egal wohin der MX zeigt. Deshalb zum Schluss:

plesk bin site --update example.org -mail_service false

Achtung: Plesk löscht dabei die Postfächer der Domain samt Inhalt vom Server. Ich hatte vorher angenommen, sie blieben einfach liegen. Dank des Archivs aus Schritt 4 war das nur eine Überraschung und kein Verlust.

So prüfst du es

Wohin würde der Server eine Mail jetzt zustellen? Das fragst du Postfix, ohne wirklich etwas zu senden:

sendmail -bv info@example.org
grep "to=<info@example.org>" /var/log/maillog | tail -1

Im Log sollte relay=…mail.protection.outlook.com und status=deliverable stehen. Steht dort noch relay=plesk_virtual, ist der Maildienst nicht aus.

Dazu von außen:

dig +short MX example.org
dig +short TXT example.org

Und der eigentliche Test: eine Mail von einem fremden Konto schicken und nachsehen, ob sie in Outlook im freigegebenen Postfach auftaucht. Das dauert beim ersten Mal bis zu einer Stunde, weil Outlook das Postfach erst einbinden muss.

Rückweg

Bis einschließlich Schritt 5 kommst du jederzeit zurück: MX wieder auf den alten Wert, SPF-Eintrag entfernen, fertig. Die Postfächer auf dem Server sind bis dahin unangetastet.

Nach Schritt 6 gibt es die Postfächer auf dem Server nicht mehr. Der Rückweg heißt dann: Maildienst wieder einschalten, Postfächer neu anlegen, Archiv zurückspielen, MX zurückdrehen. Machbar, aber kein Zwei-Minuten-Job. Lass das Archiv deshalb liegen, bis du sicher bist. Wie man Backups so baut, dass sie den Ernstfall überleben, habe ich beim verschlüsselten Passbolt-Backup auf die NAS aufgeschrieben.

Stolperstellen aus der Praxis

• Das falsche Suchmuster im Log. Null Treffer heißt nicht „niemand meldet sich an“, sondern vielleicht nur „du suchst falsch“. Mach die Gegenprobe mit einem Postfach, von dem du weißt, dass es benutzt wird. Ich habe die Passwörter in dem Glauben geändert, es hinge kein Gerät daran. Kurz darauf standen die ersten fehlgeschlagenen Anmeldungen meiner eigenen Geräte im Log.
• Apple Mail kann keine freigegebenen Postfächer. Auf dem iPhone brauchst du die Outlook-App oder eine Weiterleitung aus dem freigegebenen Postfach an deine Hauptadresse. Klär das, bevor du die alten Konten löschst.
• Microsoft braucht Zeit, und zwar unterschiedlich viel. Erste Domain: sieben Minuten, bis alle Mailserver sie kannten. Zweite Domain am selben Tag: Nach einer Stunde kannte sie erst einer von vier Servern, erst am Abend waren es alle. Plane den MX-Wechsel nicht auf fünf Minuten vor dem Feierabend.
• Der DNS-Anbieter denkt mit. Bei meinem Hoster ist im TXT-Formular eine „Standard-DMARC-Regel“ vorausgewählt, obwohl im DNS bisher gar kein DMARC-Eintrag existierte. Wer einfach speichert, schaltet nebenbei eine strenge Regel scharf und wundert sich über abgewiesene Mails. Vor dem Speichern prüfen, was das Formular sonst noch mitschickt.
• Geschenkte Aliase. Jedes neue freigegebene Postfach bekam bei mir ungefragt eine zweite Adresse unter der Standard-Domain des Mandanten. Aus info@example.org wurde zusätzlich info@ auf meiner Hauptdomain. Stört selten, sollte man aber wissen.
• IPv6 ohne Rückwärtseintrag. Microsoft weist Mails von einer IPv6-Adresse ohne PTR-Eintrag zeitweise ab. Die Mail bleibt dann in der Warteschlange und geht erst bei einem späteren Versuch raus. Entweder den PTR setzen oder Postfix mit smtp_address_preference = ipv4 auf IPv4 festlegen.
• Zwei Admin-Center, zwei Anmeldungen. Dass du im Microsoft 365 Admin Center angemeldet bist, heißt nicht, dass das Exchange Admin Center dich reinlässt. Halte dein Kennwort bereit, bevor du mitten in der Migration davorstehst.

Fazit

Ein Plesk Postfach nach Microsoft 365 umzuziehen ist an sich eine Sache von einer Stunde: Domain hinzufügen, freigegebenes Postfach anlegen, Mails kopieren, MX umstellen, Maildienst abschalten. Was daraus einen Nachmittag macht, sind die Wartezeiten bei Microsoft und die eigenen Annahmen. Meine zwei teuersten waren „da meldet sich eh keiner an“ und „die Postfächer bleiben beim Abschalten schon liegen“. Beide falsch, beide dank Archiv folgenlos. Der Server hostet jetzt nur noch Webseiten, die Postfächer wohnen an einem Ort, und gekostet hat es genau null Lizenzen. Nur etwas Demut vor dem eigenen grep.