DNS-Records bei netcup im CCP verwalten: A, AAAA, CNAME, MX und TXT richtig setzen
Im netcup CCP lassen sich A-, AAAA-, CNAME-, MX- und TXT-Records direkt im Browser anlegen. Diese Anleitung zeigt alle Schritte – inklusive netcup-Eigenheiten wie Grün-Box-Validierung, CNAME-Einschränkungen und 10-Minuten-Propagation.
Wer bei netcup eine Domain betreibt, verwaltet seine DNS-Einträge direkt im Customer Control Panel (CCP) – ohne separates DNS-Tool, ohne CLI. Das CCP bietet eine vollständige webbasierte DNS-Verwaltung für alle Record-Typen, die im KMU-Alltag relevant sind: A, AAAA, CNAME, MX und TXT. Diese Anleitung erklärt dir, wie du jeden dieser Typen korrekt anlegst, bearbeitest und typische Fallstricke wie die CNAME-Beschränkung auf der Root-Domain oder den Unterschied zwischen interner und weltweiter Propagation vermeidest.
Voraussetzungen
- Netcup-Account mit Kundennummer und Passwort
- Mindestens eine bei netcup registrierte oder zu netcup transferierte Domain
- Netcup-Nameserver müssen für die Domain aktiv sein:
ns1.netcup.net,ns2.netcup.net,ns3.netcup.net– sonst wirken CCP-Änderungen nicht - Ziel-IP-Adressen (IPv4/IPv6) für A/AAAA-Records bereithalten
- Hostnamen des Mailservers für MX-Records
- SPF/DKIM/DMARC-Strings vom E-Mail-Anbieter, falls benötigt
- Einen modernen Browser – keine Software-Installation erforderlich
Schritt 1: DNS-Verwaltung im CCP öffnen
Melde dich unter customercontrolpanel.de an. Navigiere links im Menü zu „Domains". In der Domain-Liste klickst du auf das Lupen-Icon neben der gewünschten Domain. Im folgenden Detail-Bereich wechselst du zum Tab „DNS".
Dort siehst du eine tabellarische Übersicht aller vorhandenen Records sowie ein Formular zum Hinzufügen neuer Einträge. Jeder Eintrag besteht aus den Feldern Host, Type, Destination sowie bei MX-Records zusätzlich MX Priority. Die Spalte Valid zeigt den Validierungsstatus nach dem Speichern.
Verifizieren: Du siehst den DNS-Tab mit vorhandenen Records (mindestens NS- und SOA-Einträge) und einem leeren Formular zum Hinzufügen.
Schritt 2: A-Record anlegen (IPv4)
Ein A-Record verknüpft einen Hostnamen mit einer IPv4-Adresse. Das ist der häufigste Record-Typ – er wird für die Root-Domain (@) und Subdomains wie www eingesetzt.
Host: @
Type: A
Destination: 78.47.133.14Für eine Subdomain wie www trägst du im Feld Host stattdessen www ein. Klicke anschließend auf „Save DNS Records".
Verifizieren: Eine grüne Box erscheint nach dem Speichern. Der neue Eintrag ist in der Record-Liste sichtbar. Nach ca. 10 Minuten kannst du mit nslookup example.com ns1.netcup.net die Auflösung prüfen.
Schritt 3: AAAA-Record anlegen (IPv6)
Für IPv6-Konnektivität benötigst du einen AAAA-Record. Die Vorgehensweise ist identisch zum A-Record, nur der Typ und die Destination-Adresse unterscheiden sich.
Host: @
Type: AAAA
Destination: 2a03:4000:1:2::1Du kannst A- und AAAA-Record parallel für denselben Hostnamen betreiben – das nennt sich Dual-Stack. Moderne Resolver bevorzugen dann IPv6.
Verifizieren: Grüne Box nach dem Speichern. Test: nslookup -type=AAAA example.com ns1.netcup.net
Schritt 4: CNAME-Record anlegen (Alias)
Ein CNAME-Record erstellt einen Alias: Er zeigt auf einen anderen Hostnamen statt auf eine IP-Adresse. Das ist praktisch für www, Shop-Subdomains oder externe Dienste wie GitHub Pages.
Wichtige Einschränkung: CNAME-Records sind auf der Root-Domain (@) technisch nicht erlaubt. Sie würden mit den obligatorischen SOA- und NS-Records kollidieren (RFC-Vorgabe). Netcup setzt dies korrekt durch – der Versuch endet mit einer roten Box.
Host: www
Type: CNAME
Destination: meinserver.example.com.Beachte den abschließenden Punkt (.) im Destination-Feld. Er kennzeichnet den Hostnamen als absoluten FQDN und verhindert, dass der Resolver ihn fälschlicherweise relativ zur eigenen Zone interpretiert.
Weitere Einschränkung: Für denselben Hostnamen darf kein CNAME parallel zu anderen Record-Typen existieren. www kann also nicht gleichzeitig CNAME und A-Record sein.
Verifizieren: Grüne Box nach dem Speichern. Test: nslookup -type=CNAME www.example.com ns1.netcup.net
Schritt 5: MX-Record anlegen (Mailserver)
MX-Records definieren, welcher Mailserver E-Mails für deine Domain entgegennimmt. Der Wert im Feld MX Priority steuert die Priorität: Je niedriger die Zahl, desto höher die Priorität. Für einen einzelnen Mailserver empfiehlt sich der Richtwert 10.
Host: @
Type: MX
MX Priority: 10
Destination: mail.example.com.Für Redundanz kannst du mehrere MX-Records mit unterschiedlichen Prioritäten anlegen – z.B. 10 für den Primär- und 20 für den Backup-Server.
Fallstrick: MX-Records sollten immer direkt auf A/AAAA-Records zeigen, niemals auf CNAME-Einträge. Das verstößt gegen RFC 2181 und kann zu Zustellungsproblemen führen.
Verifizieren: Grüne Box nach dem Speichern. Test: nslookup -type=MX example.com ns1.netcup.net oder MXToolbox.
Schritt 6: TXT-Record anlegen (SPF, DKIM, Verifikation)
TXT-Records sind das Schweizer Messer unter den DNS-Einträgen. Sie werden für SPF-Konfigurationen, DKIM-Verifikation, DMARC, sowie Domain-Verifizierungen bei Google Search Console oder Microsoft 365 verwendet. Es gibt im netcup CCP keinen separaten SPF-Record-Typ – SPF wird ausschließlich als TXT-Record implementiert.
Host: @
Type: TXT
Destination: v=spf1 mx a include:_spf.webhosting.systems ~allDas Anführungszeichen um den Wert kannst du im Eingabefeld weglassen – netcup fügt es intern korrekt hinzu.
Für DMARC trägst du den Record auf dem speziellen Host _dmarc ein:
Host: _dmarc
Type: TXT
Destination: v=DMARC1; p=none; rua=mailto:dmarc@example.comWichtig bei SPF: Pro Domain darf nur ein einziger TXT-Record mit v=spf1 existieren. Mehrere SPF-Records führen laut RFC 7208 zu SPF-Fehlern und verschlechtern die E-Mail-Zustellbarkeit.
Verifizieren: Grüne Box nach dem Speichern. SPF-Test via MXToolbox SPF-Checker.
Schritt 7: DKIM per CNAME einrichten (netcup Webhosting)
Wenn du das netcup Webhosting nutzt, wird DKIM nicht über einen TXT-Record, sondern über CNAME-Records auf webhosting.systems delegiert. Das netcup-System verwaltet die eigentlichen DKIM-Schlüssel zentral.
Host: key1._domainkey
Type: CNAME
Destination: key1._domainkey.[paketname].webhosting.systems.
Host: key2._domainkey
Type: CNAME
Destination: key2._domainkey.[paketname].webhosting.systems.Den genauen Paketnamen findest du im Webhosting-Bereich deines CCP.
Übersicht: DNS-Record-Typen im netcup CCP
| Record-Typ | Zweck | Host-Beispiel | Destination-Beispiel | Besonderheit |
|---|---|---|---|---|
| A | IPv4-Adresse zuweisen | @ oder www | 78.47.133.14 | Root-Domain (@) erlaubt |
| AAAA | IPv6-Adresse zuweisen | @ oder www | 2a03:4000:1:2::1 | Root-Domain (@) erlaubt |
| CNAME | Alias auf anderen Hostnamen | www, shop | ziel.example.com. | Nicht auf @, kein Mix mit anderen Typen |
| MX | Mailserver für die Domain | @ | mail.example.com. | Priorität erforderlich, kein CNAME-Ziel |
| TXT | SPF, DKIM, Verifikation | @, _dmarc | v=spf1 mx a ... | SPF nur einmal pro Domain |
| SRV | Dienst-Lokalisierung | _sip._tcp | 10 20 5060 sip.example.com. | Priorität, Weight, Port, Ziel |
| NS | Nameserver-Delegation | subdomain | ns1.nameserver.de. | Für Subdomain-Delegation |
| CAA | SSL-Ausstellung beschränken | @ | 0 issue "letsencrypt.org" | Schränkt erlaubte CAs ein |
| DS | DNSSEC-Schlüssel-Signierung | @ | [Key-ID Algo Hash] | Nur mit aktivem DNSSEC |
Propagation und TTL verstehen
| Szenario | Zeitrahmen | Hinweis |
|---|---|---|
| netcup-interne Aktivierung | ~10 Minuten | Gilt nur für netcup-eigene Nameserver |
| Weltweite Propagation (niedriger TTL) | 1–2 Stunden | Abhängig von externen Resolver-Caches |
| Weltweite Propagation (hoher TTL / 48h) | Bis zu 48 Stunden | Alte TTL-Werte bleiben gecacht |
| TTL-Konfiguration | Zone-weit | Keine individuellen TTL pro Record |
| Reset auf Standard-DNS | ~10 Minuten | Via Checkbox „Set standard DNS settings" |
Der TTL (Time to Live) ist bei netcup zone-weit konfigurierbar, nicht pro einzelnem Record. Möchtest du eine Migration oder einen Server-Wechsel möglichst schnell weltweit wirksam machen, senke den TTL mindestens 24 Stunden vor dem geplanten Wechsel auf einen niedrigen Wert wie 300 Sekunden ab. Externe Resolver cachen sonst den alten Wert für die gesamte ursprüngliche TTL-Dauer.
Records bearbeiten und löschen
Bestehende Records kannst du direkt im DNS-Tab des CCP anpassen. Klicke den gewünschten Eintrag an, ändere die Felder und speichere wieder mit „Save DNS Records". Die grüne Box bestätigt, dass die Änderung korrekt gespeichert wurde.
Zum Löschen eines Records entfernst du die Zeile bzw. leerst die entsprechenden Felder, je nach CCP-Version über ein Lösch-Icon oder durch Bereinigen des Eintrags. Danach wieder speichern.
Die Checkbox „Set standard DNS settings" setzt sämtliche manuell eingerichteten Records auf netcup-Standardwerte zurück. Vorsicht: Dieser Vorgang überschreibt alle eigenen Einträge ohne weitere Rückfrage und ist nach dem Speichern nicht einfach rückgängig zu machen. Notiere vorher alle manuellen Records.
Wildcard-Subdomain einrichten
Möchtest du alle undefinierten Subdomains auf dieselbe IP-Adresse leiten, verwendest du das Wildcard-Zeichen * als Host-Wert:
Host: *
Type: A
Destination: 78.47.133.14Damit werden Anfragen an beliebig.example.com auf die angegebene IP weitergeleitet, solange kein spezifischer Record für diesen Hostnamen existiert. Explizite Records haben Vorrang vor dem Wildcard-Eintrag.
Troubleshooting / Typische Fehler
Rote Box beim Speichern
Die rote Box zeigt einen semantischen Fehler im Eintrag an – z.B. eine ungültige IP-Adresse, ein falsch formatierter Hostname oder ein unzulässiger Record-Typ für den gewählten Host. Überprüfe Destination und Host auf Tippfehler. IPv6-Adressen müssen vollständig oder in korrekter Kurzschreibweise angegeben werden.
CNAME auf Root-Domain schlägt fehl
Wenn du versuchst, einen CNAME-Record mit Host @ anzulegen, erhältst du eine Fehlermeldung. Das ist kein CCP-Bug, sondern RFC-konformes Verhalten. Verwende stattdessen einen A-Record (IPv4) oder AAAA-Record (IPv6). Benötigst du einen Alias auf der Root-Domain (z.B. für einen CDN-Anbieter), frage beim Anbieter nach einem ALIAS- oder ANAME-Record – netcup CCP unterstützt dies nativ nicht.
Änderung ist nach 10 Minuten noch nicht aktiv
Die 10-Minuten-Angabe gilt ausschließlich für netcup-interne Nameserver. Externe Resolver cachen Einträge für die Dauer des eingestellten TTL. Teste direkt gegen einen netcup-Nameserver: nslookup example.com ns1.netcup.net. Wenn dort der neue Wert erscheint, liegt das Problem beim externen Resolver-Cache.
Mehrere SPF-Records führen zu Fehlern
Existieren zwei TXT-Records mit v=spf1 auf der Root-Domain, schlagen SPF-Prüfungen bei eingehenden Mails fehl. Zusammenführen statt duplizieren: Alle Includes in einen einzigen SPF-Record packen. Prüfen lässt sich das mit dem MXToolbox SPF-Checker.
DNS-Änderungen wirken überhaupt nicht
Falls im CCP gespeicherte Einträge sich gar nicht auswirken, prüfe zunächst, ob für die Domain tatsächlich die netcup-Nameserver eingetragen sind. Wenn externe Nameserver aktiv sind, hat der netcup-DNS-Tab keinen Effekt. Die aktuellen Nameserver siehst du im selben CCP unter dem Domain-Detail.
Fehlende abschließende Punkte bei Hostnamen
Bei CNAME-, MX- und NS-Records sollte der Ziel-Hostname mit einem abschließenden Punkt enden (z.B. mail.example.com.). Ohne Punkt kann der Resolver den Hostnamen relativ zur aktuellen Zone interpretieren, was zu falschen Auflösungen führt.
Häufige Fragen
Kann ich einen CNAME für meine Hauptdomain (z.B. example.com ohne www) setzen?
Nein. CNAME-Records auf der Root-Domain (@) sind technisch nicht erlaubt, da sie mit den obligatorischen SOA- und NS-Records kollidieren. Das ist RFC-Standard, keine netcup-Einschränkung. Verwende A- oder AAAA-Records für die Root-Domain. Einige Anbieter bieten ALIAS/ANAME als Workaround – netcup CCP unterstützt das nativ nicht.
Wie lange dauert es, bis ein neuer DNS-Eintrag aktiv ist?
Netcup-intern sind Änderungen typischerweise nach ca. 10 Minuten sichtbar. Weltweit hängt es vom gesetzten TTL ab: Externe Resolver behalten den alten Wert im Cache, bis der TTL abläuft – das können bis zu 48 Stunden sein. Tipp: TTL vor einer geplanten Änderung auf 300 Sekunden absenken.
Was bedeutet die grüne Box nach dem Speichern?
Die grüne Box ist die Bestätigung, dass der Eintrag semantisch korrekt und erfolgreich gespeichert wurde. Eine rote Box signalisiert einen Formatfehler, z.B. eine ungültige IP-Adresse oder einen unzulässigen Record-Typ für diesen Host.
Wie trage ich SPF für meine Domain ein?
SPF wird als TXT-Record auf Host @ angelegt. Für netcup-Webhosting lautet der typische Wert:
v=spf1 mx a include:_spf.webhosting.systems ~allPro Domain darf nur ein einziger TXT-Record mit v=spf1 existieren.
Kann ich den TTL pro einzelnem Record einstellen?
Im netcup CCP ist der TTL nur zone-weit konfigurierbar, nicht individuell pro Record. Zudem respektieren nicht alle externen Nameserver den eingestellten TTL-Wert.
Was passiert, wenn ich „Set standard DNS settings" aktiviere?
Alle manuell eingerichteten DNS-Records werden gelöscht und durch netcup-Standardeinträge ersetzt. Dieser Vorgang ist nach dem Speichern nicht rückgängig zu machen. Notiere alle eigenen Records, bevor du diese Option nutzt.
Fazit
Das netcup CCP bietet eine vollständige und übersichtliche DNS-Verwaltung direkt im Browser – ohne externe Tools oder Kommandozeile. Die Grün/Rot-Validierung gibt sofortiges Feedback, und die interne Propagation von ca. 10 Minuten ermöglicht schnelle Tests. Die wichtigsten netcup-Eigenheiten, die du dir merken solltest: CNAME niemals auf @ setzen, SPF immer als TXT-Record anlegen und bei geplanten Serverumzügen den TTL rechtzeitig absenken. Wer seinen netcup-Server und die E-Mail-Zustellbarkeit weiter absichern möchte, findet in den verlinkten Anleitungen hilfreiche nächste Schritte.
Weiterführende Anleitungen und Quellen
- DNS-Records erklärt: A, AAAA, CNAME, MX und TXT
- Reverse-DNS (rDNS/PTR) für IPv4 und IPv6 im netcup SCP setzen
- Exchange Online: SPF, DKIM und DMARC für die eigene Domäne
- Domain umziehen ohne Ausfall: Website und E-Mail sicher migrieren
- netcup Helpcenter: Configuring DNS (Existing Domains)
- netcup Helpcenter: DNS Records (Webhosting)
