Beim Domain-Umzug fällt meist nicht die Website aus, sondern die E-Mail: Der MX-Record wurde mit hohem TTL umgestellt, der DKIM-Selector fehlt auf dem neuen Server, oder die Domain hat plötzlich zwei SPF-Einträge. Diese Anleitung zeigt die Reihenfolge für einen Umzug ohne Unterbrechung, bis zum Abschalten der alten Umgebung.

Voraussetzungen

Bearbeitungsrechte beim alten und beim neuen DNS-Provider sowie Zugang zum Registrar (Nameserver-Wechsel, Auth-Code)
Zonen-Export der aktuellen Zone aus dem Provider-Panel
Neuer Mailserver betriebsbereit, mit DKIM-Schlüssel und Zugangsdaten (SMTP/IMAP) für Tests
Wartungsfenster außerhalb der Geschäftszeit, 48 Stunden Vorlauf und 72 Stunden Parallelbetrieb
dig (Linux/macOS, Paket dnsutils bzw. bind-utils) oder nslookup (Windows)

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

Steht ein Record heute auf 86400 Sekunden, gilt die neue TTL erst 24 Stunden nach der Änderung überall. Senken Sie alle Records, besonders den MX-Record.

Setzen Sie in der aktuellen Zone folgende TTL-Werte auf 300 Sekunden:

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 = bis 24 h Mail beim alten Server
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

Die TTL der NS-Delegation legt die TLD-Registry fest, Sie können sie nicht senken: für .de 86400 Sekunden, für .com 172800 Sekunden (dig +norec @a.nic.de denic.de NS). Die alte Zone muss nach dem Nameserver-Wechsel deshalb noch mindestens zwei Tage korrekt antworten.

Verifizieren: dig +noall +answer @ALTER-NAMESERVER example.com MX zeigt in der zweiten Spalte 300. Wiederholen Sie die Abfrage für A, AAAA und TXT.

Schritt 2: Vollständige DNS-Zone inventarisieren

Vor dem Cutover müssen Sie jeden Record kennen. TXT-Records für Drittdienste (Google Search Console, Microsoft 365, Newsletter-Tools) werden leicht übersehen. dig findet nur Namen, die Sie kennen; nutzen Sie zusätzlich den Zonen-Export des alten Providers.

# Alle relevanten Record-Typen der Domain abfragen
for t in A AAAA MX TXT NS SOA CAA; do dig +noall +answer example.com $t; done

# DMARC und DKIM-Selektoren (Selector-Namen im Mailserver bzw. in Mail-Headern: s=...)
dig +noall +answer _dmarc.example.com TXT
dig +noall +answer mail._domainkey.example.com TXT

# Subdomains, u. a. Autokonfiguration für Mail-Clients
for n in www mail autoconfig autodiscover; do dig +noall +answer $n.example.com A; done

Unter Windows ohne dig nutzen Sie nslookup:

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

Tragen Sie alle Records in eine Tabelle ein, sie dient auch als Rollback-Grundlage. Record-Typen erklärt die Anleitung DNS-Records erklärt: A, AAAA, CNAME, MX, TXT.

Verifizieren: Jeder Eintrag aus dem Provider-Export steht in Ihrer Tabelle, und jede Subdomain aus der Tabelle liefert per dig eine Antwort.

Schritt 3: DKIM für den neuen Mailserver vorbereiten

Häufigster stiller Fehler: Der neue Server signiert mit einem Selector, der im DNS fehlt. DKIM und damit DMARC schlagen fehl, Mails landen ohne Fehlermeldung im Spam. Veröffentlichen Sie den neuen Selector deshalb zuerst im DNS und betreiben Sie ihn parallel zum alten. Microsoft 365 und mailcow erzeugen den Schlüssel selbst; die Befehle brauchen Sie nur bei eigenem Postfix/OpenDKIM.

# DKIM-Schlüsselpaar erzeugen (RSA 2048 Bit)
openssl genrsa -out dkim_private.key 2048
openssl rsa -in dkim_private.key -pubout -out dkim_public.key

# Öffentlichen Schlüssel als eine Zeile für den TXT-Record ausgeben
grep -v -- '-----' dkim_public.key | tr -d '\n'

Tragen Sie den Schlüssel unter einem neuen Selector-Namen (z. B. mail2026) in die neue Zone ein, damit alter und neuer Selector gleichzeitig existieren:

# TXT-Record mail2026._domainkey.example.com
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...[base64-public-key]...

Der alte Selector bleibt ein bis zwei Wochen in der Zone, für noch unterwegs befindliche Mails. Für eigene Linux-Server siehe OpenDKIM und Postfix: DKIM-Signatur einrichten.

Verifizieren: dig +short @NEUER-NAMESERVER mail2026._domainkey.example.com TXT liefert den Record mit v=DKIM1 und demselben Schlüssel, den der Mailserver anzeigt.

Schritt 4: SPF-Record konsolidieren

Es darf genau einen SPF-TXT-Record pro Domain geben. Panels legen oft einen zweiten an. Zwei v=spf1-Einträge ergeben laut RFC 7208, Abschnitt 4.5, das Ergebnis permerror; viele Empfänger behandeln die Mails dann als nicht authentifiziert oder weisen sie ab.

# Genau ein SPF-Record auf der Domain, z. B. eigener Server + Google Workspace
v=spf1 ip4:203.0.113.42 include:_spf.google.com ~all

# -all = Hardfail (Ziel), ~all = Softfail (Übergang), +all nie verwenden

Beachten Sie das Limit von 10 DNS-Lookups pro SPF-Prüfung (include, a, mx, ptr, exists, redirect); darüber lautet das Ergebnis ebenfalls permerror. Prüfen Sie den Record mit dem SPF-Check im MXToolbox SuperTool.

Verifizieren: dig +short @NEUER-NAMESERVER example.com TXT | grep -c spf1 gibt genau 1 aus, der SPF-Check meldet keine Fehler.

Schritt 5: DMARC schrittweise aktivieren

Setzen Sie p=reject erst, wenn SPF und DKIM stabil laufen. Die Reihenfolge in drei Stufen:

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

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

# 5c: nach weiteren 4 Wochen ohne Auffälligkeiten
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Werten Sie die täglichen Reports (z. B. mit dmarcian.com) vor jeder Stufe aus. Für den Umzug selbst reicht p=none; eine bestehende strengere Policy übernehmen Sie unverändert.

Verifizieren: dig +short @NEUER-NAMESERVER _dmarc.example.com TXT liefert genau einen Record, der mit v=DMARC1 beginnt. Nach ein bis zwei Tagen treffen die ersten Reports an der rua-Adresse ein.

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

Bauen Sie die Zone beim neuen Provider vollständig auf und befragen Sie dessen Nameserver direkt:

# Neuen Nameserver direkt befragen (ns1.neuerhosting.com anpassen)
NS=ns1.neuerhosting.com
for t in A AAAA MX TXT; do dig @$NS +noall +answer example.com $t; done
dig @$NS +noall +answer _dmarc.example.com TXT
dig @$NS +noall +answer mail2026._domainkey.example.com TXT
for n in www mail autoconfig autodiscover; do dig @$NS +noall +answer $n.example.com A; done

Vergleichen Sie jeden Wert mit Ihrer Tabelle. intodns.com prüft nur die delegierte Zone, also erst nach dem Cutover.

Verifizieren: Jede Abfrage am neuen Nameserver liefert denselben Wert wie Ihre Tabelle (außer bewusst geänderten IPs und dem neuen DKIM-Selector). Keine Abfrage endet mit NXDOMAIN oder leerer Antwort.

Schritt 7: DNSSEC prüfen und ggf. deaktivieren

Ist DNSSEC aktiv, muss der DS-Record vor dem Nameserver-Wechsel entfernt werden (außer bei einem abgestimmten Schlüsseltransfer zwischen den Providern), sonst lösen validierende Resolver die Domain nicht mehr auf:

# DNSSEC-Status prüfen: Gibt es einen DS-Record bei der TLD?
dig +short example.com DS
# Ausgabe vorhanden = DNSSEC aktiv, leer = nicht aktiv

Ist DNSSEC aktiv: Entfernen Sie den DS-Record im Registrar-Panel, warten Sie dessen TTL ab (zweite Spalte von dig +noall +answer example.com DS) und stellen Sie erst dann die Nameserver um. Nach dem Wechsel aktivieren Sie DNSSEC beim neuen Provider wieder.

Verifizieren: dig +short example.com DS liefert eine leere Ausgabe, und die TTL des gelöschten DS-Records ist abgelaufen.

Schritt 8: Cutover – Nameserver umstellen

Stellen Sie die Nameserver im Wartungsfenster beim Registrar um, wenn diese Liste erfüllt ist:

TTL aller Records auf 300 s, die alte TTL ist seitdem abgelaufen
Neue Zone vollständig und per dig @NEUER-NAMESERVER geprüft (alter und neuer DKIM-Selector, ein SPF-Record, DMARC, Autokonfiguration, Drittdienst-TXT)
DNSSEC deaktiviert (falls es vorher aktiv war)
Neuer Mailserver nimmt Mails an (Test unten)
Alter Server und alte Zone bleiben mindestens 48 bis 72 Stunden aktiv

# Neuen Mailserver vor dem Cutover testen (Port 25 ist an vielen
# Internetanschlüssen ausgehend gesperrt, dann von einem Server aus testen)
telnet mail.neuerhosting.com 25
openssl s_client -connect mail.neuerhosting.com:587 -starttls smtp

Verifizieren: Im Registrar-Panel stehen die neuen Nameserver. dig +short example.com NS @a.nic.de (für .de) zeigt nach wenigen Minuten die neuen Nameserver.

Schritt 9: Nach dem Cutover – Propagation beobachten und testen

Resolver mit gespeicherter alter NS-Delegation fragen bis zu 24 (.de) bzw. 48 Stunden (.com) weiter die alten Nameserver. Tragen Sie die neuen IPs und den neuen MX deshalb auch in der alten Zone ein, damit beide Zonen gleich antworten.

# Welche Nameserver und welche IP sieht Ihr Resolver?
dig +short example.com NS
dig +noall +answer example.com A
# Beispiel: example.com. 287 IN A 203.0.113.42 (zweite Spalte = Rest-TTL)

Senden Sie Testmails an externe Postfächer (z. B. Gmail, Outlook.com, GMX). mail-tester.com bewertet SPF, DKIM und DMARC und zeigt, was fehlt.

Verifizieren: Im Header der Testmails steht spf=pass, dkim=pass mit dem neuen Selector und dmarc=pass. Antworten an die Domain kommen im neuen Postfach an.

Schritt 10: TTL nach erfolgreichem Cutover wieder anheben

Nach 48 bis 72 Stunden stabilem Betrieb heben Sie die TTL wieder an. Danach dauert ein Rollback wieder entsprechend länger.

; TTL auf 3600 s anheben (Zonendatei oder Provider-Panel)
$TTL 3600
example.com.    IN A   203.0.113.42
example.com.    IN MX  10 mail.example.com.

Verifizieren: dig +noall +answer @NEUER-NAMESERVER example.com MX zeigt 3600 in der zweiten Spalte. Erst jetzt schalten Sie Mailserver und Zone beim alten Anbieter ab.

Registrar-Wechsel: Getrennt vom DNS-Umzug planen

Registrar-Wechsel und DNS-Umzug sind unabhängige Vorgänge. Trennen Sie beide zeitlich:

Transfersperre (gTLDs wie .com): Nach der ICANN-Transfer-Policy kann eine Domain in den ersten 60 Tagen nach Registrierung oder Registrar-Wechsel gesperrt sein. ICANN überarbeitet diese Fristen derzeit, fragen Sie den aktuellen Stand beim Registrar ab.
Auth-Code: Bei gTLDs muss der bisherige Registrar den Code innerhalb von 5 Kalendertagen herausgeben. Fordern Sie ihn frühzeitig an.
Nameserver nach dem Transfer prüfen: Manche Registrare setzen dabei eigene Nameserver. Prüfen Sie danach dig +short example.com NS.

Troubleshooting / Typische Fehler

MX-TTL nicht gesenkt: Mails landen bis zu 24 Stunden beim alten Server; lassen Sie ihn so lange annehmen.
Zwei SPF-Records auf der Domain: Ergebnis permerror (siehe Schritt 4). Auf einen Record zusammenführen.
DKIM-Selector fehlt nach Serverwechsel: Mails landen im Spam (siehe Schritt 3). Header einer Testmail prüfen: dkim=fail oder dkim=neutral.
DNSSEC nicht deaktiviert: Resolver liefern SERVFAIL. DS-Record sofort entfernen.
Drittdienst-TXT-Records vergessen: Dienste verlieren die Domain-Bestätigung. Nachtragen.
Negatives Caching: Ein nachgetragener Record bleibt für die negative TTL (SOA MINIMUM, typisch 300 bis 3600 s) unsichtbar.
autoconfig/autodiscover-Records fehlen: Mail-Clients richten sich auf neuen Geräten nicht mehr automatisch ein.
DMARC mit p=reject zu früh: Legitime Mails nicht erfasster Sendequellen (Newsletter, CRM) werden abgewiesen. Zurück auf p=none.

Häufige Fragen

Wie lange dauert DNS-Propagation wirklich?

Records gelten nach Ablauf ihrer TTL. Ein Nameserver-Wechsel wirkt erst nach Ablauf der NS-Delegation (.de bis 24, .com bis 48 Stunden).

Müssen Sie Registrar und DNS-Provider gleichzeitig wechseln?

Nein. Führen Sie DNS-Umzug und Registrar-Transfer als getrennte Schritte mit zeitlichem Abstand durch.

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

Der Transfer wechselt den Vertragspartner für die Domain, der DNS-Umzug die Nameserver, die die Zone ausliefern.

Können E-Mails während des Umzugs verloren gehen?

Bei korrekter Vorbereitung nein. Solange beide Mailserver annehmen, kommen Mails an. Mails aus dem alten Postfach übertragen Sie per IMAP (z. B. imapsync).

Wie testen Sie die neue DNS-Zone, bevor Sie die Nameserver umstellen?

Durch direkte Abfragen am neuen Nameserver, siehe Schritt 6.

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

Mindestens 48, besser 72 Stunden (NS-Delegation). Abschalten erst, wenn die Logs keine Zugriffe und keine Mails mehr zeigen.

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

Stellen Sie die betroffenen Records in beiden Zonen auf die alten Werte zurück; bei 300 s TTL wirkt das nach Minuten, ein Nameserver-Rückwechsel bräuchte bis zu 48 Stunden.

Fazit

Entscheidend sind die Reihenfolge und der Parallelbetrieb: Die neue Zone ist vor dem Wechsel vollständig geprüft, die alte antwortet danach noch mindestens 48 Stunden. Solange die TTL niedrig ist, bleibt ein Rollback in Minuten möglich.

Weiterführende Anleitungen und Quellen

Externe Quellen: RFC 7208 (SPF) · RFC 7489 (DMARC) · ICANN Transfer Policy · Microsoft Learn: Use DKIM for email in your custom domain (learn.microsoft.com)