Ihre Domain mit einem externen Dienst verbinden

Ihre Domain auf einen externen Dienst zu richten – einen Homepage-Baukasten oder einen externen E-Mail-Anbieter – heißt normalerweise: Einträge bei Ihrem bestehenden DNS-Anbieter ändern. Es heißt meist nicht, die Domain zu übertragen oder ihre Nameserver zu wechseln: Wer die Nameserver ersetzt, obwohl nur ein Eintrag nötig war, kann den Rest einer funktionierenden Zone auslöschen – E-Mail- und Verifizierungseinträge eingeschlossen –, sofern nicht vorher alles beim neuen Anbieter nachgebaut wurde. Das DNS Ihrer Domain ist die Schaltzentrale: Website-Verkehr folgt A- (IPv4) und AAAA-Einträgen (IPv6), manchmal über einen CNAME-Alias; E-Mail folgt MX-Einträgen; TXT-Einträge beweisen Eigentum und autorisieren Absender. Der Anbieter gibt Ihnen die Werte; Sie tragen sie dort ein, wo Ihr DNS verwaltet wird – und das ist nicht immer der Registrar.

Die Adressen und Hostnamen unten verwenden reservierte Dokumentationsbereiche (192.0.2.0/24, 2001:db8::/32, example.com) als Platzhalter. Kopieren Sie sie nie wörtlich – nehmen Sie die aktuellen Werte immer aus dem Einrichtungsbildschirm Ihres Anbieters, denn sie unterscheiden sich je Anbieter und ändern sich mit der Zeit.

Sichern, bevor Sie irgendetwas ändern

Exportieren Sie die aktuelle DNS-Zone oder machen Sie einen klaren Screenshot jedes vorhandenen Eintrags, bevor Sie etwas anfassen. Ändern Sie nur die Einträge, die der neue Dienst braucht – löschen Sie keine fremden MX-, TXT-, CAA-, Verifizierungs- oder Subdomain-Einträge, denn die gehören zu Dingen, die noch funktionieren. Halten Sie die alten Werte und den alten Dienst verfügbar, bis die neue Konfiguration getestet ist: So wird aus einer misslungenen Umstellung eine Zwei-Minuten-Wiederherstellung statt eines Ausfalls.

Einen Homepage-Baukasten anbinden

Homepage-Baukästen hosten Ihre Seiten auf eigenen Servern und geben Ihnen Adressen, auf die Sie zeigen sollen. Der Haken ist der Unterschied zwischen Ihrem Apex (der nackten yourdomain.tld) und der www-Subdomain.

# Apex → IPv4 address supplied by the service
yourdomain.tld.       A      192.0.2.1

# Apex → IPv6 address — only if the service supplies one
yourdomain.tld.       AAAA   2001:db8::1

# www → hostname supplied by the service
www.yourdomain.tld.   CNAME  target.example.com.

Viele Website-Dienste nutzen dieses Muster – ein oder mehrere A/AAAA-Einträge am Apex und ein CNAME für www –, andere ergänzen Verifizierungseinträge, anbieterspezifische Aliase oder eine ganz andere Anordnung. Kopieren Sie den kompletten, aktuellen Eintragssatz aus dem Einrichtungsbildschirm des Dienstes selbst, nicht aus einer Anleitung.

Eine Warnung zur Schreibweise: Die Beispiele oben sind im Zonendatei-Stil. DNS-Panels beschriften anders – der Apex kann als @, als volle Domain oder als leeres Namensfeld erscheinen, und manche Panels hängen Ihre Domain (und den Schlusspunkt) automatisch an. Tippen Sie www.yourdomain.tld in so ein Panel, haben Sie gerade www.yourdomain.tld.yourdomain.tld angelegt. Halten Sie sich an das Format, das Ihr Panel erwartet.

Die Apex-CNAME-Einschränkung

Auf den Apex können Sie keinen CNAME setzen – das DNS verbietet, dass er neben den dort verpflichtenden SOA- und NS-Einträgen existiert. Sagt ein Dienst also „setzen Sie einen CNAME von Ihrer Root-Domain auf uns“, schauen Sie, was Ihr DNS-Anbieter wirklich bietet:

• ALIAS, ANAME oder CNAME-Flattening – anbieterspezifische Funktionen, die sich wie ein Apex-CNAME verhalten: Sie lösen das Ziel auf und antworten mit dessen Adressen. Namen, Verfügbarkeit und Verhalten unterscheiden sich je DNS-Host; keine davon ist ein Standard-Eintragstyp.
• A/AAAA-Einträge mit den Adressen, die der Dienst veröffentlicht – einfach, aber es bricht, wenn der Dienst seine IPs ändert.
• www zum primären Hostnamen machen und den Apex dorthin weiterleiten – das umgeht die Einschränkung komplett.

Wofür Sie sich auch entscheiden: Der externe Dienst und Ihr DNS-Anbieter müssen dieselbe Lösung unterstützen.

Externe E-Mail anbinden

Das E-Mail-Routing steuern MX-Einträge, plus TXT-Einträge für die Authentifizierung:

# MX — where mail is delivered
yourdomain.tld.  MX  1   mx.example.com.

# SPF — authorizes the provider to send as you
yourdomain.tld.  TXT  "v=spf1 include:_spf.example.com ~all"

# DKIM — signs your outgoing mail (selector and key come from the provider)
selector._domainkey.yourdomain.tld.  TXT  "v=DKIM1; k=rsa; p=MIGf..."

# DMARC — start in monitoring mode; tighten once reports look clean
_dmarc.yourdomain.tld.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

E-Mail umzuziehen ist eine Migration, kein Eintragstausch:

• Legen Sie zuerst jedes Postfach beim neuen Anbieter an und testen Sie es. Ändern Sie dann die MX-Einträge – und lassen Sie das alte System weiter Mail annehmen, während zwischengespeicherte Antworten ablaufen: In diesem Fenster können Nachrichten legitim bei beiden Anbietern eintreffen. Machen Sie danach einen letzten Abgleich, und schließen Sie den alten Dienst erst, wenn Mail durchgängig beim neuen ankommt.
• Vergessen Sie die Maschinen nicht. Auch Kontaktformulare der Website, Rechnungssysteme, Scanner und Newsletter-Tools verschicken Mail – die Mitarbeiter-Postfächer zu migrieren stellt keines davon um.
• Ein SPF-Eintrag, sauber geprüft. Eine Domain darf genau einen SPF-Eintrag veröffentlichen. Bevor Sie Ihren ersetzen, listen Sie jedes System auf, das legitim Mail für die Domain versendet – neuer Anbieter, Formulare, Rechnungen, Newsletter –, führen Sie dann nur die noch nötigen Mechanismen zusammen, werfen Sie veraltete Absender raus und bleiben Sie unter der SPF-Grenze von zehn DNS-Lookups. (SPF autorisiert die Domain im SMTP-Envelope; erst DMARC verknüpft die authentifizierte Domain mit der sichtbaren Absenderadresse.)
• DMARC ist Ihre Richtlinie, nicht nur ein weiterer Wert vom Anbieter. Starten Sie mit p=none – reines Beobachten, mit Berichten an eine Adresse, die wirklich existiert, oder an einen Auswertungsdienst – und gehen Sie erst auf quarantine oder reject, wenn die Berichte zeigen, dass Ihre gesamte legitime Mail eine ausgerichtete SPF- oder DKIM-Prüfung besteht.

TTL senken, dann umstellen

Die TTL (Time to Live) bestimmt, wie lange Resolver einen Eintrag zwischenspeichern dürfen. Wo Ihr DNS-Anbieter es erlaubt – und der externe Dienst nichts anderes vorgibt –, senken Sie die TTL der Einträge, die Sie ändern werden, auf 300–600 Sekunden oder den niedrigsten sinnvollen Wert im Angebot, und zwar mindestens eine alte TTL-Periode vor der Umstellung: Ein Eintrag mit Tages-TTL braucht seinen niedrigeren Wert mehr als einen Tag vorher. Nach der Änderung aktualisieren sich die meisten Caches innerhalb der neuen TTL, während ältere Antworten auslaufen – einzelne Resolver mit veralteten Daten können hinterherhinken –, und sobald die Migration stabil ist, stellen Sie die TTL wieder auf einen normalen Wert. (Die Nameserver-Delegation der Domain beim Registrar zu ändern ist ein separater, langsamerer Vorgang – und, wie gesagt, selten der, den Sie wirklich brauchen; siehe Registrar oder DNS-Anbieter wechseln.)

Prüfen, bevor Sie aufräumen

Für eine Website: Prüfen Sie Apex und www – über IPv4 und, wo eingerichtet, IPv6 –, kontrollieren Sie die gewollte Weiterleitung zwischen beiden, prüfen Sie, dass HTTPS funktioniert und der neue Anbieter sein Zertifikat ausgestellt hat, und klicken Sie sich durch Ihre übrigen Subdomains, um sicherzugehen, dass nichts Unbeteiligtes kaputtging.

Für E-Mail: Tauschen Sie Testnachrichten in beide Richtungen mit einem externen Postfach, prüfen Sie jeden erwarteten MX-Eintrag samt Priorität, lesen Sie in den Headern einer empfangenen Nachricht nach, ob SPF, DKIM und DMARC bestehen, testen Sie das Kontaktformular und die anderen automatischen Absender – und vergewissern Sie sich, dass der alte Server still geworden ist, bevor Sie ihn abschalten.

Tragen Sie die aktuellen Einträge des Anbieters exakt ein, bewahren Sie eine Kopie des vorherigen Stands auf und lassen Sie altes und neues System während der Umstellung überlappen – dann läuft der Wechsel glatt, und wenn nicht, ist er umkehrbar.

Was zu tun ist

1. Finden Sie heraus, wo Ihr DNS tatsächlich verwaltet wird – das ist nicht immer der Registrar.
2. Exportieren oder fotografieren Sie die komplette bestehende Zone, bevor Sie etwas ändern.
3. Holen Sie den aktuellen Eintragssatz aus dem Einrichtungsbildschirm des externen Dienstes selbst.
4. Prüfen Sie, ob auf denselben Namen schon Einträge existieren, bevor Sie neue anlegen.
5. Senken Sie die betroffenen TTLs rechtzeitig vorher – wo unterstützt und nicht abgeraten.
6. Fügen Sie nur die Einträge hinzu oder ändern Sie nur die, die der Dienst verlangt.
7. Für E-Mail: neue Postfächer vorbereiten und testen, bevor Sie MX anfassen; dann altes und neues System durch die Übergangszeit parallel laufen lassen.
8. Prüfen Sie DNS, HTTPS, Mail-Zustellung und Authentifizierungs-Header.
9. Stellen Sie normale TTLs wieder her – und entfernen Sie alte Einträge und Dienste erst, wenn alles bestanden hat.