Domains und SubdomainsRatgeber
Subdomain einrichten: DNS-Eintrag, Webserver und Zertifikat
Eine Subdomain richtest du in drei Schritten ein: Du legst in der DNS-Zone der Hauptdomain einen A-, AAAA- oder CNAME-Eintrag für den neuen Namen an, sagst dem Webserver, welche Inhalte er unter diesem Namen ausliefern soll, und besorgst ein Zertifikat für HTTPS. In Hosting-Oberflächen erledigt ein Formular oft alle drei Schritte.

Eine Subdomain wie shop.beispiel.de oder blog.beispiel.de ist ein eigener Name unterhalb deiner Domain. Du musst sie nicht extra registrieren, sie gehört dir mit der Domain. Damit sie funktioniert, müssen aber drei Dinge zusammenpassen: Das DNS muss den Namen auf einen Server zeigen lassen, der Server muss wissen, welche Inhalte er für diesen Namen ausliefert, und für HTTPS braucht es ein Zertifikat, das den Namen abdeckt. In vielen Hosting-Oberflächen erledigt ein einziges Formular alle drei Schritte. Wer versteht, was dahinter passiert, findet Fehler aber schneller. Was eine Subdomain grundsätzlich ist, steht unter Was ist eine Subdomain?.
Den Namen festlegen
Für den Namen der Subdomain gelten die Regeln des DNS. Jeder Namensteil zwischen zwei Punkten darf höchstens 63 Zeichen lang sein. Der ganze Name darf in der DNS-Darstellung höchstens 255 Byte lang sein, in der üblichen Schreibweise mit Punkten sind das 253 Zeichen [1]. Erlaubt sind Buchstaben, Ziffern und Bindestriche, und ein Namensteil soll mit einem Buchstaben oder einer Ziffer enden [1]. Kurze, sprechende Namen wie shop, hilfe oder termine sind leichter zu merken und zu tippen. Eine Subdomain kann selbst wieder Subdomains haben, etwa test.shop.beispiel.de. Das hat Folgen für Zertifikate, dazu weiter unten mehr.
Ob du für ein neues Angebot überhaupt eine Subdomain oder lieber ein Verzeichnis wie beispiel.de/shop/ nimmst, ist eine eigene Frage. Die Abwägung steht unter Subdomain oder Verzeichnis: was ist besser für SEO?.
Schritt 1: den DNS-Eintrag anlegen
Den Eintrag legst du in der DNS-Zone deiner Hauptdomain an, also dort, wo auch die Einträge für beispiel.de und www.beispiel.de stehen. Welchen Typ du wählst, hängt davon ab, wohin die Subdomain zeigen soll:

| Typ | Beispiel | Wann |
|---|---|---|
| A | shop.beispiel.de A 192.0.2.10 | Die Subdomain zeigt auf einen Server mit fester IPv4-Adresse. |
| AAAA | shop.beispiel.de AAAA 2001:db8::10 | Derselbe Server ist auch über IPv6 erreichbar. |
| CNAME | shop.beispiel.de CNAME shop.anbieter.example | Ein externer Dienst gibt dir einen Hostnamen vor, dessen Adresse er selbst verwaltet. |
Ein CNAME ist praktisch für Shops, Newsletter-Dienste oder Ticketsysteme, die ihre Server selbst verwalten. Er hat aber Regeln, etwa dass unter demselben Namen keine anderen Einträge stehen dürfen. Die Einzelheiten erklärt CNAME-Eintrag: wann er passt und wann nicht.
Achte darauf, für die Subdomain keinen NS-Eintrag anzulegen, wenn du sie nicht wirklich an andere Nameserver übergeben willst. Ein NS-Eintrag delegiert die Subdomain, und Einträge für sie in deiner Hauptzone gelten dann nicht mehr [2]. Solche Delegationen entstehen manchmal unbemerkt, wenn eine Subdomain in einer Hosting-Oberfläche als eigene Domain mit eigener Zone angelegt wird. Wie Plesk damit umgeht, steht unter Plesk: Domains, Subdomains und Zertifikate verwalten.
Willst du viele Subdomains auf denselben Server leiten, kann ein Wildcard-Eintrag wie *.beispiel.de die Arbeit abnehmen. Er hat eigene Tücken, die Wildcard-DNS: ein Eintrag für alle Subdomains beschreibt. Ob der neue Eintrag ausgeliefert wird, siehst du mit dem DNS-Check. Neue Namen sind meist schnell sichtbar. Hast du einen bestehenden Eintrag geändert, halten Resolver den alten Wert so lange fest, wie seine TTL erlaubt.
Schritt 2: den Webserver einrichten
Zeigt die Subdomain auf denselben Server wie deine Hauptdomain, muss der Webserver die Anfragen auseinanderhalten. Das geschieht über den Namen, den der Browser bei jeder Anfrage mitschickt. Apache nennt das namensbasierte virtuelle Hosts: Viele Namen teilen sich eine IP-Adresse, und der Server entscheidet anhand des Namens in der Anfrage, welche Konfiguration gilt [3].

Bei Apache legst du dafür einen eigenen VirtualHost-Block an. Mit ServerName gibst du den Namen der Subdomain an, mit DocumentRoot das Verzeichnis, aus dem die Inhalte kommen [3]. Die Apache-Dokumentation rät, in jedem dieser Blöcke ausdrücklich einen ServerName zu setzen [3]. Weitere Namen für dieselben Inhalte trägst du mit ServerAlias ein. Dort sind auch Namen mit Stern erlaubt, etwa *.beispiel.de. Jeder dieser Namen muss aber auch im DNS auf den Server zeigen [3].
Bei nginx übernimmt die Direktive server_name diese Aufgabe. nginx sucht zuerst nach einem exakt passenden Namen, dann nach dem längsten Namen mit Stern am Anfang, dann nach dem längsten mit Stern am Ende und zuletzt nach dem ersten passenden regulären Ausdruck [4]. Ein Name wie *.beispiel.de erfasst dabei www.beispiel.de und ebenso tiefere Namen wie www.sub.beispiel.de [4].
Findet der Server keinen passenden Block, liefert er die Inhalte eines Standard-Blocks aus. Bei Apache ist das der erste VirtualHost für die passende Adresse und den Port [3]. Bei nginx legst du den Standard mit default_server in der listen-Direktive fest [4].
In Hosting-Oberflächen wählst du meist nur den Namen und ein Verzeichnis. Die Oberfläche schreibt die Konfiguration dann selbst.
Schritt 3: ein Zertifikat für HTTPS
Ohne Zertifikat zeigt der Browser für die Subdomain eine Warnung. Das Zertifikat der Hauptdomain hilft nur, wenn es den Namen der Subdomain ausdrücklich enthält oder ein passendes Wildcard-Zertifikat ist. Kostenlose Zertifikate stellt Let's Encrypt aus. Die Prüfung, dass dir der Name gehört, läuft auf einem von zwei üblichen Wegen [5]:
- HTTP-01: Dein Server legt eine Datei unter http://shop.beispiel.de/.well-known/acme-challenge/ ab, die Let's Encrypt über Port 80 abruft. Damit sind keine Wildcard-Zertifikate möglich.
- DNS-01: Du oder dein Programm legt einen TXT-Eintrag unter _acme-challenge.shop.beispiel.de an. Das geht auch für Wildcards, ist automatisch aber nur sinnvoll, wenn dein DNS-Anbieter eine Schnittstelle dafür hat.
Für Wildcard-Zertifikate verlangt Let's Encrypt immer die DNS-Prüfung [6]. Ein Wildcard-Zertifikat für *.beispiel.de gilt nur für genau eine Ebene: Es passt zu shop.beispiel.de, nicht aber zu test.shop.beispiel.de. Nach RFC 9525 steht der Stern nur als ganzer erster Namensteil und deckt genau einen Namensteil ab [7]. Ob sich ein Wildcard-Zertifikat lohnt oder einzelne Zertifikate besser sind, erklärt SSL für Subdomains: Wildcard oder einzelne Zertifikate. Die Einrichtung selbst steht unter Let's Encrypt: kostenlose Zertifikate einrichten.
Zwei Einträge, die auch für Subdomains gelten
Hast du für deine Hauptdomain einen CAA-Eintrag gesetzt, der festlegt, welche Zertifizierungsstellen Zertifikate ausstellen dürfen, gilt er auch für die Subdomain. Die Stelle sucht nach RFC 8659 vom angefragten Namen aus nach oben, bis sie einen CAA-Eintrag findet [8]. Willst du für die Subdomain eine andere Stelle nutzen, braucht sie einen eigenen CAA-Eintrag.
Sendet deine Hauptdomain den Kopf Strict-Transport-Security mit includeSubDomains, gilt die HSTS-Regel auch für alle Subdomains [9]. Browser, die die Hauptdomain besucht haben, rufen die Subdomain dann nur noch über HTTPS auf. Eine Subdomain ohne gültiges Zertifikat ist für sie nicht erreichbar.
Subdomains sind öffentlich sichtbar
Ein Name, den du niemandem verrätst, bleibt trotzdem nicht lange unbekannt, sobald du ein Zertifikat für ihn ausstellen lässt. Let's Encrypt trägt jedes ausgestellte Zertifikat in die Certificate-Transparency-Protokolle ein [10]. Diese Protokolle sind öffentlich und sollen es jedem ermöglichen, die Ausstellung von Zertifikaten zu prüfen [11]. Wer will, kann dort die Namen deiner Subdomains nachlesen. Der Subdomain-Finder zeigt, welche Namen deiner Domain in diesen Protokollen stehen. Für eine Testumgebung reicht ein unbekannter Name deshalb nicht als Schutz. Sichere sie mit einem Passwort oder einer Sperre nach IP-Adresse.

Subdomains wieder abschalten
Brauchst du eine Subdomain nicht mehr, lösche auch ihren DNS-Eintrag. Das ist besonders wichtig bei CNAME-Einträgen, die auf einen externen Dienst zeigen. Microsoft beschreibt den Fall so: Ein Kunde löscht eine Cloud-Ressource, der CNAME bleibt stehen, und ein Dritter legt später eine Ressource mit demselben Hostnamen an. Der Verkehr für die Subdomain landet dann bei ihm [12]. Er kontrolliert die Inhalte, kann ein gültiges Zertifikat beantragen und so Cookies abgreifen, die für alle Subdomains gelten [12]. Microsoft empfiehlt, das Entfernen des DNS-Eintrags fest in die Abschaltung eines Dienstes einzuplanen [12].
Kurze Checkliste
- Namen nach den DNS-Regeln wählen.
- A-, AAAA- oder CNAME-Eintrag in der Zone der Hauptdomain anlegen, keinen NS-Eintrag.
- Mit dem DNS-Check prüfen, ob der Eintrag ausgeliefert wird.
- Im Webserver einen eigenen Block mit dem Namen der Subdomain und dem Verzeichnis anlegen.
- Zertifikat beantragen, CAA-Eintrag und HSTS-Regel der Hauptdomain beachten.
- Subdomain im Browser über HTTPS aufrufen.
- Soll sie in der Google-Suche erscheinen, in der Search Console prüfen. Eine Anleitung gibt es auf Google Search Console einrichten und nutzen.
- Gesetz RFC 1035: Domain Names, Implementation and Specification, Abschnitte 2.3.1 und 2.3.4. IETF. Stand November 1987. abgerufen am 29.10.2026
- Gesetz RFC 1034: Domain Names, Concepts and Facilities, Abschnitt 4.2. IETF. Stand November 1987. abgerufen am 29.10.2026
- Organisation Name-based Virtual Host Support, Apache HTTP Server 2.4. The Apache Software Foundation. Stand ohne Datum. abgerufen am 29.10.2026
- Organisation Server names. nginx. Stand ohne Datum. abgerufen am 29.10.2026
- Organisation Challenge Typen. Let's Encrypt. Stand 12.02.2026. abgerufen am 29.10.2026
- Organisation FAQ. Let's Encrypt. Stand 28.04.2025. abgerufen am 29.10.2026
- Gesetz RFC 9525: Service Identity in TLS, Abschnitt 6.3. IETF. Stand November 2023. abgerufen am 29.10.2026
- Gesetz RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. IETF. Stand November 2019. abgerufen am 29.10.2026
- Gesetz RFC 6797: HTTP Strict Transport Security (HSTS), Abschnitt 6.1.2. IETF. Stand November 2012. abgerufen am 29.10.2026
- Organisation Certificate Transparency (CT) Logs. Let's Encrypt. Stand 04.09.2026. abgerufen am 29.10.2026
- Gesetz RFC 9162: Certificate Transparency Version 2.0. IETF. Stand Dezember 2021. abgerufen am 29.10.2026
- Organisation Prevent dangling DNS entries and avoid subdomain takeover. Microsoft. Stand 20.07.2026. abgerufen am 29.10.2026
Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.
Weitere Artikel
DomainsDomain-EndungenLänderendung, .com oder .shop: Was die Domain-Endung für Zielgruppe, Google und die Registrierung bedeutet und welche …
DomainsUmlaut-Domains und PunycodeWie aus müller.de technisch xn--mller-kva.de wird, welche Zeichen bei .de erlaubt sind und was du bei E-Mail, Browsern und …
DomainsDomain registrierenWie du eine Domain registrierst oder eine vergebene kaufst, welche Regeln für Namen und Inhaberdaten gelten und welche …
HostingWebsite nicht erreichbarDeine Website lädt nicht? So grenzt du den Fehler ein: erst die Fehlermeldung lesen, dann DNS, Zertifikat und Server prüfen …