Zum Inhalt springen 
Ich zeige dir Schritt für Schritt, wie du 2025 deine ionos domain einrichten und in wenigen Minuten live schaltest. Dabei richte ich DNS-Records sauber ein, binde externe Domains an und sorge für SSL sowie Weiterleitungen – klar erklärt, ohne Umwege.
Zentrale Punkte
Die folgenden Stichpunkte geben dir den schnellen Überblick für den gesamten Ablauf.
- DNS-Setup richtig planen: A, AAAA, CNAME, MX, TXT
- Externe Domains via Nameserver übernehmen
- SSL für Haupt- und Subdomains aktivieren
- Weiterleitungen für www und Root sauber lösen
- Fehler bei Propagation und E-Mail vermeiden
Vorbereitung: Konto, Name, Timing
Bevor ich loslege, prüfe ich zuerst meinen Domainnamen auf Verfügbarkeit und lege mir eine Alternative zurecht, falls die erste Wahl belegt ist. Ich erstelle oder öffne mein IONOS Konto, halte Rechnungsdaten bereit und plane 10–20 Minuten für die Grundkonfiguration ein. Für E-Mail-Setups notiere ich mir gewünschte Postfächer und spätere MX-Records, damit ich im Anschluss keine Lücken lasse. Auch an die gewünschte www-Variante denke ich früh: soll die Website auf www.deinedomain.de oder direkt auf deinedomain.de laufen. Mit dieser Vorbereitung spare ich mir später Klicks und halte Änderungen im DNS übersichtlich.
Domain bei IONOS registrieren: Schritt für Schritt
Ich melde mich im IONOS Login an, öffne den Menüpunkt Domain & SSL und starte die Suche nach meinem gewünschten Namen. Ist die Endung frei, buche ich sie, wähle die Laufzeit und schließe die Bestellung ab. Danach liegt die Domain in meinem Vertrag und ich kann sofort starten, Records zu setzen, E-Mail zu aktivieren oder sie mit einem Webspace zu verbinden. Für eine Website verknüpfe ich die Domain anschließend mit meinem Hosting oder meiner Anwendung, damit der A-Record später auf die richtige IP zeigt. Spätestens jetzt reserviere ich ein SSL-Zertifikat, damit Aufrufe direkt verschlüsselt erfolgen.
DNS-Grundlagen kurz erklärt
DNS löst einen Domainnamen in technische Ziele wie IP-Adressen und Dienste auf. Der A-Record zeigt auf eine IPv4-Adresse, AAAA auf IPv6, CNAME leitet Aliasnamen weiter, MX legt den Mail-Empfang fest, und TXT liefert Prüfwerte wie SPF oder Verifizierungen. Jede Änderung besitzt eine Gültigkeit, die Time to Live (TTL), die festlegt, wie lange Zwischenspeicher die Daten behalten. Propagation dauert wenige Minuten bis hin zu 48 Stunden, je nach Cache der Provider. Ich plane diese Verzögerung ein und teste Änderungen mit Tools, bevor ich einen Go-live ankündige.
DNS in IONOS einstellen: A, AAAA, CNAME, MX, TXT
In der DNS-Verwaltung wähle ich die Domain aus, öffne die Record-Ansicht und entscheide, ob ich die IONOS-Standardeinträge nutze oder eine eigene Konfiguration setze. Für Websites trage ich beim A-Record die Server-IP ein, ergänze optional AAAA, und leite www per CNAME auf die Hauptdomain. Für E-Mails setze ich MX-Records nach Vorgabe des Mail-Systems und hinterlege SPF/DKIM/DMARC als TXT, damit Zustellung und Reputation stimmen. Ändere ich mehrere Einträge nacheinander, speichere ich konsequent nach jedem Schritt, um keine Eingabe zu verlieren. Für tiefergehende Einstellungen hilft mir oft ein kompaktes Nachschlagewerk wie DNS-Einstellungen bei IONOS, damit ich die passende Record-Art schnell parat habe und Tipparbeit spare.
Externe Domain einbinden und Nameserver setzen
Liegt die Domain bei einem anderen Registrar, richte ich sie bei IONOS als externe Domain ein und stelle anschließend beim bisherigen Anbieter die Nameserver auf IONOS um. Dafür trage ich die Server ns1045.ui-dns.org, ns1045.ui-dns.de, ns1045.ui-dns.biz und ns1045.ui-dns.com ein und bestätige die Änderung. Nach der Aktualisierung verwalte ich alle DNS-Records direkt in IONOS und entferne alte Einträge beim Alt-Provider, damit keine widersprüchlichen Einstellungen entstehen. E-Mail-Dienste oder Weiterleitungen prüfe ich vorab und übertrage sie, sodass Postfächer ohne Unterbrechung erreichbar bleiben. Plane ich einen Umstieg, erstelle ich vorab ein Backup meiner Einträge, damit ich jede Einstellung sauber nachbilden kann.
Domain-Transfer oder DNS-Übernahme: was passt?
Ich entscheide zuerst, ob ich nur die DNS-Steuerung zu IONOS hole oder die Domain komplett transferiere. Bleibt die Domain beim bisherigen Registrar und ich ändere nur die Nameserver, geht es meist am schnellsten. Möchte ich alles unter einem Vertrag bündeln, stoße ich einen Domain-Transfer mit AuthCode an und beachte Transferfristen der TLD. Vor dem Start prüfe ich Lock-Status, Inhaberdaten und E-Mail-Erreichbarkeit für Freigaben. Für den Ablauf und typische Stolpersteine hilft mir ein bewährter Domain-Transfer Guide, damit der Wechsel ohne Unterbrechung über die Bühne geht.
Subdomains und SSL richtig aufsetzen
Für zusätzliche Projekte lege ich Subdomains wie blog.deinedomain.de oder shop.deinedomain.de an und weise sie einem Ziel zu. Ein CNAME auf einen Dienst oder ein A/AAAA-Record auf eine IP verbindet die Subdomain sauber mit dem Zielsystem. Danach aktiviere ich ein SSL-Zertifikat für jede genutzte Subdomain, damit Besucher keine Warnungen sehen. Nutze ich Wildcard-SSL (*.deinedomain.de), decke ich viele Subdomains auf einen Schlag ab; trotzdem prüfe ich, ob Spezialfälle ein separates Zertifikat erfordern. Zum Abschluss rufe ich jede Subdomain einmal auf und kontrolliere Inhalt, Zertifikatskette und Weiterleitungen.
Domain mit Baukästen und SaaS verbinden
Für externe Dienste wie Landingpage-Tools oder 3D-Touren lege ich meist einen CNAME auf eine vorgegebene Zieladresse an. Viele Anbieter erwarten www als CNAME, während die Root-Domain via 301-Weiterleitung auf www zeigt. Manchmal liefern Plattformen zusätzliche TXT-Records zur Verifizierung; diese setze ich gleich mit, damit Freischaltungen durchlaufen. Benötige ich eine dauerhafte Umleitung, halte ich die Unterschiede zwischen 301 und 302 klar auseinander. Ein kompaktes Nachlesen zur sauberen Umleitung liefert mir die DNS-Weiterleitung Erklärung, sodass ich keine Schleifen oder doppelten Hops erzeuge.
Weiterleitungen: www, Root-Domain und Redirects
Ich entscheide früh, ob die Website auf der Root-Domain oder unter www laufen soll und richte konsistente Weiterleitungen ein. Der Standard ist: www zeigt auf die Root oder umgekehrt, nicht beides gemischt. Für permanente Wechsel nutze ich 301, für temporäre Aktionen 302; so behalten Suchmaschinen die richtige kanonische Variante. DNS-seitig löse ich www als CNAME, während die Zieladresse per A/AAAA auf die Webserver-IP zeigt. In der Anwendung oder im Webserver setze ich zusätzlich eine Weiterleitung, damit jede URL exakt eine finale Adresse besitzt.
Häufige Fehler und schnelle Lösungen
Typische Stolperfallen betreffen TTL und Propagation: Änderungen brauchen Geduld, globale Caches leeren sich nicht überall gleichzeitig. Wenn E-Mails ausfallen, prüfe ich zuerst die MX-Records, danach SPF/DKIM/DMARC und leite Tests an mehrere Provider. Zeigt die Website sporadisch alte Inhalte, handelt es sich oft um DNS- oder Browser-Caches; ein Test über Mobilfunknetz klärt die Lage schnell. Bei SSL-Fehlern kontrolliere ich, ob Zertifikate für alle genutzten Hostnamen aktiv sind und ob die Kette vollständig ist. Vor großen Änderungen dokumentiere ich meine Einträge, damit ich jederzeit zu einem funktionierenden Zustand zurückkehren kann.
Hosting 2025: Leistung und Tarifwahl
Wer mehr aus seiner Domain holen will, achtet auf Performance, PHP-Versionen, Caching und Backups. Für stark besuchte Projekte lohnt ein Plan mit höherem Arbeitsspeicher, HTTP/2 oder HTTP/3 sowie NVMe-Speicher. Wichtig ist eine klare Skalierungsoption, damit ich bei wachsenden Zugriffen zügig upgraden kann. Ein Blick auf Support-Zeiten und Monitoring spart mir Ausfälle in kritischen Phasen. Die folgende Übersicht zeigt, wie ich 2025 gängige Pakete für typische Einsätze einordne, inklusive kurzer Vorteile.
| Platz | Anbieter | Vorteile |
|---|---|---|
| 1 | webhoster.de | Hohe Performance, sehr guter Service, umfangreiche Features – ideal für WordPress, Shops und Business-Projekte. |
| 2 | IONOS | Solider Einstieg, viele Zusatzfunktionen, breite Auswahl an Domain-Optionen. |
| 3 | Strato | Attraktive Preise, große Tarifvielfalt für unterschiedliche Anforderungen. |
TTL-Strategie und Änderungen ohne Downtime
Vor größeren Umstellungen senke ich die TTL betroffener Records gezielt ab (z. B. von 1–24 Stunden auf 300 Sekunden), und zwar 24–48 Stunden im Voraus. So greifen spätere Umschaltungen schneller. Nach dem Go-live erhöhe ich die TTL wieder auf ein stabiles Niveau, um unnötige DNS-Last und Cache-Misses zu vermeiden. Ich ändere möglichst nur einen Parameter pro Schritt (erst A/AAAA, dann Redirects, anschließend SSL-Zwang), damit ich Fehlerquellen klar eingrenzen kann. Bei parallelen Umzügen (Blue/Green) lasse ich die alte Umgebung noch einige Stunden mitlaufen und überwache Zugriffe, bevor ich sie abschalte.
Für komplexe Deployments erstelle ich je Umgebung eigene Subdomains (z. B. stage., preview., v2.) und trenne damit Tests sauber vom Live-Betrieb. Während des Cutovers halte ich die TTL kurz und plane einen klaren Rückweg: Ich dokumentiere die alten IPs und Records, um bei Problemen binnen Minuten zurückrollen zu können.
HTTPS sauber durchziehen: Zertifikate, HSTS und Kette
Nach der Aktivierung von SSL stelle ich sicher, dass wirklich alle Aufrufe auf HTTPS enden: Ich setze einen 301-Redirect von http:// auf https:// sowie auf meine kanonische Hostname-Variante (www oder Root). Um die Sicherheit zu verstärken, kann ich HSTS aktivieren (Strict-Transport-Security). Dabei setze ich zunächst eine moderate max-age und teste, bevor ich includeSubDomains oder einen Preload anvisiere. HSTS ist eine Einbahnstraße: Ein falsches Setup lässt sich beim Besucher nicht schnell zurücknehmen – daher prüfe ich Zertifikatserneuerungen und Subdomains gründlich.
Zeigt der Browser Kettenfehler, fehlt oft ein Intermediate-Zertifikat. Ich kontrolliere die Zertifikatskette und gleiche deren Gültigkeit mit der Hauptlaufzeit ab. Nutze ich mehrere Zertifikate (z. B. Wildcard plus Einzelzertifikat), achte ich darauf, Hostnamen nicht doppelt und widersprüchlich zu bedienen.
E-Mail-Authentifizierung im Detail: SPF, DKIM, DMARC
Für zuverlässige Zustellung setze ich drei Bausteine sauber um. SPF definiert erlaubte Versandpfade (v=spf1 … -all). Ich halte die Regel so schlank wie möglich und vermeide das Überschreiten der Lookup-Grenze (max. 10 DNS-Abfragen durch include, a, mx, ptr, exists, redirect). Überflüssige Includes entferne ich oder lasse sie von meinem Provider „flatten“.
DKIM signiert ausgehende Mails pro Domain und Selector (z. B. s1, s2). Ich plane die Schlüsselrotation: Während ein neuer Selector live geht, lasse ich den alten noch einige Tage aktiv, bevor ich ihn entferne. Bei DMARC starte ich mit p=none und lasse mir Berichte zusenden (rua=mailto:), um Sichtbarkeit zu gewinnen. Läuft alles stabil, erhöhe ich auf quarantine und anschließend auf reject. Ich wähle die Ausrichtung (Alignment) passend: aspf=r/adkim=r ist tolerant, s erzwingt strenge Übereinstimmung.
Neben MX-Prüfung kontrolliere ich bei Mail-Problemen immer die Reihenfolge der Records, Prioritäten und, ob restriktive DMARC-Policies legitime Absender ausklammern. Sollen mehrere Systeme parallel versenden (z. B. Shop, Newsletter, CRM), koordiniere ich SPF-Includes und richte eigene DKIM-Selector je System ein.
DNSSEC und CAA: zusätzliche Sicherheit
Ich aktiviere DNSSEC, um die Zone kryptografisch zu signieren. Liegt die Domain bei IONOS inklusive Registrierung, genügt das Einschalten in der Verwaltung; bei externen Registraren trage ich den DS-Record im Parent ein. Nach der Aktivierung teste ich die Auflösung: Bei Fehlkonfigurationen droht SERVFAIL statt korrekter Antworten. Vor Änderungen an Nameservern deaktiviere ich DNSSEC, migriere sauber und aktiviere es wieder, damit der Schlüsseltausch keinen Ausfall erzeugt.
Mit CAA-Records definiere ich, welche Zertifizierungsstellen Zertifikate für meine Domain ausstellen dürfen. Das schränkt die Angriffsfläche ein. Ich halte die Einträge konsistent für Root und Subdomains und hinterlege optional iodef für Benachrichtigungen. Vor dem Wechsel des Zertifikatsanbieters passe ich CAA frühzeitig an, damit die Ausstellung nicht blockiert wird.
CDN, WAF und Apex-Besonderheiten
Viele Plattformen verlangen einen CNAME auf die Zieladresse. Das ist für www unproblematisch, beim Apex (Root-Domain) jedoch nicht erlaubt. Ich löse das auf zwei Arten: Entweder ich leite die Root-Domain per 301 auf www um, oder ich trage die vom Anbieter bereitgestellten A/AAAA-Adressen ein. Bietet mein DNS-Provider ALIAS/ANAME oder CNAME-Flattening an, nutze ich diese Option für eine CNAME-ähnliche Erfahrung am Apex. Ich dokumentiere die Vorgaben des Dienstes (IPv4/IPv6, TLS-Termination, benötigte TXT-Verifizierungen) und plane Erneuerungsprozesse ein, damit Zertifikate und Zieladressen automatisiert aktuell bleiben.
IPv4/IPv6, Round-Robin und Fallback
Ich setze A und AAAA konsistent, sofern mein Zielsystem IPv6 unterstützt. Fehlt IPv6-Unterstützung, lasse ich den AAAA-Record weg, um Timeouts zu vermeiden. Für einfache Lastverteilung kann ich mehrere A-Records hinterlegen (Round-Robin). Ohne Health-Checks ist das nur ein „Best Effort“ – fällt ein Ziel aus, fragen Clients es trotzdem an. In kritischen Setups kombiniere ich DNS-Strategien mit Load-Balancern oder überwachten Endpunkten.
Profi-Checks: schneller testen und debuggen
Nach Änderungen verifiziere ich die Auflösung von außen. Mit dig oder nslookup prüfe ich A/AAAA/CNAME/MX/TXT und sehe, welche Nameserver geantwortet haben. dig +trace zeigt mir den Weg von der Root bis zur Authoritative-Zone – wertvoll, wenn Delegationen klemmen. Für Redirects reicht oft ein curl -I https://deinedomain.de, um Statuscodes und Ziel zu sehen. SSL-Ketten und SNI teste ich mit openssl s_client -connect deinedomain.de:443 -servername deinedomain.de -showcerts. Diese Checks bewahre ich mir als kleine Checkliste auf, um bei Störungen schnell zu entscheiden, ob es an DNS, Webserver, Zertifikat oder Anwendung liegt.
Sonderfälle sauber lösen
Wildcard-Subdomains (*.deinedomain.de) fange ich ab, wenn viele dynamische Hosts entstehen. Trotzdem definiere ich explizite Records für kritische Subdomains, da diese Wildcards übersteuern. Pfadbasierte Weiterleitungen gehören nicht ins DNS: Ein DNS-Record kennt nur Hostnamen, keine URLs mit Verzeichnissen. Solche Regeln setze ich im Webserver, Reverse-Proxy oder in der Zielanwendung um.
Bei internationalen Namen (IDN) prüfe ich die Punycode-Schreibweise, damit alle Systeme denselben Hostnamen erwarten. Nutze ich spezielle Dienste wie VoIP oder Kollaborationslösungen, kann ein SRV-Record nötig sein (z. B. _service._proto.name mit Zielhost, Port und Priorität). Ich trage diese Werte exakt wie gefordert ein, da Tippfehler hier für schwer auffindbare Fehler sorgen.
Struktur und Pflege der DNS-Zone
Ich halte meine Zone übersichtlich: klare Benennung, einheitliches Muster für Subdomains, kurze Notizen zu Zweck und Besitzer. Vor jeder größeren Änderung exportiere ich die Zone (oder fotografiere die Record-Liste) und archiviere sie. Wiederkehrende Muster (z. B. app, api, static) nutze ich konsequent, damit Teammitglieder sofort erkennen, wo was hingehört. Für Projekte mit vielen Beteiligten führe ich eine einfache Änderungs-History mit Datum, Verantwortlichen und kurzer Begründung – das spart später Suchzeit.
Kurz zusammengefasst: in 10 Minuten online
Ich registriere die Domain, setze A/AAAA und CNAME, aktiviere SSL und lege die gewünschte Weiterleitung fest – das reicht für den ersten Auftritt. Für E-Mails ergänze ich MX sowie SPF/DKIM/DMARC und teste Zustellung mit zwei bis drei Postfächern. Externe Domains hole ich über IONOS-Nameserver an Bord oder transferiere sie inklusive AuthCode. Wenn etwas klemmt, prüfe ich TTL, DNS-Caches und Zertifikate und arbeite Checklisten sauber ab. So bringe ich jede IONOS-Domain verlässlich online und halte Verwaltung und Wachstum übersichtlich.
