Ein Registrarwechsel wirkt auf den ersten Blick wie eine Verwaltungsaufgabe: Der Vertrag endet, ein neuer Anbieter wird ausgewählt und die Domain wird übertragen. Für ein Unternehmen ist die Domain jedoch mit Website, E-Mail, Zertifikaten, Weiterleitungen und Wiederherstellungskontakten verbunden. Ein schlecht vorbereiteter Transfer kann deshalb genau dann auffallen, wenn niemand mehr weiß, welche Zugangsdaten gelten oder welcher Nameserver autoritativ ist. Der sichere Ablauf trennt die Verwaltung der Registrierung von der technischen Auflösung und dokumentiert beide Seiten. So bleibt die Domain erreichbar, während das Eigentum und die Zuständigkeiten sauber wechseln.
Beginnen Sie mit einer klaren Ausgangsfrage: Soll nur der Registrar wechseln, oder sollen auch DNS, Mail und Webhosting umziehen? Bei einem reinen Registrarwechsel bleiben die Nameserver normalerweise unverändert. Das bedeutet aber nicht, dass eine Prüfung überflüssig ist. Ein veralteter Eintrag, eine unbekannte Kontaktadresse oder eine Transfer-Sperre kann den Vorgang blockieren. Der Domainprofil hilft bei der ersten Bestandsaufnahme von Registrierung, DNS und TLS. Halten Sie für jede Domain Eigentümer, kritische Dienste, Ablaufdatum, aktuelle Verwaltung und geplantes Wartungsfenster fest.
Transferfähigkeit und Kontaktdaten prüfen
Die Transfer-Richtlinie der ICANN verlangt einen nachvollziehbaren Prozess und eine Autorisierung durch den registrierten Inhaber. In der Praxis braucht der neue Registrar meist einen AuthInfo-Code oder einen vergleichbaren Transfercode. Prüfen Sie, ob der Domainstatus eine Sperre wie ClientTransferProhibited enthält, ob eine Änderung des Inhabers eine neue Wartefrist auslöst und ob die E-Mail-Adresse für Bestätigungen erreichbar ist. Bei .de-Domains gelten die Regeln der Registry und des jeweiligen Registrars. Verlassen Sie sich daher nicht auf eine Anleitung für ein anderes TLD, sondern lesen Sie die konkrete Transferinformation vor dem Antrag.
Die WHOIS-Abfrage liefert nicht immer vollständige personenbezogene Daten, kann aber Registrar, Status, Nameserver und Zeitstempel sichtbar machen. Vergleichen Sie mehrere Angaben und speichern Sie den Zeitpunkt der Prüfung. Eine leere Kontaktangabe bedeutet nicht, dass keine Autorisierung nötig ist. Prüfen Sie den Kontozugriff, die Zwei-Faktor-Authentifizierung und die Adresse, an die der neue Registrar Nachrichten sendet. Wenn ein ehemaliger Mitarbeiter oder eine private Adresse hinterlegt ist, korrigieren Sie das vor dem Transfer nach einem dokumentierten Freigabeprozess. Eine Transferanfrage darf nicht zur Gelegenheit werden, Eigentumsverhältnisse ungeprüft zu verändern.
DNS und Dienste vor dem Wechsel inventarisieren
Erstellen Sie eine Liste aller DNS-Zonen und Einträge, bevor Sie den Antrag abschicken. Dazu gehören A- und AAAA-Einträge, CNAME, MX, TXT, DKIM-Selektoren, SPF, DMARC, Zertifikatsnachweise und Nameserver. Notieren Sie TTL, Ziel, Zweck und verantwortliche Person. Der DNS-Prüfer zeigt die öffentlich beobachtbare Antwort, aber die interne Zonendatei bleibt eine zweite wichtige Quelle. Achten Sie besonders auf Subdomains, die nicht in der Navigation erscheinen: Login, API, Statusseite, Webhooks, Support und Testsysteme werden bei einem oberflächlichen Vergleich leicht vergessen.
- Registrar, Registrant, Ablaufdatum und aktueller Transferstatus.
- AuthInfo-Verfügbarkeit und E-Mail-Adresse für Transferbestätigungen.
- Alle Nameserver sowie deren A-, AAAA- und Glue-Abhängigkeiten.
- Web-, Mail-, API- und Zertifikats-Hostnamen mit kritischer Priorität.
- DNS-Einträge mit TTL, Zweck, Eigentümer und letzter Prüfung.
- Rückfallplan, Wartungsfenster und erreichbare Kontaktpersonen.
Prüfen Sie die Dienste mit ihren echten Hostnamen. Eine Startseite kann funktionieren, während ein MX-Eintrag auf ein altes Postfach zeigt oder ein API-Hostname ein anderes Zertifikat liefert. Testen Sie HTTPS für Root-Domain und www getrennt, prüfen Sie Mailzustellung an eine kontrollierte Adresse und lesen Sie die für Authentifizierung relevanten TXT-Antworten. Der Wechsel des Registrars sollte diese Einträge nicht verändern, doch ein falsch übernommener DNS-Service oder eine unklare Delegation kann es tun. Dokumentieren Sie deshalb nicht nur den erwarteten Zustand, sondern auch die sichtbare Antwort vor dem Transfer.
Antrag stellen und Transfer beobachten
Starten Sie den Transfer erst, wenn der alte Registrar die Sperre entfernt hat und der AuthInfo-Code frisch geprüft wurde. Verwenden Sie ein Wartungsfenster, in dem die verantwortliche Person E-Mail und Statusmeldungen verfolgt. Nach dem Antrag kontrollieren Sie, ob eine Bestätigung aussteht, ob der alte Registrar den Transfer beschleunigen oder ablehnen kann und welche Frist der neue Registrar nennt. Ein Transferstatus ist kein Ersatz für eine Erreichbarkeitsprüfung. Messen Sie DNS, HTTP und Mail parallel und markieren Sie Antworten als bestätigt, verzögert oder unbekannt, statt aus einem einzelnen Timeout einen Ausfall abzuleiten.
Bei einer Ablehnung sollte das Team die konkrete Ursache sichern: Transfer-Sperre, fehlende Zustimmung, noch laufende Wartefrist oder ein Konflikt mit Registry-Regeln sind unterschiedliche Fälle. Wiederholen Sie nicht blind, sondern beheben Sie die Ursache und prüfen Sie den Status erneut. Die ICANN-Richtlinie nennt auch Fälle, in denen ein Transfer wegen Betrugshinweisen, gerichtlichen Anordnungen oder einer begründeten Identitätsstreitigkeit abgelehnt werden kann. Ein Supportticket beim Registrar und die öffentliche Statusantwort gehören zur Nachvollziehbarkeit. Teilen Sie AuthInfo-Codes nicht in Chatkanälen und speichern Sie keine unnötigen Zugangsdaten in einem Bericht.
Nach dem Transfer absichern
Wenn der neue Registrar als zuständig angezeigt wird, beginnt die Nacharbeit. Prüfen Sie Registrant, Organisation, E-Mail-Adresse, Ablaufdatum, Nameserver und Transferstatus im neuen Konto. Aktivieren Sie Mehrfaktor-Authentifizierung, entfernen Sie ehemalige Nutzer und setzen Sie eine interne Verlängerungserinnerung. Kontrollieren Sie, dass Rechnungen und Warnungen an eine überwachte Firmenadresse gehen. Bei einem Eigentümerwechsel können zusätzliche Sperrfristen gelten. Dokumentieren Sie die Entscheidung und lassen Sie eine zweite Person die Kontodaten gegen die Freigabe prüfen. Ein erfolgreicher Transfer ist kein Beweis, dass das Konto dauerhaft gut geschützt ist.
Führen Sie anschließend eine externe Nachmessung durch. Vergleichen Sie die gespeicherten DNS-Werte mit den aktuellen Antworten, rufen Sie die Website über IPv4 und IPv6 auf und testen Sie die Zertifikatsabdeckung. Senden Sie eine Testmail, prüfen Sie die Antwort des MX-Ziels und kontrollieren Sie die für SPF, DKIM und DMARC relevanten Namen. Das Tool für Domain-Gesundheit kann diese Sicht in einen wiederholbaren Prüfpunkt einordnen. Wenn sich ein Wert unerwartet verändert hat, klären Sie zuerst die Eigentümerschaft der Zone und die Änderungszeit, bevor Sie zurückrollen oder weitere Einträge bearbeiten.
Mehrere Domains und Agenturprozesse
Agenturen und Unternehmen mit vielen Domains sollten Transfers nicht als Sammelaktion ohne Einzelnachweis durchführen. Gruppieren Sie Domains nach TLD, Kritikalität, Mailnutzung und Eigentümer. Jede Gruppe kann ein anderes Verfahren, eine andere Frist oder eine andere Zustimmung benötigen. Führen Sie zunächst einen Pilottransfer mit einer nicht kritischen Domain aus und prüfen Sie, welche Statusmeldungen und Belege tatsächlich entstehen. Danach arbeiten Sie mit einer Checkliste, die pro Domain AuthInfo, Kontaktdaten, Nameserver, DNS-Bestand, Ablaufdatum und Nachtest festhält. So wird eine scheinbar einfache Kostenoptimierung nicht zur unbemerkten Betriebsänderung.
Für Portfolios lohnt sich eine periodische Überwachung von Registrar, Status, Ablauf und Nameservern. Ein unerwarteter Wechsel kann ein Verwaltungsfehler sein, aber auch ein Hinweis auf einen unautorisierten Transfer. Speichern Sie die Änderung mit Zeit, Quelle und zuständiger Person. Die WHOIS-Abfrage und die API-Dokumentation können dabei als Einstieg für manuelle oder integrierte Prüfungen dienen. Formulieren Sie klare Eskalationsregeln: Bei unbekannter Änderung Konto sichern, beim Registrar nachfragen und erst danach technische Dienste verändern. Eine unklare Antwort bleibt unbekannt, bis sie durch eine autoritative Quelle geklärt ist.
Änderungsfenster und Rückfall sauber dokumentieren
Schreiben Sie für jeden Transfer auf, was sich ändern soll und was ausdrücklich unverändert bleibt. Dazu gehören Registrar, Konto und Status einerseits sowie Nameserver, DNS-Zone und Dienstziele andererseits. Legen Sie fest, welche Person den Transfer starten darf und wer den Abschluss bestätigt. Bei kritischen Domains gehört eine zweite Freigabe dazu. Prüfen Sie vor Beginn, ob ein laufender DNS- oder Websitewechsel den Transfer überlagert. Zwei gleichzeitige Änderungen können eine korrekte Ursache verschleiern. Ein kurzes Änderungsprotokoll mit Uhrzeit, Quelle und Entscheidung erleichtert die Rückkehr zu einem bekannten Zustand.
Wenn ein Transfer länger dauert, behandeln Sie die Verzögerung als eigenen Zustand. Prüfen Sie, ob eine E-Mail-Bestätigung fehlt, ob ein Sperrstatus noch aktiv ist oder ob eine Registry eine zusätzliche Prüfung verlangt. Ändern Sie währenddessen nicht parallel die Nameserver, außer der Plan sieht es ausdrücklich vor. Nach der Übernahme vergleichen Sie den Status mit einer autoritativen Antwort und testen die Dienste über mehrere Netze. Erst wenn Eigentum, Verwaltung und Erreichbarkeit zusammenpassen, schließen Sie das Wartungsfenster. Ein sauberer Rückfallplan beschreibt auch, wer die Kommunikation an Kunden und interne Teams übernimmt.
Änderungsfenster und Rückfall sauber dokumentieren
Schreiben Sie für jeden Transfer auf, was sich ändern soll und was ausdrücklich unverändert bleibt. Dazu gehören Registrar, Konto und Status einerseits sowie Nameserver, DNS-Zone und Dienstziele andererseits. Legen Sie fest, welche Person den Transfer starten darf und wer den Abschluss bestätigt. Bei kritischen Domains gehört eine zweite Freigabe dazu. Prüfen Sie vor Beginn, ob ein laufender DNS- oder Websitewechsel den Transfer überlagert. Zwei gleichzeitige Änderungen können eine korrekte Ursache verschleiern. Ein kurzes Änderungsprotokoll mit Uhrzeit, Quelle und Entscheidung erleichtert die Rückkehr zu einem bekannten Zustand.
Planen Sie die Kommunikation genauso sorgfältig wie die Technik. Informieren Sie Support, Finanzen und Marketing, welche Domain betroffen ist, ob Kunden eine Änderung sehen und welche Kontaktadresse bei einer Verzögerung gilt. Prüfen Sie Rechnungszugang und automatische Verlängerung im neuen Konto, bevor Sie den alten Vertrag schließen. Bei mehreren TLDs kann ein Transfer unterschiedliche Bestätigungen und Fristen auslösen. Halten Sie pro Domain eine Entscheidung fest, statt den Zustand aus einer Sammelbestätigung abzuleiten. Nach sieben oder vierzehn Tagen folgt eine zweite Kontrolle von Status, Nameservern, Mail und TLS. So werden stille Konto- oder Kontaktfehler entdeckt, bevor die nächste Verlängerung fällig wird.
Bei Domains mit mehreren Sprachen oder Ländern prüfen Sie zusätzlich, ob jede Variante im richtigen Konto und unter dem richtigen Vertrag geführt wird. Eine Sammelrechnung ersetzt keine Eigentumsprüfung. Ordnen Sie jede Domain einer Marke und einem Geschäftszweck zu und halten Sie Abweichungen als offene Aufgabe fest. So bleibt nach dem Transfer nachvollziehbar, welche Namen aktiv, reserviert oder zur Stilllegung vorgesehen sind.
- Ziel und Umfang des Wechsels schriftlich festlegen.
- Transferfähigkeit, Inhaber, AuthInfo und Bestätigungsadresse prüfen.
- DNS, Mail, Web, API und TLS vor dem Antrag messen.
- Transferstatus und Meldungen im Wartungsfenster verfolgen.
- Nach Abschluss Konto, Kontaktdaten, Status und Ablaufdatum absichern.
- DNS, HTTP, Mail und Zertifikat extern vergleichen und Belege archivieren.
Die Domain soll den Registrar wechseln, nicht unbemerkt ihre Identität oder ihre Dienste verlieren.
Grundsatz für kontrollierte Domaintransfers
Ein geplanter Registrarwechsel lässt sich ohne Ausfall durchführen, wenn Sie Autorisierung, Transferstatus und technische Abhängigkeiten getrennt prüfen. Beginnen Sie mit WHOIS-Abfrage, erfassen Sie DNS und TLS im Domainprofil und wiederholen Sie die Messung nach dem Transfer. Für wiederkehrende Portfolio-Checks finden Sie in der API-Dokumentation die verfügbaren Prüfungen. Halten Sie Unsicherheit sichtbar und lassen Sie jede Änderung einer verantwortlichen Person zuordnen.