Ein Domain-Umzug klingt technisch überschaubar – bis um 10 Uhr morgens die Buchhaltung anruft, weil seit Stunden keine E-Mails mehr ankommen. Der häufigste Grund: Der MX-Record wurde entweder mit einem zu hohen TTL umgestellt, der DKIM-Selector fehlt auf dem neuen Server, oder es gibt plötzlich zwei SPF-Einträge auf der Domain. Diese Anleitung führt dich Schritt für Schritt durch einen unterbrechungsfreien Umzug – von der Vorbereitung über den eigentlichen Cutover bis zum sicheren Abschalten der alten Umgebung.

Voraussetzungen

Zugang zum aktuellen DNS-Provider mit Bearbeitungsrechten (Nameserver-Verwaltung)
Zugang zum neuen Hosting/DNS-Provider – die Zone muss vor dem Cutover vollständig eingerichtet sein
Zugang zum Domain-Registrar (für den Nameserver-Wechsel oder den EPP-Auth-Code bei Registrar-Wechsel)
Vollständiger DNS-Record-Export der aktuellen Zone (per dig oder Provider-Panel)
DKIM-Schlüsselpaar vom neuen Mailserver (öffentlicher Schlüssel für den DNS-TXT-Record, privater Schlüssel für den Mailserver)
Zugangsdaten zum neuen Mailserver (SMTP/IMAP) für Zustelltests vor dem Cutover
Externe Test-E-Mail-Konten bei Gmail, Outlook.com oder GMX für Empfangs- und Versandtests
Geplantes Wartungsfenster in Nebenstunden (z. B. Sonntag 2–4 Uhr) für den eigentlichen Cutover-Schritt
dig (Linux/macOS) oder nslookup (Windows) installiert; alternativ MXToolbox im Browser

Schritt 1: TTL vorab senken – mindestens 48 Stunden vor dem Cutover

Resolver cachen DNS-Antworten bis zum Ablauf des aktuellen TTL-Werts. Wenn dein A-Record heute noch einen TTL von 86400 Sekunden (24 Stunden) hat, musst du nach dem Absenken auf 300 Sekunden erneut 24 Stunden warten, bis der kurze TTL universell gilt. Plane daher mindestens 48 Stunden Vorlauf ein. Wichtig: Nicht nur der A-Record – alle Records müssen angepasst werden, besonders der MX-Record, der bei vielen Admins vergessen wird.

Setze in deiner aktuellen DNS-Zone folgende TTL-Werte auf 300 (5 Minuten):

Record-Typ	Typischer Ist-Wert	Ziel-Wert	Warum wichtig
A / AAAA	3600–86400 s	300 s	Webserver-IP, kritisch für Website
MX	3600–86400 s	300 s	Mailrouting – vergessen = 24 h E-Mail-Ausfall
TXT (SPF)	3600 s	300 s	SPF-Änderungen gelten schnell
TXT (DKIM)	3600 s	300 s	Selector-Wechsel ohne Wartezeit
TXT (_dmarc)	3600 s	300 s	Policy-Änderungen wirken sofort
CNAME (autoconfig)	3600 s	300 s	Thunderbird/Outlook-Autokonfiguration

Schritt 2: Vollständige DNS-Zone inventarisieren

Vor dem Cutover musst du jeden Record kennen. Besonders TXT-Records für Drittdienste (Google Search Console, Microsoft 365, Stripe, Mailchimp) tauchen in Provider-Exporten oft nicht prominent auf und werden leicht übersehen.

# Vollständige Inventarisierung – alle relevanten Record-Typen abfragen
dig +noall +answer example.com A
dig +noall +answer example.com AAAA
dig +noall +answer example.com MX
dig +noall +answer example.com TXT
dig +noall +answer example.com NS
dig +noall +answer example.com SOA
dig +noall +answer example.com CAA

# DMARC-Record
dig +noall +answer _dmarc.example.com TXT

# DKIM-Selektoren prüfen (Selector-Namen im Mailserver-Log nachschlagen)
dig +noall +answer mail._domainkey.example.com TXT
dig +noall +answer default._domainkey.example.com TXT

# Autokonfiguration für E-Mail-Clients
dig +noall +answer autoconfig.example.com A
dig +noall +answer autodiscover.example.com A

Auf Windows ohne dig kannst du nslookup verwenden:

# Windows nslookup – MX und TXT Records prüfen
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

Trage alle gefundenen Records in eine Tabelle (Spreadsheet) ein. Das ist dein Migrationsdokument und dein Rollback-Referenzpunkt. Weitere Hinweise zu DNS-Record-Typen findest du in der Anleitung DNS-Records erklärt: A, AAAA, CNAME, MX, TXT.

Schritt 3: DKIM für den neuen Mailserver vorbereiten

Das ist der häufigste stille Fehler beim Mailserver-Wechsel: Der neue Server verwendet einen anderen DKIM-Selector oder Schlüssel, der im DNS noch nicht eingetragen ist. Ausgehende E-Mails haben dann eine ungültige DKIM-Signatur, DMARC schlägt fehl, und Mails landen im Spam – ohne Fehlermeldung für den Absender.

Die sichere Migrationsstrategie lautet: Neuen Selector zuerst im DNS veröffentlichen, parallel zum alten betreiben, dann erst den alten Mailserver abschalten.

# Neues DKIM-Schlüsselpaar generieren (2048 Bit RSA, Linux/OpenSSL)
openssl genrsa -out dkim_private.key 2048
openssl rsa -in dkim_private.key -pubout -out dkim_public.key

# Öffentlichen Schlüssel ohne Header für den DNS-TXT-Record extrahieren:
grep -v -- '-----' dkim_public.key | tr -d '\n'

Den so gewonnenen Base64-String trägst du als TXT-Record in der neuen DNS-Zone ein. Wähle einen neuen Selector-Namen (z. B. mail2025), damit alter und neuer Selector gleichzeitig im DNS existieren können:

# DNS-TXT-Record für neuen DKIM-Selector
# Zonenname: mail2025._domainkey.example.com
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...[base64-public-key]...

Veröffentliche diesen Record vor dem Cutover im DNS. Der alte Selector (z. B. mail._domainkey.example.com) bleibt mindestens 1–2 Wochen nach dem Umzug aktiv, damit noch unterwegs signierte E-Mails validiert werden können. Für Setups auf eigenem Linux-Server hilft die Anleitung OpenDKIM und Postfix: DKIM-Signatur einrichten.

Schritt 4: SPF-Record konsolidieren

Es darf genau einen SPF-TXT-Record pro Domain geben. Viele Hosting-Control-Panels legen beim neuen Hosting automatisch einen zweiten SPF-Record an. Zwei v=spf1-Einträge auf einer Domain führen laut RFC 7208 sofort zu PermError – E-Mails werden abgewiesen.

# Korrekter SPF-Record (NUR EIN TXT-Record auf der Apex-Domain)
# Beispiel: eigener Server + Google Workspace als Versandquelle
v=spf1 ip4:203.0.113.42 include:_spf.google.com ~all

# Qualifier-Bedeutung:
# -all = Hardfail (alles andere ablehnen) – empfohlen für Sicherheit
# ~all = Softfail (markieren, nicht ablehnen) – empfohlen beim Testen
# +all = unsicher, niemals verwenden

Beachte das SPF-DNS-Lookup-Limit: Pro SPF-Record dürfen maximal 10 DNS-Lookups ausgelöst werden (include:, a, mx, ptr, exists). Wird das Limit überschritten, ist das Ergebnis PermError. Überprüfe den fertigen Record mit dem SPF-Check auf MXToolbox SuperTool.

Schritt 5: DMARC schrittweise aktivieren

Aktiviere DMARC niemals direkt mit p=reject, bevor SPF und DKIM stabil laufen. Die sichere Reihenfolge in drei Stufen:

# Schritt 5a – Monitoring-Modus (nichts wird blockiert, Reports kommen an)
# DNS-TXT-Record: _dmarc.example.com
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

# Schritt 5b – Quarantäne (nach 4 Wochen Report-Auswertung, 25 % der Mails)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

# Schritt 5c – Volle Ablehnung (nach weiteren 4 Wochen, wenn Reports sauber)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

DMARC-Aggregate-Reports brauchen 24–48 Stunden nach SPF/DKIM-Aktivierung, bevor aussagekräftige Daten sichtbar sind. Werte die Reports mit einem Tool wie dmarcian.com aus, bevor du zur nächsten Stufe wechselst. Für den initialen Umzug reicht p=none.

Schritt 6: Neue DNS-Zone aufbauen und testen – vor dem Cutover

Baue die vollständige Zone beim neuen DNS-Provider auf, bevor du die Nameserver beim Registrar umstellst. Du kannst den neuen Nameserver direkt befragen, ohne dass er bereits aktiv ist:

# Neuen Nameserver direkt befragen (ersetze ns1.neuerhosting.com entsprechend)
dig @ns1.neuerhosting.com +noall +answer example.com A
dig @ns1.neuerhosting.com +noall +answer example.com MX
dig @ns1.neuerhosting.com +noall +answer example.com TXT
dig @ns1.neuerhosting.com +noall +answer _dmarc.example.com TXT
dig @ns1.neuerhosting.com +noall +answer mail2025._domainkey.example.com TXT
dig @ns1.neuerhosting.com +noall +answer autoconfig.example.com A
dig @ns1.neuerhosting.com +noall +answer autodiscover.example.com A

Vergleiche jeden Wert mit deinem Inventardokument aus Schritt 2. Führe außerdem einen vollständigen Zone-Check auf intodns.com durch – dort siehst du fehlende Records und RFC-Verstöße auf einen Blick.

Schritt 7: DNSSEC prüfen und ggf. deaktivieren

Wenn DNSSEC auf deiner Domain aktiv ist, muss der DS-Record beim Registrar vor dem Nameserver-Wechsel gelöscht werden. Andernfalls können DNSSEC-validierende Resolver die Domain nach dem Wechsel komplett nicht auflösen – die Domain wird für einen Teil der Nutzer unerreichbar. Prüfe den Status:

# DNSSEC-Status prüfen
dig +dnssec example.com A
# Wenn im Answer-Abschnitt ein RRSIG-Record erscheint, ist DNSSEC aktiv

Ist DNSSEC aktiv: Lösche den DS-Record im Registrar-Panel, warte die TTL ab, dann erst die Nameserver umstellen. Nach erfolgreichem Wechsel kannst du DNSSEC beim neuen Provider wieder aktivieren.

Schritt 8: Cutover – Nameserver umstellen

Wenn alle vorherigen Schritte abgeschlossen sind und der Zone-Check am neuen Nameserver grünes Licht gibt, kannst du die Nameserver beim Registrar umstellen. Führe den Cutover im geplanten Wartungsfenster durch.

Cutover-Checkliste (vor dem Umstellen abhaken):

TTL aller Records seit mindestens 48 Stunden auf 300 s – und die Wartezeit ist abgelaufen
Neue DNS-Zone vollständig und per dig @neuer-ns verifiziert
DKIM-Selector des neuen Mailservers im DNS der neuen Zone eingetragen
Alter DKIM-Selector ebenfalls in der neuen Zone vorhanden
Genau ein SPF-TXT-Record in der neuen Zone
DMARC mit p=none in der neuen Zone eingetragen
autoconfig- und autodiscover-Records in der neuen Zone eingetragen
Alle Drittdienst-TXT-Records (Google, Microsoft, Stripe etc.) kopiert
DNSSEC deaktiviert (falls es vorher aktiv war)
Neuer Mailserver läuft und akzeptiert Mails (Telnet-Test erfolgreich)
Alter Server bleibt noch mindestens 48–72 Stunden aktiv

# E-Mail-Zustellung am neuen Server testen (vor Cutover)
# MX des neuen Servers direkt abfragen:
dig @ns1.neuerhosting.com +short example.com MX

# SMTP-Verbindungstest auf Port 25:
telnet mail.neuerhosting.com 25

# Mit TLS (Port 587):
openssl s_client -connect mail.neuerhosting.com:587 -starttls smtp

Schritt 9: Nach dem Cutover – Propagation beobachten und testen

Unmittelbar nach dem Nameserver-Wechsel solltest du aktiv prüfen, ob die neuen Records ankommen. Mit dem vorab gesenkten TTL sehen 80–90 % der Nutzer die Änderung innerhalb von 1–4 Stunden. Einzelne ISPs ignorieren TTL-Werte – das ist nicht steuerbar.

# Propagation prüfen – welcher Nameserver antwortet?
dig +short example.com NS
dig +short example.com A

# TTL-Countdown beobachten (3. Feld in der Antwort):
dig example.com A | grep -E 'IN\s+A'
# Beispiel-Ausgabe: example.com. 287 IN A 203.0.113.42

Sende nach dem Cutover Test-E-Mails an externe Konten (Gmail, Outlook.com, GMX) und prüfe die Mail-Header auf gültige DKIM-Signatur und SPF-Pass. Das Tool mail-tester.com bewertet SPF/DKIM/DMARC auf einer Skala von 1–10 und zeigt sofort, was noch fehlt.

Schritt 10: TTL nach erfolgreichem Cutover wieder anheben

Nach 48–72 Stunden stabilem Betrieb auf dem neuen Server hebe die TTL-Werte wieder auf normale Werte an, um die DNS-Last zu reduzieren:

; TTL wieder auf 3600 s (1 Stunde) anheben – in der Zonendatei oder im Provider-Panel
$TTL 3600
example.com.    IN A   203.0.113.42
example.com.    IN MX  10 mail.example.com.

Registrar-Wechsel: Getrennt vom DNS-Umzug planen

Registrar-Wechsel und DNS-Umzug sind zwei unabhängige Vorgänge. Es ist empfehlenswert, beide zeitlich zu trennen. Beim Registrar-Wechsel gilt:

ICANN 60-Tage-Sperre: Nach Domain-Registrierung, Registrar-Wechsel oder Änderung des Registrant-Kontakts ist die Domain 60 Tage für einen Transfer gesperrt (clientTransferProhibited). Diese Frist muss eingeplant werden.
EPP-Auth-Code: Der aktuelle Registrar muss den Code innerhalb von 5 Tagen nach Anfrage herausgeben. Der Transfer selbst dauert nochmals bis zu 5 Kalendertage. Frühzeitig anfragen.
Nameserver-Übernahme prüfen: Manche Registrare tragen beim Transfer automatisch ihre eigenen Nameserver ein und löschen die bisherigen. Sofort nach dem Transfer prüfen, welche Nameserver aktiv sind – sonst ist die sorgfältig konfigurierte DNS-Zone plötzlich inaktiv.

Troubleshooting / Typische Fehler

MX-TTL nicht gesenkt: Wurde nur der A-Record-TTL auf 300 s gesenkt, aber der MX-Record blieb bei 86400 s, landen E-Mails nach dem Cutover noch bis zu 24 Stunden beim alten Mailserver. A- und MX-Record haben unabhängige TTL-Werte.
Zwei SPF-Records auf der Domain: Hosting-Control-Panels legen beim neuen Hosting automatisch einen SPF-Record an. Existiert bereits einer vom alten Provider, gibt es zwei v=spf1-Einträge → sofort PermError laut RFC 7208. Auf einen einzigen Record konsolidieren.
DKIM-Selector fehlt nach Serverwechsel: Der neue Mailserver signiert mit einem Selector, der im DNS noch nicht steht. Alle ausgehenden Mails haben ungültige DKIM-Signatur, DMARC schlägt fehl, Mails landen im Spam – ohne Fehlermeldung für den Absender.
DNSSEC nicht deaktiviert: Nameserver-Wechsel mit aktivem DNSSEC ohne vorherigen DS-Record-Löschung macht die Domain für DNSSEC-validierende Resolver komplett unerreichbar.
Drittdienst-TXT-Records vergessen: Verifizierungs-Records für Google Search Console, Microsoft 365, Mailchimp, Stripe etc. müssen manuell kopiert werden. Dienste deaktivieren sonst die Domain-Verifizierung.
Negatives Caching: Fehlt ein Record beim Nameserver-Wechsel und wird nachträglich hinzugefügt, haben Resolver die negative Antwort (NXDOMAIN) bereits für den negativen TTL gecacht (SOA MINIMUM, typisch 300–3600 s). Der Record ist für diese Zeit unsichtbar.
autoconfig/autodiscover-Records fehlen: E-Mail-Clients können sich auf neuen Geräten nicht mehr automatisch einrichten, wenn diese CNAME/A-Records auf den alten Server zeigen oder ganz fehlen.
DMARC mit p=reject zu früh: Wird p=reject gesetzt, bevor alle Sendequellen (Newsletter-Tool, CRM, externer SMTP-Relay) in SPF und DKIM eingetragen sind, werden legitime E-Mails abgewiesen. Immer zuerst p=none und 4 Wochen Reports auswerten.

Häufige Fragen

Wie lange dauert DNS-Propagation wirklich?

Technisch können Änderungen bis zu 24–72 Stunden benötigen. Praktisch sehen 80–90 % der Nutzer die Änderung innerhalb von 1–4 Stunden, wenn der TTL vorher auf 300 s gesenkt wurde. Einzelne ISPs ignorieren TTL-Werte und cachen länger – das ist nicht steuerbar und kein Fehler auf deiner Seite.

Muss ich Registrar und DNS-Provider gleichzeitig wechseln?

Nein – und es ist ausdrücklich besser, beides zu trennen. Du kannst den DNS-Provider wechseln (Nameserver umstellen), ohne den Registrar zu wechseln, und umgekehrt. Empfehlung: DNS-Migration und Registrar-Transfer als separate Schritte mit zeitlichem Abstand durchführen, um Risiken zu minimieren.

Was ist der Unterschied zwischen Registrar-Transfer und DNS-Umzug?

Beim Registrar-Transfer wird die Verwaltungshoheit über die Domain (Vertragspartner, WHOIS, Auth-Code) zu einem neuen Anbieter verschoben. Der DNS-Umzug ändert, welche Nameserver die Zone verwalten und wo die Records gepflegt werden. Beides ist vollständig unabhängig voneinander.

Kann ich E-Mails während des Umzugs verlieren?

Bei korrekter Vorbereitung nein. Solange beide Mailserver gleichzeitig aktiv sind und der alte MX-Record noch gilt, werden E-Mails sicher zugestellt. Sendende Mailserver wiederholen fehlgeschlagene Zustellversuche typischerweise für 24–48 Stunden. Risiko besteht nur, wenn der alte Server vorzeitig abgeschaltet wird oder der MX-Record mit noch hohem TTL umgestellt wurde.

Wie teste ich, ob die neue DNS-Zone vollständig ist, bevor ich die Nameserver umstelle?

Mit dig @ns1.neuerhosting.com example.com MX und entsprechenden Abfragen für alle Record-Typen kannst du den neuen Nameserver direkt befragen, bevor er aktiv geschaltet wird. Zusätzlich helfen intodns.com und MXToolbox SuperTool für einen vollständigen Zone-Check.

Wie lange sollte der alte Server nach dem Cutover noch laufen?

Mindestens 24 Stunden, idealerweise 48–72 Stunden. Resolver können noch den alten A- oder MX-Record gecacht haben, und sendende Mailserver wiederholen Zustellversuche über mehrere Stunden. Erst nach Ablauf dieser Frist und nach aktiver Prüfung der Logs die alte Umgebung abschalten.

Was tun, wenn nach dem Cutover doch etwas nicht funktioniert (Rollback)?

Da der TTL noch auf 300 s steht, kannst du die Nameserver beim Registrar innerhalb weniger Minuten zurückstellen. Die alte DNS-Zone ist unverändert – der Rollback dauert damit nur 5–10 Minuten, bis 80 % der Resolver wieder die alten Records sehen. Genau deshalb darf der TTL erst nach mindestens 48 Stunden stabilem Betrieb wieder angehoben werden.

Fazit

Ein Domain-Umzug ohne Ausfall ist kein Zufall, sondern das Ergebnis einer klaren Reihenfolge: TTLs frühzeitig senken und die Wartezeit einhalten, alle Records lückenlos inventarisieren, den neuen DKIM-Selector parallel aufbauen, SPF auf genau einen Record konsolidieren, die neue Zone am neuen Nameserver testen – und erst dann den Schalter umlegen. Der größte Mehrwert dieser Reihenfolge liegt darin, dass der Rollback jederzeit möglich bleibt, solange der TTL niedrig ist. Wer DKIM, SPF und DMARC sauber mitnimmt, vermeidet nicht nur E-Mail-Ausfall, sondern schützt auch die Reputation der Absender-Domain langfristig.

Weiterführende Anleitungen und Quellen

DNS-Records erklärt: A, AAAA, CNAME, MX, TXT – Grundlagen aller Record-Typen, die beim Umzug relevant sind
SPF, DKIM und DMARC für Exchange Online / Microsoft 365 einrichten – wenn der Ziel-Mailserver Microsoft 365 ist
OpenDKIM und Postfix: DKIM-Signatur einrichten – DKIM-Konfiguration auf eigenem Linux-Mailserver
Mailcow Mailserver mit Docker aufsetzen – vollständiger Self-hosted-Mailserver inklusive DKIM/DMARC

Externe Quellen: DCHost: Domain and DNS Migration Checklist (dchost.com) · DMARCLY: How to Implement DMARC/DKIM/SPF – The Definitive Guide (dmarcly.com) · Microsoft Learn: Use DKIM for email in your custom domain (learn.microsoft.com)