Zum Inhalt springen 
Ich zeige dir Schritt für Schritt, wie du deine Strato Domain mit einer externen Website verbindest – inklusive DNS, SSL und typischen Stolperfallen, damit alles sauber läuft. Der Leitfaden nutzt das Fokus-Keyword strato domain extern verbinden, erklärt die notwendigen Einträge und hilft dir, E-Mail bei Strato zu behalten, während deine Seite bei Squarespace, Webflow, Shopify oder einem anderen Dienst läuft.
Zentrale Punkte
Bevor ich in die Umsetzung gehe, fasse ich die wichtigsten Aspekte zusammen, damit du die einzelnen Schritte leichter einordnen kannst und keine Priorität verlierst. Ich erkläre kurz die Aufgabe der DNS-Einträge und warum du A- und CNAME-Records brauchst, um eine Domain sauber auf einen externen Anbieter zu richten. Ich zeige, wie du E-Mail bei Strato weiter nutzt, ohne deine Website dort zu hosten, damit Postfächer und Aliasse ohne Unterbrechung bestehen bleiben. Ich gehe auf Weiterleitung vs. DNS-Änderung ein und erläutere, wann welche Methode sinnvoll ist und welche Auswirkungen auf SEO entstehen. Ich gebe dir außerdem eine kompakte Prüfungsliste an die Hand, mit der du die Verbindung erfolgreich abschließt und spätere Fehler schnell findest.
- DNS-Grundlagen: A-, CNAME-, MX-, TXT-Records verstehen
- E-Mail behalten: MX-Records unverändert lassen
- SEO-Vorteile: DNS-Verbindung statt 301/302-Weiterleitung
- SSL/HTTPS: Zertifikat nach Verknüpfung prüfen
- Fehlersuche: TTL, Propagation und Cache im Blick
Was bedeutet „Strato Domain extern verbinden“?
Du behältst deine Domain bei Strato, leitest sie aber per DNS auf eine andere Plattform – die Website liegt also extern, während Strato deine Domain weiterhin verwalten. So trennst du Besitz der Adresse von Hosting und kannst Baukästen wie Squarespace, Webflow oder Shopify nutzen, ohne die Domain zu transferieren. Dafür passt du A- und CNAME-Records an, teilweise auch TXT-Records für Bestätigungen und Sicherheitsmerkmale. E-Mail kann weiterhin über Strato laufen, wenn du MX-Records nicht änderst und SPF/DKIM an das Gesamtsystem anpasst. Diese Entkopplung schafft maximale Freiheit bei Tools, Performance und künftigen Umzügen, ohne dass du die Hoheit über deine Adresse verlierst.
DNS-Grundlagen kurz erklärt
Ich unterscheide klar zwischen A-Record und CNAME, weil beide unterschiedliche Ziele haben. Der A-Record zeigt auf eine IPv4-Adresse der Zielplattform, während ein CNAME-Record einen Namen auf einen anderen Namen verweist, meist für „www“ oder Verifizierungen. Für einen schnellen Refresh kontrolliere ich den TTL-Wert, denn er beeinflusst, wie schnell Änderungen weltweit sichtbar werden. MX-Records lenken E-Mail, daher fasse ich sie nur an, wenn ich E-Mails wirklich umziehe. Für vertiefende Grundlagen nutze ich gerne kompakte Erklärungen wie A‑Record vs. CNAME, um Verwechslungen zu vermeiden.
Vorbereitung: Daten sammeln und prüfen
Ich halte mein Strato-Login bereit, wähle die konkrete Domain und entscheide, ob ich nur „www“ verbinden oder Root-Domain und „www“ gemeinsam auf die Zielseite leiten will. Dann öffne ich die Anleitung der Zielplattform, kopiere IPs, Hostnamen und etwaige TXT-Werte für die Verifizierung und lasse das Fenster offen. Ich prüfe, ob E-Mails bei Strato bleiben sollen, denn dann fasse ich MX-Records nicht an und plane nötige SPF/DKIM-Ergänzungen ein. Wenn ich DNS bei einem externen Dienst verwalte, überlege ich, ob dediziertes DNS-Hosting extern Vorteile bei Performance und Verwaltung bietet. Je besser die Vorbereitung, desto schneller setze ich die Einträge ohne spätere Korrekturen.
Schritt 1: Zielplattform einrichten (Squarespace, Webflow, Shopify)
Bei Squarespace öffne ich „Externe Domain verwenden“, gebe die Domain ein und wähle „Domain verbinden“, woraufhin CNAME- und A-Records mit konkreten Werten erscheinen [1][2], etwa IPs wie 198.185.159.144 für den A-Record etc.. Webflow zeigt mir nach „Add a custom domain“ die nötigen A-, CNAME- und ggf. TXT-Einträge für die Verifizierung an, die ich später bei Strato eintrage [3]. In Shopify gehe ich auf Einstellungen, Domains, „Bestehende Domain verbinden“ und erhalte die DNS-Zieldaten, die exakt in Strato übernommen werden [7]. Ich belasse diese Tabs offen, damit ich nichts falsch tippe und alle Namen exakt kopiere. So minimiere ich Schreibfehler und verkürze den späteren Abgleich.
Schritt 2: Bei Strato einloggen und Domain wählen
Ich melde mich im Strato-Kundenbereich an, gehe zu „Domains verwalten“ und wähle die passende Adresse. Anschließend öffne ich den DNS-Tab beziehungsweise die Domain-Verwaltung, je nachdem, wie das Menü angezeigt wird. Ich kontrolliere, ob bestehende A- oder CNAME-Records hinterlegt sind, und entscheide, ob ich sie überschreibe oder neue Subdomain-Einträge ergänze. Im Zweifel notiere ich mir den vorherigen Zustand, um jederzeit zurückspringen zu können. Übersicht und Sorgfalt sparen mir später sehr viel Zeit.
Schritt 3: DNS-Einträge setzen – A, CNAME, TXT
A-Record eintragen
Ich öffne den A-Record, setze die IP aus der Zielplattform und speichere die Änderung. Bei Squarespace nutze ich die bereitgestellten IPs [1][2], bei Webflow die angezeigten Adressen [3], bei Shopify die vorgegebenen Zielwerte [7]. Wenn die Root-Domain ohne „www“ erreichbar sein soll, setze ich den A-Record genau für die Hauptdomain. Einige Anbieter verlangen zusätzlich einen zweiten A-Record, den ich ebenfalls sauber übernehme. Genaues Kopieren verhindert spätere Probleme.
CNAME-Records hinterlegen
Für „www“ setze ich meist einen CNAME auf den Hostnamen der Plattform, etwa ext-cust.squarespace.com für Squarespace [1][2] oder die entsprechende Vorgabe bei Webflow beziehungsweise Shopify [3][7]. Manche Plattformen generieren einen zufälligen CNAME für die Verifizierung, den ich exakt mit Host und Ziel eintrage und ebenfalls speichere. Falls „www“ auf die Root-Domain zeigen soll, nutze ich entweder einen CNAME auf die Root (wenn erlaubt) oder die vom Anbieter empfohlene Variante. Ich entferne keine MX-Records, wenn E-Mail bei Strato bleibt. So bleibt die Zustellung zuverlässig und ohne Ausfall.
TXT-Records für Verifizierung und E-Mail
Webflow verlangt oft einen TXT-Record mit einem one-time-verification-Wert [3], den ich genauso übernehme und abspeichere. Für saubere Absenderreputation ergänze oder aktualisiere ich SPF und später DKIM, wenn ich externe E-Mail-Services plane. Ich tippe TXT-Werte exakt ab oder kopiere sie, damit keine unnötigen Fehler entstehen. Nach jeder Änderung prüfe ich, ob der Eintrag syntaktisch passt und keine doppelten Records unnötige Konflikte verursachen. Sauber gepflegte TXT-Records ersparen mir viel Support.
Schritt 4: Prüfung, SSL und Redirects
Nach dem Speichern warte ich auf die DNS-Propagation, die wenige Minuten bis etliche Stunden dauern kann, und starte dann die Prüfung. In der Zielplattform schaue ich auf den Verbindungsstatus, häufig erscheint ein grüner Haken oder eine Bestätigung. Ich aktiviere oder erneuere das SSL-Zertifikat, damit HTTPS ohne Warnmeldung läuft, und teste http auf https, sowie „www“ auf die Root oder umgekehrt. Ich prüfe, ob Canonical-URLs stimmen und ob Weiterleitungen sauber greifen, damit keine doppelten Inhalte entstehen. Ein kurzer Test mit mehreren Geräten und Netzen deckt Cache-Effekte und lokale Resolver auf.
Weiterleitung vs. DNS-Änderung
Eine Domain-Weiterleitung richte ich ein, wenn ich nur umleiten will, etwa von einer Zusatzdomain auf eine Hauptadresse, ohne DNS-Records im Detail zu ändern [4][6]. Dazu gehe ich bei Strato in die Domainverwaltung und nutze „Umleitung einrichten“, trage die Ziel-URL ein und wähle 301 für dauerhaft oder 302 für temporär [6]. Für eine saubere SEO nutze ich bei Hauptprojekten jedoch die DNS-Verbindung per A- und CNAME-Record, damit die Seitenstruktur und URLs unverändert bleiben. Falls du genau wissen willst, wie das geht, hilft dir diese Anleitung zur Weiterleitung bei Strato. Die folgende Tabelle zeigt den Unterschied in Kurzform und erleichtert deine Entscheidung.
| Methode | Vorteile | Nachteile |
|---|---|---|
| DNS (A-/CNAME-Änderung) | Volle Kontrolle, gute SEO, keine URL-Wechsel | Technisch etwas aufwendiger |
| Weiterleitung (301/302) | Schnell eingerichtet | Weniger professionell, eigene URL-Struktur geht verloren |
Typische Fehler und schnelle Lösungen
Wenn nach 24 Stunden nichts live ist, vergleiche ich alle Werte erneut und suche Tippfehler bei Hostnamen, Punkten oder Bindestrichen. Ich prüfe, ob ich ungewollt alte Records stehen ließ, die neue Einträge überlagern könnten, etwa mehrere A-Records für dieselbe Hostname-Kombination. Ich leere Browser- und DNS-Cache oder teste per Hotspot, um lokale Effekte auszuschließen. Ich kontrolliere TTL, denn ein hoher Wert verzögert die Sichtbarkeit weltweit deutlich. Bei hartnäckigen Fällen entferne ich widersprüchliche Einträge und setze die Zielwerte neu, damit nur die korrekten Records greifen.
E-Mail bei Strato behalten: MX, SPF, DKIM
Ich lasse MX-Records unverändert, wenn Postfächer bei Strato weiter laufen sollen, und ändere ausschließlich Web-Records wie A und CNAME. Ich ergänze SPF so, dass Strato als sendender Server erlaubt bleibt, eventuell plus externe Dienste, die später Mails senden. Ich richte DKIM dort ein, wo meine Mail tatsächlich signiert wird, damit Empfänger die Signatur prüfen können. Ich teste die Zustellung, Antispam-Quoten und Rückläufer, um Fehlkonfigurationen schnell zu erkennen. So bleiben Website und E-Mail sauber getrennt und funktionieren zuverlässig weiter.
DNS-Propagation verstehen: TTL richtig wählen
TTL beschreibt, wie lange Resolver einen Eintrag cachen, daher plane ich Änderungen so, dass ich vorab eine niedrigere TTL setze und erst danach die Zielwerte ändere. Nach der Umstellung erhöhe ich die TTL wieder, um weniger Anfragen zu verursachen und die Antwortzeiten zu stabilisieren. Bei dringenden Launches reduziere ich TTL rechtzeitig, damit Updates schneller sichtbar werden. Ich kommuniziere intern, dass es zu Verzögerungen kommen kann, und plane Puffer für die DNS-Propagation ein. So vermeide ich falsche Annahmen und halte Erwartungen realistisch im Team.
Checkliste ohne Haken: So gehe ich vor
Ich starte mit der Zielplattform, erfasse alle DNS-Werte und öffne das Fenster mit A-, CNAME- und TXT-Einträgen für die spätere Übernahme. Danach logge ich mich bei Strato ein, wähle die Domain und öffne den DNS-Tab. Ich setze A-Record(s) für die Root-Domain, trage den CNAME für „www“ ein und übernehme die Verifizierungs-TXT-Werte. Ich speichere und warte auf die Aktualisierung, beobachte die Zielplattform und bestätige die Verbindung, sobald der Status grün ist. Ich aktiviere SSL, teste http zu https, „www“ zur Root und prüfe, ob alle Seiten erreichbar sind und Canonicals stimmen, damit SEO sauber bleibt.
Technische Besonderheiten bei Strato: Hostnamen, Root und CNAME-Limits
Beim Eintragen der DNS-Records achte ich auf die Eingabemasken. Für die Root-Domain nutze ich entweder das Hostfeld „@“ oder lasse es leer, je nach Oberfläche. Ich setze beim Ziel eines CNAME keinen Protokoll-Teil (kein http/https), sondern nur den FQDN – idealerweise mit abschließendem Punkt in Gedanken, auch wenn die UI ihn nicht zeigt. Wichtig: Ein CNAME an der Root ist im DNS-Standard nicht erlaubt. Wenn ich die Root-Domain auf eine Plattform zeigen will, nutze ich A-Record(s) (und optional AAAA für IPv6). Einige DNS-Anbieter bieten ALIAS/ANAME für die Root an; bei Strato plane ich konservativ mit A/AAAA und verwende „www“ als CNAME auf den Plattform-Host. So bleibt die Zone normkonform und stabil.
Ich halte die Anzahl der Einträge pro Host bewusst schlank. Mehrere A-Records mit unterschiedlichen Zielen können erwünscht sein (Load-Balancing), erzeugen bei falscher Mischung jedoch Inkonsistenzen. CNAME und A/MX/TXT dürfen sich niemals denselben Host teilen. Ich prüfe deshalb doppelte Hosts und entferne widersprüchliche Kombinationen, bevor ich neue Werte speichere.
IPv6 (AAAA), CAA und DNSSEC im Blick
Viele Plattformen unterstützen heute IPv6. Wenn mir die Zielplattform AAAA-Adressen anbietet, ergänze ich sie neben dem A-Record, damit die Seite auch über IPv6 erreichbar ist. Das steigert Reichweite und kann Latenzen verbessern. Zusätzlich kann ich CAA-Records definieren, um festzulegen, welche Zertifizierungsstellen (CAs) Zertifikate für meine Domain ausstellen dürfen. Das ist eine freiwillige Absicherung gegen Fehlissuance. Falls DNSSEC bei Strato aktiviert ist, ändere ich Nameserver oder kritische DNS-Einträge nur mit Blick auf korrekte Signaturen. Bei einem geplanten Nameserver-Wechsel stelle ich sicher, dass Key-Rollover und DS-Eintrag sauber koordiniert sind, damit es zu keinem Ausfall kommt.
www oder nicht-www: Canonical-Strategie und HSTS
Ich entscheide bewusst, ob meine Hauptadresse mit oder ohne „www“ laufen soll. Beide Varianten sind technisch korrekt, aber ich brauche eine klare Canonical und eine saubere 301-Weiterleitung von der sekundären Variante. Ich prüfe die Redirect-Kette: Es sollte nur ein Hop von http zu https und ggf. von www zur Root (oder umgekehrt) stattfinden. Längere Ketten erhöhen Latenzen und schwächen SEO. Wenn ich HSTS nutze, aktiviere ich es erst, wenn HTTPS auf beiden Varianten sauber steht, da falsch gesetztes HSTS bei gemischten Inhalten oder fehlerhaften Zertifikaten zu harten Blockaden führt. Mixed-Content warne ich aktiv aus, indem ich sämtliche Assets auf https umstelle.
Alternative: Nameserver wechseln statt DNS bei Strato pflegen
Manchmal ist es sinnvoller, die Nameserver komplett auf einen externen Provider zu legen (externe DNS-Verwaltung), etwa für Anycast-Performance, Geo-DNS oder umfangreiche Automatisierung. Dabei ändere ich bei Strato lediglich die Nameserver-Einträge und verlagere alle Zone-Records (A, AAAA, CNAME, MX, TXT, CAA) zum neuen DNS-Anbieter. Vorteile: schnelle Änderungen, APIs und ggf. integrierte CDN/WAF-Dienste. Nachteile: zusätzliche Abhängigkeit und Mehraufwand beim initialen Transfer der Zone. Für das Kernziel „strato domain extern verbinden“ reicht die Verwaltung in Strato jedoch meist aus – ich wähle den Wechsel nur, wenn ich die Extras wirklich nutzen will.
Mischbetrieb: Subdomains für Blog, Shop und App
Ich plane den Namensraum frühzeitig. Häufig läuft die Hauptseite unter der Root oder „www“, während ein Shop unter „shop.“ und ein Blog unter „blog.“ liegt. Dafür setze ich gezielt Subdomain-Records: CNAME für „www“ und ggf. „blog.“ auf die Plattform-Hosts, A/AAAA für Dienste, die IPs verlangen, oder einen eigenen MX/separate TXT-Einträge, wenn Subdomains eigenständig Mails versenden. Von Wildcard-Records („*.domain.tld“) halte ich Abstand, sofern ich sie nicht wirklich brauche – sie können die Fehlersuche erschweren und verdächtige Subdomains verdecken.
Erweiterte E-Mail-Absicherung: SPF, DKIM, DMARC sauber abstimmen
Damit E-Mail bei Strato zuverlässig bleibt, passe ich neben unveränderten MX-Records die Absender-Authentifizierung sorgfältig an. SPF soll alle legitimen Sender umfassen, aber das 10-DNS-Lookups-Limit nicht reißen. Ich vermeide doppelte SPF-Records und pflege eine einzige, konsolidierte Policy. DKIM setze ich dort, wo Mails tatsächlich signiert werden (z. B. Newsletter-Tool). Schlüssel drehe ich turnusmäßig, alte Selector lasse ich während der Übergangsphase parallel bestehen. Zusätzlich ergänze ich DMARC mit „p=none“ zum Start, überwache Reports und erhöhe später auf „quarantine“ oder „reject“. So steigere ich Zustellbarkeit, ohne Risiko für legitime Absender.
Diagnose und Tests: Tools und Kommandos
Für die verlässliche Prüfung verlasse ich mich nicht nur auf Browser-Tests. Ich nutze Befehle wie dig oder nslookup, um A-, AAAA-, CNAME-, MX- und TXT-Records abzufragen (z. B. dig A deine-domain.tld +short, dig CNAME www.deine-domain.tld +short). Mit curl -I https://deine-domain.tld sehe ich HTTP-Statuscodes und prüfe, ob Redirects wie erwartet greifen. openssl s_client -connect deine-domain.tld:443 -servername deine-domain.tld hilft beim SSL-Handshake. Bei Problemen leere ich DNS-Caches: unter Windows ipconfig /flushdns, auf macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, unter Linux je nach Resolver. Tests über Mobilfunk-Hotspot blenden lokale Netzwerkcaches aus.
Zero-Downtime-Planung und Rollback
Wenn ich Downtime unbedingt vermeiden will, senke ich die TTL 24–48 Stunden vor dem Wechsel auf z. B. 300 Sekunden. Ich richte die Zielplattform komplett ein, aktiviere SSL-Vorbereitungen und teste unter einer temporären Subdomain (z. B. „staging.“). Am Umschalttermin ändere ich die relevanten DNS-Records, überwache die Erreichbarkeit und lasse die alte Umgebung kurze Zeit parallel bestehen. Tritt ein Fehler auf, kann ich mit der niedrigen TTL schnell auf die vorherige Konfiguration zurückspringen. Nach erfolgreicher Stabilisierung erhöhe ich die TTL wieder auf einen ausgewogenen Wert (z. B. 3600 Sekunden) für weniger Queries und stabile Antworten.
Feinheiten bei Plattform-Vorgaben
Viele Anbieter zeigen mehrere A-IPs an. Ich übernehme alle, sofern empfohlen, damit die Plattform Lastverteilung und Failover nutzen kann. Bei CNAME-Verifizierungen verwende ich exakt den von der Plattform genannten Host (inkl. eventueller Präfixe wie „_verification“ oder zufälliger Tokens). Ich warte die interne Statusprüfung ab, bevor ich alte Verifizierungs-Records lösche. Einige Plattformen benötigen Zeit, um Zertifikate auszustellen – ich plane daher keine sofortigen Live-Tests Sekunden nach der Umstellung.
Häufige Fragen (FAQ) zu „strato domain extern verbinden“
- Wie lange dauert die Umstellung? Zwischen Minuten und 24–48 Stunden, abhängig von TTL, Caches und globaler Propagation.
- Geht E-Mail verloren? Nein, wenn MX unverändert bleibt und SPF/DKIM/DMARC korrekt gepflegt sind. Web-Änderungen betreffen E-Mail nicht.
- Muss ich IPv6 setzen? Nein, aber es ist empfehlenswert. Wenn die Plattform AAAA liefert, profitiert die Erreichbarkeit und oft die Latenz.
- Kann ich Root nur per CNAME verbinden? Standard-DNS erlaubt keinen Root-CNAME. Ich nutze A/AAAA oder die vom Anbieter empfohlenen Alternativen.
- Warum sehe ich alte Inhalte? Lokale oder Provider-Caches, hohe TTL oder CDNs können alte Einträge vorübergehend zeigen. Geduld und Cache-Flush helfen.
- Was ist mit Subdomains? Ich kann einzelne Subdomains getrennt anbinden (Blog, Shop, App) und so Mischbetrieb ohne Konflikte realisieren.
- Wie sichere ich mich ab? Mit CAA-Records für Zertifikate, DNSSEC (falls genutzt), klarer Redirect-Strategie und konsistenter E-Mail-Authentifizierung (SPF/DKIM/DMARC).
Kurz zusammengefasst
Ich verbinde meine Strato-Domain extern, indem ich A-, CNAME- und nötige TXT-Records exakt setze und MX-Records für E-Mail bei Strato lasse. Ich teste nach der Umstellung SSL, Weiterleitungen und den Status in der Zielplattform, bis alles grün ist. Für SEO und klare URLs nutze ich bevorzugt die DNS-Verknüpfung statt reiner Weiterleitungen. Bei Fehlern prüfe ich akribisch Schreibweisen, TTL und Caches, bevor ich weitere Änderungen vornehme. Mit diesem Ablauf gelingt die Verbindung zuverlässig, ohne deine E-Mail oder Projektstruktur zu gefährden.
