Blog · DNS und Domainumzug ·
Domain umziehen ohne Mailausfall: Checkliste für Agenturen
Für einen Domainumzug ohne Mailausfall müssen die Maildienste während der Umstellung erreichbar und ihre DNS-Einträge vollständig bleiben. Der erste Schritt ist deshalb die Klärung, was überhaupt umzieht: Registrierung, autoritatives DNS, Website oder Postfächer. Diese Checkliste führt durch einen DNS-Anbieterwechsel bei unverändertem Mailanbieter. Ein lokaler Test zeigt, wie fehlende Mail-Einträge vor der Umschaltung auffallen.
Was bedeutet Domainumzug in diesem Projekt?
Ein Registrarwechsel, ein Nameserverwechsel, ein Website-Umzug und ein Postfachumzug sind verschiedene Änderungen. Eine neue Website braucht nicht automatisch neue Nameserver. Ein Registrarwechsel kann je nach Ablauf die bestehende Delegation erhalten. Ein neuer Mailanbieter verlangt zusätzlich die Übernahme von Postfächern, Konten, Geräten und Nachrichten. Schreiben Sie vor jedem Termin auf, welche dieser Änderungen tatsächlich beauftragt ist.
Der folgende Ablauf behandelt den Wechsel des autoritativen DNS-Anbieters; der Mailanbieter bleibt gleich. Die Website kann anschließend separat umgestellt werden. Prüfen Sie trotzdem beim bisherigen Anbieter, ob DNS oder Mail an ein gekündigtes Hostingpaket gebunden sind. Ein unveränderter MX-Eintrag hilft wenig, wenn das dazugehörige Postfach mit dem Paket abgeschaltet wird.
Benennen Sie eine Person, die die Umstellung ausführt, eine erreichbare Vertretung und eine Person beim Kunden, die die fachlichen Tests abnimmt. Registrar, DNS und Mail sollten in kundenkontrollierten Konten liegen oder einen ausdrücklich vereinbarten Übergabeweg haben. Der Leitfaden Software an Kunden übergeben ergänzt diese organisatorische Vorbereitung.
Welche Einträge müssen vor dem DNS-Umzug erfasst werden?
Beginnen Sie mit einem Export der vollständigen Zone und den Einstellungen der tatsächlich genutzten Dienste. Eine Suche nach wenigen bekannten Namen ersetzt kein Inventar: DKIM-Selektoren, delegierte Subdomains und Verifikationseinträge lassen sich damit leicht übersehen. Halten Sie Quelle und Datum des Exports fest und markieren Sie Änderungen, die danach noch am alten Anbieter erfolgen.
| Bereich | Aufnehmen und abgleichen |
|---|---|
| Website | A, AAAA, CNAME, Weiterleitungen und gegebenenfalls anbieterspezifisches Flattening; alte und neue Zielsysteme getrennt notieren. |
| Mailempfang | Alle MX-Ziele mit Prioritäten sowie A/AAAA der MX-Hostnamen, soweit diese zur umziehenden Zone gehören. |
| Mailversand | SPF, aktive DKIM-Selektoren, DMARC und sämtliche versendenden Dienste: Postfächer, Newsletter, Formulare, CRM und Rechnungssoftware. |
| Weitere Maildienste | Autodiscover, SRV und Verifikationen; falls eingesetzt MTA-STS, TLS-Berichte und DANE/TLSA. |
| Delegation und TLS | Nameserver, gegebenenfalls Glue, DS und DNSKEY, CAA sowie delegierte ACME-Challenges und Subdomains. |
Trennen Sie DNS-Daten von Funktionen des alten Anbieters. Eine HTTP-Weiterleitung oder ein aus einem Zielnamen berechneter A-Eintrag ist nicht einfach ein kopierbarer Standard-Record. Prüfen Sie, wie die neue Umgebung dieselbe Aufgabe übernimmt. Auch ein vergessener AAAA-Eintrag kann einen Teil der Website-Besucher weiter auf das alte Ziel schicken.
MX allein erhält noch keinen funktionierenden Mailbetrieb
MX beschreibt den Weg eingehender Nachrichten. SPF und DKIM werden dagegen für die Prüfung ausgehender Nachrichten gebraucht. Bei unverändertem Mailanbieter übernehmen Sie dessen freigegebene Werte vollständig. Ersetzen Sie sie nicht durch vermutete Standardwerte des neuen Website-Hosters.
SPF erlaubt nicht mehrere auswählbare SPF-Records für denselben Namen. Zwei getrennte TXT-Einträge mit jeweils v=spf1 sind daher kein
sicherer Weg, einen zusätzlichen Versanddienst anzuschließen. Die zulässigen
Absender gehören in eine abgestimmte Policy; auch deren DNS-Abfragen müssen
innerhalb der SPF-Grenzen bleiben. Eine IP-Freigabe für den Webserver ist nur
sinnvoll, wenn genau dieser Server tatsächlich versendet.
DKIM-Selektoren gehören zu den jeweiligen Versanddiensten. Sie können als TXT-Werte oder durch vom Anbieter vorgegebene CNAME-Verweise veröffentlicht sein. Aus einer einzigen Testnachricht lässt sich nicht ableiten, dass Newsletter und Rechnungssoftware denselben Selektor nutzen. DKIM verwendet den Selektor zur Zuordnung des veröffentlichten Schlüssels.
DMARC betrachtet zusätzlich die Ausrichtung zur sichtbaren Absenderdomain. Ein SPF- oder DKIM-Erfolg irgendeiner Domain genügt dafür nicht. Behalten Sie die freigegebene DMARC-Policy beim reinen DNS-Umzug bei; eine strengere Policy ist eine eigene Änderung. Falls MTA-STS eingesetzt wird, muss auch die über HTTPS bereitgestellte Policy weiter erreichbar bleiben und zu den Mailservern passen. Der TXT-Eintrag allein enthält diese Policy nicht.
Wann müssen TTLs gesenkt werden?
Eine niedrigere TTL wirkt erst bei neu abgefragten Antworten; sie verkürzt bereits gespeicherte Antworten nicht rückwirkend. Notieren Sie deshalb zunächst die bisherige TTL. Wenn ein relevanter Eintrag bislang 86.400 Sekunden zwischengespeichert werden darf, schafft die Senkung auf 300 Sekunden unmittelbar vor dem Termin kein verlässliches Fünf-Minuten-Fenster. Planen Sie den Vorlauf aus den tatsächlich vorhandenen Werten.
Betrachten Sie die TTLs der Nutzdaten, der Delegation und der DS-Einträge getrennt. Werte in der übergeordneten Zone sind nicht unbedingt im DNS-Panel des Kunden veränderbar. RFC 2181 beschreibt die TTL als Grenze für das Zwischenspeichern; sie ist keine Zusage, wann alle Nutzer weltweit einen neuen Stand sehen.
Auch das bisherige Fehlen eines Namens kann zwischengespeichert sein. Ein neu hinzugefügter DKIM-Selektor muss deshalb rechtzeitig veröffentlicht und geprüft werden. Negative DNS-Antworten haben eigene Cache-Regeln. Ein pauschales „nach 24 Stunden ist alles umgestellt“ ersetzt die Prüfung dieser Werte und der tatsächlich beobachteten Antworten nicht.
Wie bleibt die DNSSEC-Kette beim Anbieterwechsel gültig?
Ein alter DS-Eintrag beim Registrar darf nicht auf einen neuen DNS-Betrieb zeigen, der den dazugehörigen Schlüssel nicht mehr bereitstellt. Validierende Resolver können eine solche Zone als fehlerhaft behandeln. Ein erfolgreicher Abruf direkt vom neuen Nameserver beweist noch keine gültige Vertrauenskette. Die Einführung Was ist DNSSEC? erklärt die beteiligten Ebenen.
Stimmen Sie das Verfahren mit beiden DNS-Betreibern und dem Registrar ab. Wenn sie einen gemeinsamen, durchgehend signierten Übergang unterstützen, brauchen Schlüssel, Signaturen, DS und Nameserver eine abgestimmte Reihenfolge. RFC 6781 behandelt den Wechsel zwischen kooperierenden und nicht kooperierenden Betreibern. Einen universellen Knopf-Ablauf für alle Anbieter gibt es daraus nicht.
Wenn nur ein Übergang mit vorübergehend unterbrochener DNSSEC-Vertrauenskette möglich ist, muss er ausdrücklich vereinbart werden: DS beim zuständigen Registrar entfernen, den Ablauf alter DS-Antworten berücksichtigen, erst dann auf eine dafür vorbereitete neue Zone wechseln. Die neue Signierung wird geprüft und anschließend ihr passender DS veröffentlicht. Während der Unterbrechung fehlt die DNSSEC-Absicherung. Bei DANE-abhängigen Mailwegen kann gerade diese Unterbrechung relevant sein; deren Verträglichkeitsprüfung gehört vor den Wechsel.
Dokumentieren Sie denselben Ablauf auch für eine Rückkehr. Nur die alten Nameserver wieder einzutragen reicht nicht, wenn mittlerweile ausschließlich der neue DS gültig ist. Unser lokales Beispiel unten prüft keine DNSSEC-Signaturen oder öffentlichen DS-Einträge.
Lokale Probe: fehlenden DKIM-Eintrag vor der Umschaltung erkennen
Die veröffentlichte Fixture verwendet die synthetische Zone
agency.test. Sie startet nacheinander drei kurzlebige BIND-Server auf
der lokalen Loopback-Adresse: den Ausgangsstand, eine fehlerhafte Kopie und die
korrigierte Kopie. Der Website-A-Eintrag und der Nameserver ändern sich. Zehn
mailbezogene Record-Sets sollen gleich bleiben.
In der fehlerhaften Kopie fehlt absichtlich der CNAME für einen DKIM-Selektor; außerdem zeigt MX auf das falsche Ziel. Der Runner fragt jeden Stand direkt über DNS/TCP ab und verlangt autoritative Antworten. Er prüft zuerst die erwarteten Werte des Ausgangsstands. Dadurch würden nicht zwei gemeinsam leere Antworten als erfolgreiche Übernahme zählen.
Am 28. September 2026 bestanden mit BIND und DiG 9.20.29 alle 24 Prüfungen: zehn erwartete Ausgangswerte, zehn erhaltene Record-Sets, zwei erkannte Fehler und die beiden beabsichtigten Änderungen an Website-Adresse und Nameserver. Der Ergebnisdatensatz enthält Antworten, Versionen und Quelltext-Prüfsumme.
Das ist ein Test des lokalen Zonenvergleichs. Er misst weder öffentliche Cache-Laufzeiten noch Registrar-Delegation, DNSSEC, TLS oder Mailzustellung. Die synthetischen TXT-Werte und CNAME-Ziele werden als DNS-Inhalte verglichen; SPF, DKIM und DMARC werden nicht ausgewertet. Der Versuch ersetzt deshalb keine Testnachricht über den tatsächlichen Mailanbieter.
Voraussetzungen sind Python 3.10 oder neuer sowie BIND mit named,
dig, named-checkconf und named-checkzone im
Suchpfad. Speichern Sie den
Runner und starten
Sie ihn gemäß Anleitung:
python3 run.py > results.jsonDas Skript nimmt keine Produktionsadresse an, ändert keine DNS-Konten und beendet seine eigenen Server wieder. Die Beispieldaten und der Runner sind unter MIT zur Anpassung verfügbar.
Umschalten, prüfen und den alten Dienst erst danach beenden
- Vorbereiten: Die vollständige Zone am neuen Anbieter anlegen. Jede vorgesehene autoritative Instanz direkt abfragen; Mailwerte, Webziele und Delegationen mit dem freigegebenen Inventar vergleichen. Alte Dienste bleiben aktiv.
- Änderungen koordinieren: Entweder ein kurzes Änderungsfenster vereinbaren oder Änderungen bis zum Abschluss an beiden DNS-Ständen nachführen. Nur eine Person ändert die Delegation nach dem vereinbarten DNSSEC-Verfahren.
- Öffentlichen Weg prüfen: Delegation und DNSSEC über geeignete Prüfwerkzeuge kontrollieren. Antworten aus mehreren unabhängigen Resolver-Sichten vergleichen und Zeitpunkt, Resolver und Ergebnis protokollieren. Stichproben beweisen keine weltweite Umstellung.
- Mail testen: Berechtigte Testnachrichten von einem externen Konto empfangen und nach außen versenden. Newsletter, CRM und Kontaktformular jeweils gesondert prüfen. Empfang, Header und Authentifizierungsergebnisse beim Empfänger dokumentieren, personenbezogene Inhalte sparsam halten.
- Beobachten und abschließen: Zustellfehler, Warteschlangen und erreichbare Webziele mit dem Mailbetreiber verfolgen. Erst nach den vereinbarten Cache-Fristen, funktionierenden Tests und Kundenfreigabe alte DNS-Dienste beenden; die Maildienst-Vertragsbindung vorher erneut prüfen.
Eine noch erreichbare Website ist kein Mailtest. Ebenso bestätigt eine einzelne zugestellte Nachricht nicht alle Versanddienste oder die Zustellung bei jedem Empfänger. Schreiben Sie in den Abschluss deshalb genau, welche Wege erfolgreich geprüft wurden und welche noch offen sind.
Was gehört in den Rückweg?
Vereinbaren Sie vor dem Termin beobachtbare Abbruchkriterien: etwa nicht auflösbare MX-Ziele, DNSSEC-Validierungsfehler oder ein fehlgeschlagener berechtigter Empfangstest. Halten Sie alte Records, Nameserver, DS-Zustand und erreichbare Verantwortliche bereit. Die Entscheidung zum Rückweg braucht eine zuständige Person, keine improvisierte Gruppenabstimmung.
Ein fehlender Record lässt sich gegebenenfalls am neuen Anbieter korrigieren. Eine Rückdelegation kann wegen bestehender Caches ebenfalls Zeit benötigen; beide Stände müssen in dieser Zeit für den vereinbarten Dienst funktionieren. Ein DNS-Rollback stellt keine gelöschten Postfächer und keine bereits veränderten Anwendungsdaten wieder her. Wenn auch der Mailanbieter wechselt, braucht dessen Datenmigration einen eigenen Plan.
Die editierbare Domainumzug-Checkliste enthält Inventar, Vorlauf, DNSSEC-Entscheidung, Freigaben und ein Testprotokoll. Füllen Sie sie mit echten Projektwerten. „Ohne Mailausfall“ ist das Planungsziel; dieser Leitfaden gibt dafür keine pauschale Garantie.
Das Kundenprojekt mit obhut besprechen
obhut entwickelt eine Betriebsplattform für Agenturen mit Websites, Kundenportalen, SaaS und internen Anwendungen. Statisches Hosting, DNS sowie HTTP/HTTPS-Proxy und Tunnel sind implementiert.
Identitätsbasierter Access, WAF für Kundentraffic und Serverlaufzeiten sind geplant. Ein Hosting- oder Proxy-Baustein übernimmt nicht automatisch die Anwendungspflege, Mailmigration oder Wiederherstellung von Kundendaten. Ein laufender Wartungsvertrag und dessen Leistungen müssten gesondert vereinbart werden.
Im Projektgespräch für Agenturen klären wir Ihre Anwendung, den geplanten Wechsel und die heutigen Zuständigkeiten. Bringen Sie eine kurze Systemübersicht und die offenen Betriebsfragen mit; Zugangsdaten gehören nicht in das Kontaktformular.
Quellen und Prüfstand
Quellen und lokales DNS-Beispiel geprüft am 28. September 2026. Synthetische Zone; keine produktive Domain umgezogen, keine E-Mail versandt.
