Die neue Website kann einwandfrei erscheinen, während Rechnungen, Passwortlinks und Kundenantworten nicht mehr ankommen. Der Fehler liegt darin, einen Nameserverwechsel als reine Website-Einstellung zu betrachten. Dieser Arbeitsplan richtet sich an kleine Unternehmen, die ihren DNS-Anbieter wechseln und ihren bisherigen Postfachdienst behalten. Er beschreibt ein Vorgehen, keine Garantie für unterbrechungsfreie Zustellung. Die Beispiele verwenden den reservierten Namen example.com; setzen Sie Ihre eigene Domain und die Werte Ihres Anbieters ein. FESTLEGEN, WAS UMZIEHT Notieren Sie drei getrennte Dienste: den Registrar der Domain, den Anbieter der autoritativen DNS-Antworten und den Betreiber der Postfächer. Bei dieser Migration ändern Sie nur den zweiten. Website-Hosting, Postfachvertrag und Versanddienste bleiben bestehen. Möchte ein Kollege gleichzeitig Postfächer umziehen, planen Sie dafür ein eigenes Projekt mit eigenem Termin. Diese Trennung erlaubt es, eine Störung einzugrenzen, statt mehrere Migrationen gleichzeitig untersuchen zu müssen. BESTAND AUFNEHMEN, BEVOR SIE NAMESERVER ÄNDERN Exportieren Sie die bestehende Zone und speichern Sie daneben eine lesbare Fassung. Ihre Tabelle braucht Name, Typ, Wert, Priorität, TTL, Zweck, Dienstverantwortlichen und Prüfergebnis. Erfassen Sie den Zonennamen, www, mail, autodiscover, DKIM-Selektoren, _dmarc und sämtliche Verifizierungsdatensätze. Ergänzen Sie Einträge für CRM, Rechnungssoftware und Kundendienst, auch wenn niemand mehr weiß, wer sie eingerichtet hat. Fragen Sie die jeweiligen Verantwortlichen, ob diese Anwendungen noch unter Ihrer Domain senden. MX-Datensätze bestimmen Mailserver; TXT-Datensätze können E-Mail-Richtlinien veröffentlichen. SPF, DKIM und DMARC erfüllen unterschiedliche Aufgaben: Einer ersetzt die anderen nicht. Ihre Spezifikationen sind unten verlinkt. Erfassen Sie die tatsächlichen bisherigen Werte, statt eine allgemeine Anleitung zu kopieren. Veröffentlichen Sie nicht zusätzlich eine konkurrierende SPF-Richtlinie, nur weil die neue DNS-Oberfläche sie vorschlägt. DIE NEUE ZONE PROBEN Erstellen Sie die Zielzone und vergleichen Sie jeden Eintrag mit dem Bestand. Automatische Erkennung liefert einen Ausgangspunkt, keinen Abnahmenachweis. Im fiktiven Beispiel bleibt sales@example.com beim bisherigen Postfachanbieter: MX-Ziele und Prioritäten sollten daher unverändert bleiben. Auch der A-Datensatz der Website kann bestehen bleiben. Ein DNS-Umzug verlangt keine neuen erfundenen Mail- oder Webadressen. Fragen Sie vor dem Delegationswechsel jeden neuen autoritativen Server direkt ab. Speichern Sie die Ergebnisse für MX, den TXT-Datensatz am Zonenanfang, _dmarc und alle aktiven DKIM-Selektoren. Beispielsweise können Sie dig @NEW_NAMESERVER example.com MX verwenden und den Platzhalter durch den zugeteilten Server ersetzen. Vergleichen Sie vollständige Werte, nicht bloß das Vorhandensein eines Eintrags. Ein fehlender Selektor kann nur einen Versanddienst treffen und bei einer beiläufigen Prüfung unbemerkt bleiben. Wählen Sie ein ruhiges Wartungsfenster und einen zuständigen Ausführenden. Halten Sie die bisherigen Nameserver und die Kennung der Zielzone im selben Änderungsticket fest. Wenn Sie TTLs reduzieren möchten, tun Sie dies vorher und warten Sie die bisherige TTL ab; eine Änderung in letzter Minute leert keine Caches sofort. Legen Sie fest, wann über einen Rückwechsel entschieden wird und wer ihn freigeben darf. DNSSEC ALS EIGENEN PRÜFPUNKT BEHANDELN Prüfen Sie bei aktiviertem DNSSEC die vorhandenen DS-Daten und befolgen Sie das Migrationsverfahren des neuen Anbieters. Lassen Sie keinen DS-Datensatz in der übergeordneten Zone stehen, dessen Schlüssel die neue Zone nicht verwenden kann. Cloudflares Dokumentation zum vollständigen Setup erläutert diese Abhängigkeit. Eine signierte Zone braucht einen ausdrücklichen DNSSEC-Schritt im Ticket, statt der Annahme, das Nameserverformular erledige alles. DEN KUNDENABLAUF TESTEN, NICHT NUR DIE WEBSITE Senden Sie vor und nach dem Wechsel eine eindeutig markierte Nachricht von einem externen Postfach an eine echte Geschäftsadresse und antworten Sie darauf. Wiederholen Sie den Test mit einem zweiten externen Anbieter. Lösen Sie anschließend eine Passwortzurücksetzung, eine Supportmeldung und eine Beispielrechnung aus den inventarisierten Anwendungen aus. Nutzen Sie Testkunden und nicht vertrauliche Inhalte. Dokumentieren Sie die erwartete Nachricht, ihren Eingang und die vorgesehenen Authentifizierungsergebnisse in den Kopfzeilen. Funktioniert die Website, aber nicht der Posteingang, beginnen Sie mit MX und dem empfangenden Maildienst. Scheitern nur CRM-Nachrichten, vergleichen Sie dessen Authentifizierungseinträge und Protokolle. Tritt die Störung nur in einem Netz auf, vergleichen Sie DNS-Antworten, bevor Sie Anwendungseinstellungen ändern. Dieser vorgeschlagene Diagnoseweg grenzt die Suche ein; allein beweist er keine Ursache. MIT NACHWEISEN ABSCHLIESSEN Halten Sie beide DNS-Dienste während des vereinbarten Beobachtungszeitraums verfügbar. Vermeiden Sie sachfremde Änderungen, solange Ergebnisse gesammelt werden. Schließen Sie das Ticket erst, wenn Bestandsvergleich, externe Mailtests und Prüfungen der Geschäftsanwendungen dokumentierte Ergebnisse und Verantwortliche haben. Speichern Sie den endgültigen Zonenexport, den Zeitpunkt und offene Ausnahmen. Diese kleine Dokumentation hilft beim nächsten Umzug mehr als ein Bildschirmfoto mit dem Status aktiv. Planen Sie eine neue Marke? Vergleichen Sie Namen im DomainEvery-Katalog: https://domainevery.com/de/domains und nehmen Sie die Verantwortung für E-Mail und DNS in Ihre Startplanung auf. PRIMÄRQUELLEN Cloudflare: Nameserver ändern: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/; Cloudflare: E-Mail-Datensätze: https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/; DNS-Formate, RFC 1035: https://www.rfc-editor.org/rfc/rfc1035.html; SPF, RFC 7208: https://www.rfc-editor.org/rfc/rfc7208; DKIM, RFC 6376: https://www.rfc-editor.org/rfc/rfc6376.html; DMARC, RFC 7489: https://www.rfc-editor.org/rfc/rfc7489.html.