Domain umziehen ohne E-Mail-Ausfall: DNS, MX, SPF, DKIM und DMARC

Das Domain Name System (DNS) übersetzt Namen in Adressen. Die Liste aller Einträge einer Domain heißt Zone, und die Nameserver geben sie an alle aus, die danach fragen. Der MX-Eintrag (Mail Exchanger) nennt den Server, der Post für Ihre Domain annimmt. Die übrige technische Grundlage einer Website beschreibt unser Leitfaden zu technischem SEO. Der Registrar ist der Anbieter, bei dem Ihre Domain registriert ist. Welcher Umzug ansteht, entscheidet über den Aufwand:

Ändert sich der Domainname selbst, gelten zusätzlich die Schritte aus dem Abschnitt Was gilt zusätzlich bei einem Wechsel der Domain? unserer Relaunch-Checkliste.

Kurze Störungen: Bei einem vorübergehenden DNS-Fehler legt ein sendender Mailserver die Nachricht in seine Warteschlange und versucht es später erneut. Der Standard RFC 5321 (externe Website) nennt als Abstand zwischen den Versuchen mindestens 30 Minuten und als Frist bis zum Aufgeben in der Regel mindestens vier bis fünf Tage. Eine kurze Störung verzögert die Post deshalb meist nur.

Fehlender Eintrag: Gibt es keinen MX-Eintrag, behandelt der sendende Server laut RFC 5321 die Adresse der Domain selbst als Mailserver. Das ist nach einem Umzug oft ein Webserver oder ein CDN, also ein Netz von Servern für die Auslieferung von Websites. Beide nehmen in der Regel keine Post an.

SPF (Sender Policy Framework) legt fest, welche Server Mails mit Ihrer Domain versenden dürfen. DKIM (DomainKeys Identified Mail) signiert jede Mail, den Schlüssel zum Prüfen finden Empfänger im DNS. DMARC (Domain-based Message Authentication, Reporting and Conformance) sagt Empfängern, wie sie mit Mails umgehen sollen, die keine dieser Prüfungen für Ihre Domain bestehen.

So gehen Sie vor:

1. Exportieren Sie die Zone, wenn Ihr Anbieter das anbietet. Sonst übertragen Sie die Einträge aus der Verwaltungsoberfläche von Hand.
2. Fragen Sie die alten Nameserver zusätzlich direkt ab. Welche das sind, zeigt dig +short NS ihre-domain.de. Das Werkzeug dig gibt es unter macOS und Linux. Unter Windows nutzen Sie in der PowerShell Resolve-DnsName ihre-domain.de -Type MX -Server alter-nameserver -DnsOnly.
3. Suchen Sie die DKIM-Selektoren. Ein Selektor ist der Teil des Namens, unter dem der öffentliche Schlüssel im DNS steht (RFC 6376 (externe Website)). Senden Sie sich eine Mail und lesen Sie im Quelltext den Wert s= der Kopfzeile DKIM-Signature (externe Website). Bei Microsoft 365 heißen die Selektoren selector1 und selector2 (externe Website), bei Google Workspace standardmäßig google. Prüfen Sie jeden Dienst, der in Ihrem Namen sendet, etwa ein Newsletter-Werkzeug, mit einer eigenen Mail.
4. Notieren Sie Dienste, die sich über das DNS bestätigt haben. Die Search Console prüft regelmäßig, ob ihr Bestätigungscode noch vorhanden ist (externe Website), und entzieht die Berechtigung nach einer Kulanzzeit, wenn er fehlt.

dig +short NS ihre-domain.de
dig +short MX ihre-domain.de @nameserver
dig +short TXT ihre-domain.de @nameserver
dig +short TXT _dmarc.ihre-domain.de @nameserver
dig +short TXT selektor._domainkey.ihre-domain.de @nameserver
dig +short CNAME selektor._domainkey.ihre-domain.de @nameserver
dig +short CAA ihre-domain.de @nameserver

Typischer Fehler: Die DKIM-Selektoren fehlen in der Liste. Anders als MX und SPF stehen sie unter einem eigenen Namen, und den kennt nur, wer eine Mail untersucht hat.

Erledigt, wenn eine datierte Liste aller Einträge vorliegt und jeder Dienst, der in Ihrem Namen Mails sendet, mit seinem Selektor darin steht.

So gehen Sie vor:

1. Legen Sie die Zone an und tragen Sie jeden Eintrag Ihrer Liste ein. Manche Anbieter ergänzen beim Anlegen eigene Standardeinträge. Prüfen Sie deshalb auch, was Sie nicht selbst eingetragen haben.
2. Lassen Sie die Einträge der Website auf das bisherige Ziel zeigen. So bleibt der Wechsel der Nameserver für Besucher unsichtbar.
3. Übernehmen Sie DKIM so, wie Ihr Mailanbieter es vorgibt. STRATO (externe Website) und Microsoft nennen dafür CNAME-Einträge. Bei Microsoft wechselt der Anbieter die Schlüssel dann selbst. STRATO kann laut Hilfe gelegentlich auf neue Selektoren umstellen. Prüfen Sie deshalb regelmäßig den Selektor Ihrer Mails und tragen Sie jeden neuen Selektor als weiteren CNAME-Eintrag ein.

Regeln, an denen Zonen scheitern:

• Genau ein SPF-Eintrag. Laut RFC 7208 (externe Website) führen zwei Einträge mit v=spf1 zu einem dauerhaften Fehler. Derselbe Standard erlaubt je Prüfung höchstens zehn Bausteine, die DNS-Abfragen auslösen, etwa include, a und mx.
• Vorsicht mit a im SPF. Dieser Baustein erlaubt die Adressen, auf die der Domainname zeigt. Zieht die Website um, ändert sich damit auch, wer senden darf. Versendet Ihr Webserver selbst Mails, etwa aus einem Kontaktformular, tragen Sie ihn ausdrücklich ein.
• Kein CNAME an der Domain selbst. Ein CNAME leitet einen Namen auf einen anderen um. Laut RFC 1034 (externe Website) darf neben ihm kein anderer Eintrag stehen. An der Domain stehen aber immer die Nameserver und meist MX und TXT. Anbieter wie Bunny lösen das mit CNAME-Flattening (externe Website) und antworten nach außen mit Adressen.
• MX zeigt nie auf einen CNAME. Das schreibt RFC 2181 (externe Website) vor. Steht das Ziel in Ihrer eigenen Domain, etwa mail.ihre-domain.de, gehört dessen A-Eintrag mit in die Zone.

Zur TTL (Time to Live): Sie sagt, wie lange Resolver, also die Server, die Namen für Programme und Geräte auflösen, eine Antwort speichern dürfen. Google rät, sie für einen Umzug mindestens eine Woche vorher zu senken (externe Website). Sind die Mail-Einträge in alter und neuer Zone gleich, hängt die Zustellung nicht daran. Für die spätere Umstellung der Website zählt die TTL trotzdem.

Typischer Fehler: Für einen weiteren Absender entsteht ein zweiter SPF-Eintrag. Beide zusammen sind ungültig. Ergänzen Sie neue Absender im vorhandenen Eintrag.

Erledigt, wenn die neue Zone jeden Eintrag Ihrer Liste enthält, genau ein SPF-Eintrag darin steht und die Website noch auf ihr altes Ziel zeigt.

So gehen Sie vor:

1. Wiederholen Sie die Abfragen aus dem Abschnitt Welche DNS-Einträge müssen Sie vor dem Umzug sichern? mit @ und dem neuen Nameserver. Fragen Sie jeden neuen Nameserver einzeln.
2. Vergleichen Sie jede Antwort mit Ihrer Liste. Die Reihenfolge mehrerer Antworten kann wechseln.
3. Bleibt die Ausgabe leer, wiederholen Sie die Abfrage ohne +short. Dann zeigt dig auch die Angaben aus dem Kopf der Antwort, darunter den Antwortcode. REFUSED heißt, dass der Server diese Zone nicht ausliefert. NXDOMAIN oder NOERROR ohne Antwort heißt, dass der Eintrag fehlt.

Typischer Fehler: Die Abfrage läuft ohne @ über den eigenen Resolver. Dann antwortet die alte Zone, und das Ergebnis sieht fehlerfrei aus, obwohl die neue Zone noch Lücken hat.

Erledigt, wenn jeder neue Nameserver für jeden Eintrag die erwartete Antwort liefert.

Was DENIC verlangt: DENIC verwaltet als Registry alle .de-Domains, und die Delegation legt fest, welche Nameserver für eine Domain zuständig sind. Vor einer Änderung testet DENIC laut seinem Nameserver Predelegation Check (externe Website) die neuen Nameserver. Jeder muss erreichbar sein und für die Zone verbindlich antworten, es müssen mindestens zwei sein, und ihre NS-Einträge müssen exakt der Liste im Auftrag entsprechen. An der Domain selbst darf kein CNAME stehen. Deshalb muss die neue Zone fertig sein, bevor Sie den Auftrag abschicken.

DNSSEC: Dieses Verfahren signiert DNS-Antworten. Ist Ihre Domain signiert, steht in der übergeordneten Zone, bei .de-Domains also bei DENIC, ein DS-Eintrag. Passt er nicht zur neuen Zone, gilt die Antwort für prüfende Resolver laut RFC 4033 (externe Website) als ungültig. Klären Sie die Reihenfolge vorher mit beiden Anbietern. Ob Ihre Domain signiert ist, zeigt dig +short DS ihre-domain.de. Bleibt die Ausgabe leer, ist sie es nicht.

So gehen Sie vor:

1. Prüfen Sie die Regeln Ihres Anbieters. Bei STRATO lässt sich der NS-Eintrag laut Hilfe nicht bearbeiten, solange ein eigener MX-, A- oder SPF-Eintrag gesetzt ist. Setzen Sie diese Einträge dafür zurück, lassen sie sich laut STRATO nur durch erneutes Eintragen wiederherstellen. Ihre Liste muss also vorher stehen.
2. Tragen Sie alle neuen Nameserver ein.
3. Prüfen Sie bei der Registry, ob die Delegation angekommen ist: dig +noall +authority NS ihre-domain.de @a.nic.de. Unter Windows zeigt nslookup -type=NS ihre-domain.de a.nic.de dasselbe. Für andere Endungen als .de nutzen Sie dig +trace NS ihre-domain.com.
4. Kündigen Sie den alten DNS-Dienst noch nicht. Bei unserer Abfrage nannte DENIC für die Delegation von datafalke.de eine TTL von einem Tag, so lange können Resolver sie speichern. Verlassen Sie sich trotzdem nicht darauf, dass die alten Nameserver weiter antworten: Unsere lehnten Anfragen nach dem Wechsel ab.

Typischer Fehler: Der Wechsel gilt als erledigt, sobald der Anbieter ihn bestätigt. Bei uns nannte DENIC mehr als anderthalb Stunden nach der Bestätigung noch die alten Nameserver.

Erledigt, wenn die Registry die neuen Nameserver nennt.

Warum: Gmail verlangt von allen Absendern SPF oder DKIM (externe Website) und von Absendern mit mehr als 5.000 Nachrichten am Tag an Gmail-Konten SPF, DKIM und DMARC. DMARC besteht laut RFC 9989 (externe Website), wenn eine der beiden Prüfungen für Ihre Domain gelingt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) beschreibt die Anforderungen an Mailanbieter in seiner Richtlinie TR-03182 (externe Website). Die Kopfzeile Authentication-Results (externe Website) zeigt das Ergebnis der Prüfungen beim Empfänger.

So gehen Sie vor:

1. Fragen Sie die Einträge über zwei öffentliche Resolver ab, etwa mit @8.8.8.8 und @1.1.1.1. Beide sollten dieselben Werte liefern wie Ihre Liste.
2. Schicken Sie eine Mail von Ihrer Adresse an ein Konto bei einem anderen Anbieter. Öffnen Sie dort den Quelltext der Nachricht und lesen Sie die Zeile Authentication-Results.
3. Antworten Sie von diesem Konto. Die Antwort muss in Ihrem Postfach ankommen.
4. Wiederholen Sie beide Tests am nächsten Tag. Bis dahin können Resolver noch die alte Delegation nutzen.
5. Lesen Sie die Berichte an die Adresse im Wert rua Ihres DMARC-Eintrags. Dort sehen Sie, welche Server in Ihrem Namen senden.

Einen Rückweg festlegen: Bestimmen Sie vor dem Wechsel, ab wann Sie zurückwechseln, etwa wenn die Mail nach einer Stunde noch nicht ankommt. Auch der Rückweg führt über die Delegation und braucht deshalb ähnlich lange wie der Hinweg.

Typischer Fehler: Die Testmail geht an ein Postfach beim selben Anbieter. Dann bleibt sie womöglich intern, und MX und SPF kommen gar nicht zum Einsatz.

Nachgetragene Einträge: Resolver speichern auch die Antwort, dass ein Eintrag fehlt. Laut RFC 2308 (externe Website) gilt dafür der kleinere Wert aus der TTL und dem Feld MINIMUM des SOA-Eintrags der Zone. Bei unserer Zone sind das 15 Minuten.

Erledigt, wenn beide Testmails angekommen sind und die empfangene Mail bei SPF, DKIM und DMARC jeweils pass zeigt.

Ändern sich dabei Adressen oder der Hoster, gelten die Schritte für den Tag der Umstellung in der Relaunch-Checkliste. Die Grundlagen zu Weiterleitungen und Statuscodes erklärt unser Leitfaden Technisches SEO.

Zu CAA: Der CAA-Eintrag (Certification Authority Authorization) legt fest, wer Zertifikate für Ihre Domain ausstellen darf. Nennt er nur andere Stellen als die Ihres neuen Hosters, darf die Stelle des Hosters laut RFC 8659 (externe Website) kein Zertifikat ausstellen. Prüfen Sie den Wert vorher. Für Let’s Encrypt lautet er (externe Website) issue "letsencrypt.org".

Typischer Fehler: Website und Nameserver wechseln im selben Schritt. Schlägt danach etwas fehl, lässt sich kaum erkennen, ob es an der Zone, am Hoster oder am Zertifikat liegt.

Erledigt, wenn die Website über http, https und www auf die neue Adresse führt, das Zertifikat gültig ist und die Mail weiter ankommt.

Für Microsoft 365 nennt Microsoft diese Reihenfolge (externe Website): erst Postfächer anlegen, dann den MX-Eintrag ändern. Ab der Änderung läuft neue Post beim neuen Anbieter ein.

1. Legen Sie alle Postfächer und Weiterleitungen beim neuen Anbieter an.
2. Senken Sie die TTL des MX-Eintrags rechtzeitig. Eine gesenkte TTL wirkt erst, wenn die alte abgelaufen ist.
3. Nehmen Sie den neuen Absender in den vorhandenen SPF-Eintrag auf und richten Sie DKIM beim neuen Anbieter ein. Den alten Absender entfernen Sie, wenn über ihn nichts mehr gesendet wird.
4. Stellen Sie den MX-Eintrag um und testen Sie mit Mails in beide Richtungen.
5. Übertragen Sie vorhandene Mails und prüfen Sie Adressbücher und Kalender.

Steht Ihr DMARC-Eintrag auf p=reject, prüfen Sie den neuen Absender vor dem Umstellen mit einer Testmail. Besteht sie weder SPF noch DKIM für Ihre Domain, können Empfänger die Post abweisen.