Domain und E-Mail umziehen, ohne dass Post verlorengeht

Wer „Domainumzug" sagt, meint fast nie nur die Domain. Er meint ein Bündel: den Namen selbst, die Website dahinter, die Postfächer, oft noch ein Formular, einen Kalender, eine Schnittstelle zur Warenwirtschaft. Der Name ist dabei der kleinste Teil. Er ist ein Eintrag in einem Verzeichnis, und dieses Verzeichnis umzuschreiben dauert Minuten. Alles andere hängt nur deshalb am Namen, weil es über ihn gefunden wird — und genau das macht den Unterschied zwischen einem ruhigen und einem teuren Umzug.

Es hilft, sich zwei getrennte Spuren vorzustellen. Auf der oberen Spur liegt die Website. Sie hängt an den Einträgen A und AAAA, die eine Serveradresse nennen, und meistens an einem CNAME für die Adresse mit „www". Auf der unteren Spur liegt das Postfach. Es hängt am MX-Eintrag, der sagt, welcher Server Nachrichten für diese Domain annimmt, und an mehreren TXT-Einträgen, die beschreiben, wer in Ihrem Namen senden darf. Beide Spuren teilen sich denselben Namen, sonst nichts. Sie können getrennt geplant, getrennt getestet und getrennt umgelegt werden.

Diese Trennung ist der wichtigste Handgriff des ganzen Vorgangs. Wer beides am selben Nachmittag umlegt und abends ein Problem hat, hat zwei Verdächtige und keinen Beweis. Wer die Website am Montag und das Postfach am Donnerstag umlegt, weiß bei jedem Symptom sofort, wo es herkommt. Der Aufwand ist derselbe, die Fehlersuche ist eine andere Welt. Wenn Sie ohnehin gerade den Anbieter wechseln, lohnt der Blick auf die Auswahlkriterien für Webhosting — vieles, was den Umzug später schwer macht, wird bei der Auswahl entschieden.

Jede Antwort des Namenssystems trägt eine Haltbarkeitsangabe, die Time to Live. Sie sagt jedem fragenden Server, wie lange er sich die Antwort merken darf, bevor er neu fragt. Diese eine Zahl bestimmt, wie lange nach einer Änderung noch die alte Antwort im Umlauf ist — und damit den gesamten Zeitplan. Die klassische Empfehlung nennt 1 bis 5 Tage (RFC 1912) als übliche Werte und für Einträge, die oft abgefragt und selten geändert werden, sogar 1 bis 2 Wochen (RFC 1912). Wer diese Zahlen nicht kennt, plant einen Umzug auf einen Nachmittag und wundert sich zwei Tage lang.

Der Handgriff dagegen ist trivial und wird trotzdem regelmäßig vergessen: Die TTL wird gesenkt, bevor irgendetwas anderes passiert — und zwar mindestens eine alte TTL-Länge vorher, damit die alte, lange Haltbarkeit selbst schon abgelaufen ist. Steht auf dem MX-Eintrag 86400, dann senken Sie ihn heute auf 300 und legen den Umzug in acht Tagen. Sonst senken Sie zwar den Wert, aber die Welt merkt es erst einen Tag später — und der Tag, an dem sie es merkt, ist der Umschalttag.

Zwei weitere Zahlen gehören in denselben Zusammenhang, weil sie erklären, warum ein Fehler manchmal länger sichtbar bleibt als die TTL vermuten lässt. Erstens wird auch die Abwesenheit eines Eintrags gespeichert: Für dieses negative Zwischenspeichern haben sich Werte von einer bis drei Stunden (RFC 2308) als brauchbarer Vorgabewert erwiesen. Wer also einen Eintrag abfragt, bevor er existiert, bekommt die Fehlmeldung stundenlang zurück, obwohl der Eintrag längst gesetzt ist. Zweitens dürfen Auflöser eine abgelaufene Antwort weiterverwenden, wenn die zuständigen Server gerade nicht erreichbar sind; als Zeitraum dafür werden ein bis drei Tage (RFC 8767) vorgeschlagen, und die Obergrenze für gespeicherte Haltbarkeiten soll bei 604.800 Sekunden (RFC 8767) liegen, also sieben Tagen.

E-Mail ist der Grund, warum Domainumzüge einen schlechten Ruf haben. Eine Website, die eine Stunde den alten Stand zeigt, ärgert niemanden ernsthaft. Eine Bestellung, die in einem Postfach liegt, das seit gestern niemand mehr öffnet, kostet Geld — und zwar leise. Das Volumen macht es nicht besser: Berufstätige Internetnutzer bekommen im Schnitt 53 berufliche Nachrichten pro Tag (Bitkom), und 14 Prozent (Bitkom) von ihnen sogar hundert und mehr. Ein Umzug, der drei Tage lang zehn Prozent davon in die falsche Richtung schickt, ist kein Schönheitsfehler.

Der Kern des Problems ist, dass Sie den Wechsel nicht kontrollieren. Ob eine Nachricht beim alten oder beim neuen Server ankommt, entscheidet nicht Ihr Postfach, sondern der sendende Server auf der Gegenseite — und der arbeitet mit der Antwort, die er zuletzt bekommen hat. Ein großer Anbieter formuliert das ungewöhnlich offen und nennt bis zu 72 Stunden (Google Workspace), bis neue MX-Einträge erkannt werden. Drei Tage, in denen ein Teil der Post noch am alten Ziel ankommt, sind also nicht die Ausnahme, sondern der Normalfall.

Wie lange „irgendwann" ist, steht im Standard für den Mailversand. Ein sendender Server soll zwischen zwei Versuchen mindestens 30 Minuten (RFC 5321) warten und insgesamt mindestens vier bis fünf Tage (RFC 5321) versuchen, bevor er aufgibt. Das ist der Sicherheitsabstand, den ein Umzug hat — vorausgesetzt, es entsteht überhaupt eine Warteschlange. Wird die Nachricht dagegen hart abgelehnt, weil kein Server mehr für die Domain zuständig ist, gibt es keine Wiederholung und keine zweite Chance.

Wenn eine Seite nach dem Umzug eine Sicherheitswarnung zeigt, liegt das fast immer daran, dass das Zertifikat erst nach der Umschaltung ausgestellt wurde. Automatische Ausstellungsverfahren prüfen, ob der Antragsteller die Domain kontrolliert — und diese Prüfung läuft über genau die Einträge, die gerade gewechselt werden. Wer die Reihenfolge umdreht und zuerst umschaltet, wartet danach im Zweifel eine Stunde mit einer Warnseite. Wer vorher ausstellt, hat das Problem nicht. Kostenlose Zertifikate sind dabei 90 Tage (Let's Encrypt) gültig, und die Obergrenze für neu ausgestellte Serverzertifikate liegt inzwischen bei 200 Tagen (CA/Browser Forum). Beides bedeutet: Die automatische Erneuerung muss nach dem Umzug am neuen Ort laufen, sonst fällt die Seite Wochen später aus.

Der zweite Stolperstein hat einen längeren Nachlauf. Wer HSTS gesetzt hat, weist Browser an, diese Domain für einen bestimmten Zeitraum ausschließlich verschlüsselt aufzurufen. Für die Aufnahme in die Vorabliste der Browser ist eine Gültigkeit von mindestens 31.536.000 Sekunden (HSTS Preload List) — einem Jahr — verlangt. Das ist die richtige Einstellung für eine Seite im Betrieb, aber sie verzeiht keinen Umzug auf einen Server ohne gültiges Zertifikat: Der Browser lässt den Nutzer dann nicht durchklicken, sondern blockiert.

Die Frage nach dem Aufwand lässt sich nicht mit einer Zahl beantworten, aber mit einer Struktur. Der technische Umzug — Zone anlegen, Einträge setzen, umschalten — ist der kleinste Posten und in wenigen Stunden erledigt. Der größere Posten ist die Bestandsaufnahme davor: herauszufinden, was alles an der Domain hängt, dauert bei einem gewachsenen Betrieb regelmäßig länger als der Umzug selbst. Der dritte Posten ist der Nachlauf, und der lässt sich nicht abkürzen, weil er an Fristen hängt, die nicht Ihnen gehören.

Ein Umzug lohnt sich vor allem dann, wenn ohnehin etwas ansteht. Läuft der Vertrag aus, steht ein Relaunch an oder ist das Hosting an seine Grenzen gekommen, dann ist der Umzug ein Teilschritt und kein Selbstzweck. Worauf bei der Auswahl zu achten ist, steht in unserer Hosting-Auswahl für lokale Betriebe; und wenn Inhalte betroffen sind, die sich häufig ändern — etwa eine Speisekarte mit Allergenangaben — gehört deren Pflegeweg mit auf die Umzugsliste, weil er nach dem Wechsel oft ein anderer ist.

Dass es sich um kein Randthema handelt, zeigt schon die Verbreitung: In Deutschland waren im Juni 2026 über 18 Millionen (DENIC) .de-Domains registriert. Wie selbstverständlich die eigene Webseite im Betrieb geworden ist, zeigt ein regionaler Blick: In Bayern verfügten 2025 92 Prozent (Bayerisches Landesamt für Statistik) der Unternehmen mit mindestens zehn tätigen Personen über eine eigene Webseite. Fast jeder dieser Betriebe steht irgendwann vor einem Anbieterwechsel. Welche Bausteine wir dabei übernehmen, steht in den Leistungen; wie das in der Praxis aussieht, zeigen die Referenzen.

Am Ende ist ein Domainumzug ein Vorgang mit wenigen echten Entscheidungen und vielen kleinen Handgriffen in der richtigen Reihenfolge. Wer die Haltbarkeit vorher senkt, vorher testet, den alten Server anlassen kann und eine Woche hinschaut, wird den Umzug kaum bemerken. Wer es umgekehrt macht, merkt ihn wochenlang. Der Unterschied liegt nicht im Werkzeug, sondern im Kalender.