Praxisbericht: Umstellung einer Kundendomain an einem Vormittag

Ausgangslage

Die Postfächer lagen auf zwei Systemen: einem eigenen Exchange-Server im Büro (erreichbar per VPN) und drei Postfächern beim Webhoster, der auch Domain und DNS verwaltet. Der MX zeigte auf den Spamfilter des Hosters.

Datenübernahme am Vortag und in der Nacht

• Am Exchange vorübergehend IMAP4 eingeschaltet und ein eigenes Umzugskonto mit Vollzugriff angelegt.
• Kopie aller Ordner mit imapsync: 8 Postfächer, etwa 95 GB, 0 Fehler, etwa 8 Stunden. Begrenzt hat der Upload des Büroanschlusses.
• Kalender, Kontakte, Aufgaben und Notizen bewusst ausgelassen, die gehen nicht über IMAP.
• Hoster-Postfächer: Abgleich über alle Ordner mit Dublettenerkennung per Message-ID (ohne ID über Datum, Absender und Betreff). Neue Mails der letzten 7 Tage landen im selben Ordner, ältere fehlende in „Archiv <Anbieter>“; das waren meist bewusst gelöschte Newsletter.
• Alles ist mehrfach ausführbar. Ein Nachlauf kurz vor und nach der Umstellung holt den Rest.

Domain-Anbieter, Schritt 1: vorbereiten

Diese Änderungen bemerkt der Kunde noch nicht:

• Neu: mx A 203.0.113.10
• Neu: woa._domainkey TXT (DKIM)
• Neu: _dmarc TXT mit p=none
• MX-TTL von 3600 auf 600 Sekunden gesenkt, das Minimum im Panel. Die TTL gilt automatisch für alle Einträge mit gleichem Namen und Typ.

Danach das Let’s-Encrypt-Zertifikat für mx.example.de ausgestellt und alle Mailports (25, 465, 587, 993) von außen geprüft.

Tipp: Port 25 lässt sich nicht von jedem Server aus testen: Viele Rechenzentren sperren ausgehenden Port 25.

Server-Anbieter: Reverse-DNS setzen

Menü Panel des Server-Anbieters öffentliche IP Reverse DNS

Reverse-DNS der Server-IP auf mx.example.de gesetzt. Der Anbieter prüft dabei, ob der A-Eintrag mx auf diese IP zeigt. Deshalb erst Schritt 1 beim Domain-Anbieter, dann der PTR.

• Vorher stand dort ein generischer Name („ubuntu“). Damit lehnen große Empfänger ab.
• Der Hinweis „Dem Server muss mindestens eine IPv4-Adresse zugewiesen werden“ im selben Dialog betrifft nur die IP-Zuweisung und kann ignoriert werden.
• Der ausgehende Port 25 musste beim Server-Anbieter freigeschaltet sein.

Server vor der MX-Umstellung auf Direktbetrieb

Achtung: Steht der Server noch im Abholbetrieb, betrachtet er die Domain nicht als eigene und weist eingehende Mails endgültig ab („Relay access denied“). Also erst Direktbetrieb einschalten, prüfen, dass Mails angenommen werden, dann den MX umstellen.

Domain-Anbieter, Schritt 2: die Umstellung

Die CNAME-Einträge für autoconfig und autodiscover nur zu löschen, reichte nicht: Sie fielen auf den Wildcard-Eintrag * zurück, und der zeigte wieder zum Hoster. Deshalb neu als A-Eintrag angelegt.

Unverändert blieben Hauptdomain und www (Platzhalterseite beim Hoster), remote (Büro) und der Bestätigungs-TXT. Nach etwa einer Woche kommen include:<hoster> aus dem SPF und der alte DKIM-Eintrag des Hosters weg.

Nach wenigen Minuten war die Änderung bei den autoritativen Nameservern und öffentlichen Resolvern sichtbar. Die erste fremde Mail kam etwa 10 Minuten nach der Umstellung direkt an.

Zertifikat und Autodiscover nachziehen

• mail.example.de zeigt jetzt auch auf den Server, also das Zertifikat um mail und autodiscover erweitern. Sonst gibt es Zertifikatswarnungen.
• Für Outlook gibt es einen eigenen HTTPS-Endpunkt autodiscover.example.de/autodiscover/autodiscover.xml, der IMAP 993 und SMTP 465 meldet. Outlook fragt per POST, Groß- und Kleinschreibung im Pfad sind egal.
• Thunderbird und Handys nutzen autoconfig.example.de/mail/config-v1.1.xml.

Stolperstein: Der Hoster stellt intern weiter zu

Eine Testmail von einem Konto beim selben Hoster kam nicht über den neuen MX, sondern landete im alten Postfach beim Hoster. Solange die Domain dort als Maildomain aktiv ist, stellt er intern zu, ohne auf den MX zu schauen.

Lösung: im Panel des Hosters beim Webhosting-Paket unter E-Mail die Domain wählen und den Schalter „Maildienste“ auf inaktiv stellen. Die nächste Testmail kam sofort über den MX.

Achtung: Damit sperrt der Hoster auch den IMAP-Zugang. Den letzten Abgleich also vorher laufen lassen.

Dabei fielen weitere, fast leere Postfächer beim Hoster auf und eine Adresse administrator@ mit Weiterleitung auf ein anderes Postfach. Auf dem neuen Server musste dafür eine Weiterleitung angelegt werden.

Tipp: Vor der Umstellung immer alle Postfächer, Weiterleitungen und Aliase beim alten Anbieter auflisten.

Stolperstein: Greylisting

Die erste Antwort aus dem Webmail an eine Adresse beim Hoster hing etwa 16 Minuten in der Warteschlange („451 … not yet authorized … try later“) und wurde dann zugestellt. Danach gingen Mails sofort durch. Die DKIM-Signatur für die Domain war korrekt.

Stolperstein: Outlook schlägt den Server des Rechenzentrums vor

Outlook fragte nach dem Kennwort für den IMAP-Server des Rechenzentrums statt für mx.example.de. Das kommt von Microsoft AutoDetect, nicht vom eigenen Autodiscover. Die Lösung steht unter Outlook schlägt einen falschen Server vor.

Exchange außer Betrieb nehmen

1. Erst Kalender und Kontakte exportieren.
2. Alle Exchange-Dienste per PowerShell beenden und auf „Deaktiviert“ setzen. Die vorherigen Starttypen vorher in eine CSV-Datei sichern; ein zweites Skript stellt sie bei Bedarf wieder her.
3. Umzugskonto entfernen und IMAP4 am Exchange wieder ausschalten.

Zeitbedarf

Am Umstellungstag etwa 2,5 Stunden einschließlich aller Prüfungen, die reine DNS-Umstellung dauerte wenige Minuten. Weil alles vor Arbeitsbeginn lief, haben die Mitarbeitenden nichts bemerkt.