Eigene Domain für QR-Codes einrichten: CNAME, SSL und DNS erklärt

Was eine eigene Domain für eine QR-Weiterleitung tatsächlich bedeutet

Jeder dynamische QR-Code führt zunächst auf einen kurzen Weiterleitungslink, bevor er beim eigentlichen Ziel ankommt, und dieser Link liegt auf einer Domain. Scannen Sie einen Code der meisten QR-Plattformen, zeigt die Adresszeile die Shortener-Domain des Anbieters: etwas wie qrco.de, bit.ly oder bei ScanKit scankit.app/r/. Eine eigene Domain ersetzt diese Anbieter-Domain durch eine, die der Agentur (oder dem Kunden) bereits gehört, sodass die Weiterleitung stattdessen links.agentur.de oder qr.kundenmarke.de lautet.

Das ist nicht dasselbe wie dynamischer QR-Code gegenüber einem statischen. Dynamisch bedeutet lediglich, dass sich das Ziel hinter dem Code nach dem Druck noch ändern lässt. Eine eigene Domain ist eine separate, zusätzliche Ebene: Sie verändert, wie der Link selbst aussieht, auf jedem Gerät, mit dem jemand ihn vor oder nach dem Scannen betrachtet. Agenturen wollen meist beides gleichzeitig, denn die Frage eines Kunden "Warum leitet mein QR-Code über die Website eines anderen Anbieters um?" ist ein reales, wiederkehrendes Einwand-Thema in Verkaufsgesprächen, und es gibt darauf eine präzise technische Antwort.

Der Mechanismus dahinter ist derselbe wie bei jedem gebrandeten Link-Shortening-Produkt (Bitly, Rebrandly) und bei jedem White-Label-SaaS-Feature generell: Die Agentur zieht ihre QR-Plattform nicht auf einen neuen Server um, sondern richtet einen kleinen Teil ihrer eigenen Domain per DNS auf die bestehende Infrastruktur der Plattform aus.

Die DNS-Mechanik: ein CNAME-Eintrag, keine Domain-Übertragung

Eine eigene Domain für eine QR-Weiterleitung einzurichten ist eine DNS-Änderung, keine Hosting-Migration. Die Agentur legt in den DNS-Einstellungen ihrer Domain einen CNAME-Eintrag an, der eine Subdomain auf einen Hostnamen zeigen lässt, den die QR-Plattform vorgibt. Ein CNAME-Eintrag ist ein Alias: Er teilt dem Internet mit, dass Anfragen für links.agentur.de dorthin aufgelöst werden sollen, wohin auch edge.qrplattform.com auflöst. Es werden keine Dateien verschoben, kein Server wechselt den Besitzer, und die Hauptwebsite der Agentur auf derselben Domain bleibt unberührt.

Eine harte Einschränkung sollte man kennen, bevor man das bei irgendeinem Anbieter anfragt: Ein CNAME-Eintrag kann nicht am Zonen-Apex liegen, also der nackten Root-Domain (agentur.de ohne irgendetwas davor). Das ist keine Beschränkung eines bestimmten Anbieters, sondern eine strukturelle Regel in der DNS-Spezifikation selbst: Der Apex einer Domain muss einen SOA-Eintrag sowie NS-Einträge tragen, und ein Name mit einem CNAME darf gleichzeitig keinen anderen Eintragstyp tragen (RFC 1034, RFC 1912). Deshalb verlangt praktisch jede Einrichtung einer eigenen Domain, bei jedem SaaS-Produkt, das sie anbietet, eine Subdomain und nicht die nackte Domain.

Besteht eine Agentur darauf, die Root-Domain selbst statt einer Subdomain zu verwenden, ist die Lösung ein anbieterseitiges Feature, das meist ALIAS, ANAME oder CNAME-Flattening heißt (Cloudflare, AWS Route 53 und mehrere andere DNS-Hoster unterstützen es unter unterschiedlichen Namen). Es löst das Ziel auf den eigenen Servern des Anbieters auf und liefert einen synthetisierten A-Eintrag zurück, sodass am Apex tatsächlich kein CNAME liegt und die DNS-Regel nie verletzt wird. Es lohnt sich, das zu wissen, denn es ist die Antwort auf die Frage "Können wir agentur.de statt links.agentur.de verwenden", hängt aber vollständig davon ab, welches Unternehmen die DNS der Agentur hostet, nicht von der QR-Plattform.

Der häufigste Einrichtungsfehler ist nicht exotisch: ein veralteter A-Eintrag, der bereits auf der Subdomain liegt, die die Agentur verwenden möchte (oft ein Überbleibsel einer alten Weiterleitung oder einer vergessenen Testseite). Da ein Name nicht gleichzeitig einen CNAME- und einen A-Eintrag tragen kann, schlägt das Anlegen des neuen CNAME fehl oder wirkt sich still nicht aus, bis der alte Eintrag zuerst gelöscht wird.

SSL: Das Zertifikat muss pro Domain bereitgestellt werden

Ein funktionierender CNAME ist nur die halbe Miete für eine funktionierende eigene Domain. Jede dieser Domains braucht außerdem ein gültiges TLS-Zertifikat, sonst zeigt der Browser statt einer Weiterleitung eine Sicherheitswarnung an. Früher bedeutete das, pro Domain ein Zertifikat zu kaufen und manuell zu installieren, was eigene Domains für eine QR-Plattform, die viele Agenturen mit jeweils eigenen Kunden-Subdomains bedient, unpraktikabel machte.

Der moderne Standard ist automatisiert: Let's Encrypt stellt kostenlose Zertifikate über das ACME-Protokoll aus, das den Domainbesitz durch eine "Challenge" nachweist, bevor irgendetwas ausgestellt wird. In der Praxis gibt es zwei Challenge-Typen. HTTP-01 legt eine Token-Datei unter einem bestimmten Pfad auf der Domain ab; das ist einfach, kann aber kein Wildcard-Zertifikat ausstellen und benötigt einen erreichbaren Port 80. DNS-01 verlangt stattdessen, einen bestimmten TXT-Eintrag zu veröffentlichen; es ist die einzige Methode, die ein Wildcard validieren kann, und sie funktioniert auch, wenn die Domain über keinen eigenen Webserver verfügt, was gut zu einer reinen Weiterleitungs-Subdomain passt.

Für eine Plattform, die eigene Domains gleichzeitig für viele verschiedene Kunden einrichtet, ist das praktische Muster (verwendet von Cloudflare for SaaS und ähnlichen Multi-Tenant-Setups), diese ACME-Challenge im Auftrag des Kunden zu automatisieren, sobald der CNAME verifiziert ist, sodass das Zertifikat ausgestellt und erneuert wird, ohne dass die Agentur über den ursprünglichen DNS-Eintrag hinaus etwas tun muss. Enthält die DNS-Zone einer Domain einen CAA-Eintrag, der einschränkt, welche Zertifizierungsstellen für sie ausstellen dürfen, muss dieser Eintrag den verwendeten Aussteller (Let's Encrypt oder welche CA die Plattform auch nutzt) ausdrücklich erlauben, sonst schlägt die Ausstellung fehl, selbst bei einem völlig korrekten CNAME.

1. Ein Scan öffnet den gebrandeten Weiterleitungslink auf dem Smartphone des Besuchers.
2. DNS löst den CNAME auf und richtet die eigene Domain auf die QR-Plattform aus.
3. Das TLS-Zertifikat der Plattform für diese Domain wird geprüft, bevor irgendetwas lädt.
4. Der Besucher landet auf der echten, vorgesehenen Zielseite.

Wie lange es tatsächlich dauert

"Bis zu 48 Stunden" ist die Zahl, die überall für die DNS-Propagierung wiederholt wird, und sie stimmt als Worst-Case-Obergrenze technisch, überzeichnet aber den typischen Fall so stark, dass es irreführend ist. Die Verzögerung, die Nutzer tatsächlich erleben, ist Caching: Jeder DNS-Eintrag hat eine TTL (Time to Live), die Resolvern mitteilt, wie lange sie die alte Antwort noch ausliefern dürfen, bevor sie erneut nachfragen. Sobald eine Änderung die autoritativen Nameserver erreicht, ist sie fast sofort verfügbar; was Zeit kostet, ist, dass jeder Resolver im Internet, der den alten Eintrag bereits zwischengespeichert hat, dessen TTL abwarten muss.

In der Praxis bedeutet eine niedrige TTL (üblicher Standard sind 300 Sekunden, fünf Minuten), dass der Großteil des Internets eine DNS-Änderung innerhalb von Minuten sieht, nicht Tagen. Der realistische Rat für eine Domain-Umstellung: Prüfen Sie die aktuelle TTL des Eintrags, bevor Sie die Änderung vornehmen, und ist sie hoch eingestellt (ein Tag oder mehr), senken Sie sie einen Tag vorher ab, damit die eigentliche Umstellung schnell propagiert, und setzen Sie sie danach wieder hoch. Die 24-bis-48-Stunden-Zahl spiegelt größtenteils alte Konfigurationen mit hoher TTL und Worst-Case-Verarbeitungsfenster der Registrare wider, nicht das, was bei einem gut vorbereiteten modernen DNS-Setup passiert.

Hilft eine gebrandete Domain tatsächlich, und ist sie ein Sicherheitsfeature?

In den meisten Marketingtexten zu eigenen Domains werden zwei getrennte Behauptungen vermischt, und es lohnt sich, sie auseinanderzuziehen.

Die Behauptung zur Markenkonsistenz ist unkompliziert und zutreffend: Ein Link, der qr.kundenmarke.de lautet, wirkt, als gehöre er zum Kunden, und ein Link, der über einen unbekannten Anbieter-Shortener läuft, wirkt, als gehöre er einem Dritten, weil das eben stimmt. Für einen Kunden, der eine Agentur für die Durchführung seiner Kampagne bezahlt, ist diese optische Konsistenz ein reales, nachvollziehbares Anliegen, unabhängig von allem, was am Scan-Verhalten messbar wäre.

Die SEO-Behauptung ist schwächer, als sie klingt. Google hat seit Jahren erklärt, direkt vom eigenen Search-Central-Team, dass Subdomains und Unterverzeichnisse für Ranking-Zwecke gleich behandelt werden und dass Googles Systeme eine Subdomain mit ihrer übergeordneten Domain verknüpfen, statt sie zu benachteiligen. Für eine QR-Weiterleitung im Speziellen spielt das ohnehin kaum eine Rolle: Der Weiterleitungslink selbst ist kein Inhalt, den irgendjemand indexiert und gerankt sehen möchte, er ist eine Routing-Ebene, die den Besucher sofort woandershin schickt. Jeder SEO-Vorteil, der einer eigenen QR-Domain zugeschrieben wird, betrifft in Wahrheit das Markenvertrauen, nicht das Suchranking.

Die Sicherheits-Behauptung ist diejenige, bei der Präzision wichtig ist, denn sie wirkt in beide Richtungen. Eine verifizierte, per DNS und TLS bestätigte Domain, die eine Agentur tatsächlich kontrolliert, ist vertrauenswürdiger als ein generischer Shortener, aus einem konkreten Grund: Sie ist konsistent und überprüfbar, nicht weil gebrandet wirkende URLs von Natur aus sicher wären. Die Verbraucherhinweise der US-Behörde FTC zu QR-Code-Betrug besagen ausdrücklich, dass man die tatsächliche Ziel-URL prüfen sollte, bevor man einem Scan vertraut, gerade weil Angreifer optische Vertrauenssignale ausnutzen. Sicherheitsforscher haben "Quishing"-Kampagnen dokumentiert, bei denen genau aus diesem Grund überzeugende Doppelgänger-Domains registriert werden: Eine Domain, die aussieht, als gehöre sie zu einer vertrauenswürdigen Marke, ist genau das, was einen gefälschten QR-Code überhaupt erst überzeugend macht, kein Schutz dagegen. Wie sich dieses Risiko speziell bei Druckkampagnen auswirkt, lesen Sie in unserem Leitfaden zur QR-Code-Sicherheit für Agenturen. Die ehrliche Einordnung: Eine eigene Domain verdient Vertrauen, weil sie die eigene, überprüfbare Domain der Agentur unter deren eigener DNS-Kontrolle ist, und diese Disziplin (DNS-Einträge prüfen, Zertifikate erneuern, eine Domain nicht auslaufen lassen) ist es, was einen Kunden tatsächlich schützt, nicht das Branding für sich genommen.

Aus Agentursicht: eine Plattform, viele Kundendomains

Für eine Agentur, die QR-Kampagnen für mehrere Kunden betreibt, sind eigene Domains keine einmalige Einrichtung, sondern eine Pro-Kunde-Konfiguration, die sauber neben der Art passen muss, wie die Agentur bereits Kunden-Workspaces organisiert. Eine Plattform, die eigene Domains für Agenturen gut unterstützt, sollte es ermöglichen, dass die Codes jedes Kunden über dessen eigene Domain (oder die der Agentur, je nach Vertrag) weiterleiten, ohne dass sich die Domains gegenseitig stören, da jede von ihnen ein unabhängiger CNAME plus ein unabhängig bereitgestelltes Zertifikat ist.

Das hat eine vertragliche Dimension, die leicht übersehen wird, bis sie zum Problem wird: Wessen Domain auch immer die Weiterleitung läuft, diese Partei kontrolliert den Link faktisch. Leiten die QR-Codes eines Kunden über eine Subdomain um, die dem Kunden gehört, und endet die Beziehung, muss die Agentur den DNS-Eintrag entfernen oder umleiten lassen, sonst kann der Kunde einfach übernehmen, was der Code als Nächstes tut, indem er ändert, wohin seine eigene Subdomain zeigt, selbst bei einem Code, der physisch gedruckt und bereits im Umlauf ist. Agenturen, die aus diesem Grund kundeneigene Domains verwenden, sollten schriftlich festhalten, was mit dem DNS-Eintrag am Vertragsende passiert, genauso wie sie festlegen würden, wer den Zugang zu den Analysen behält. Wird stattdessen die eigene Domain der Agentur verwendet (links.agenturname.de, über verschiedene Kunden hinweg geteilt via unterschiedlicher Unterpfade oder Workspace-gebundener UTM-Parameter), entsteht diese Unklarheit nicht, allerdings um den Preis, dass die Weiterleitung nicht die Marke des einzelnen Kunden trägt.

Eine Checkliste, bevor Sie eine eigene Domain bei einer QR-Plattform anfragen

Bevor Sie einen Anbieter, gleich welcher Art, bitten, eine eigene Domain einzurichten, lohnt es sich, auf eine kurze Liste von Fragen bereits Antworten zu haben, denn genau hier zeigen sich die Unterschiede zwischen Plattformen mehr als fast überall sonst:

• Nur Subdomain oder auch Root-Domain? Klären Sie, ob die Plattform nur einen CNAME akzeptiert (also eine Subdomain) oder ob sie ALIAS/CNAME-Flattening für eine nackte Root-Domain über Ihren konkreten DNS-Host unterstützt.
• Ist das TLS-Zertifikat automatisch? Das sollte es sein, sobald der CNAME verifiziert ist. Verlangt ein Anbieter, eine Zertifikatsdatei manuell hochzuladen, ist das ein Zeichen für ein älteres, weniger automatisiertes Setup, das aufwendiger zu pflegen ist.
• Wie lange dauert die Einrichtung voraussichtlich? Bei einem korrekt vorbereiteten DNS-Eintrag und niedriger TTL sollte die Domain innerhalb einer Stunde live sein, nicht erst nach Tagen. Dauert es länger, liegt das meist an einem manuellen Prüfschritt beim Anbieter, nicht an einer DNS-Beschränkung.
• Muss die Domain dediziert sein, oder darf sie auch anderes hosten? Eine Subdomain, die ausschließlich für QR-Weiterleitungen genutzt wird (qr.kundenmarke.de), vermeidet jeden Konflikt mit bestehenden Einträgen; eine Subdomain wiederzuverwenden, die bereits anderen Traffic bedient, ist der Punkt, an dem Konflikte mit veralteten Einträgen entstehen.
• Wem gehört der DNS-Eintrag vertraglich? Legen Sie schriftlich fest, ob es die Domain der Agentur oder die des Kunden ist, und was mit dem Eintrag passiert, wenn die Beziehung endet.
• Zeigt die Plattform einen Sicherheitswarnpfad, falls das Zertifikat einmal nicht erneuert wird? Zertifikate erneuern sich automatisch über ACME, aber später vorgenommene DNS- oder CAA-Änderungen (durch jemanden, der von der eigenen Domain-Einrichtung nichts weiß) können die Erneuerung Monate nach der ursprünglich erfolgreichen Einrichtung still zunichtemachen.

Häufige Fehlerbilder und wie man sie einordnet

Die meisten Probleme mit eigenen Domains lassen sich auf eine kleine Zahl von Ursachen zurückführen, und zu erkennen, welche das ist, geht schneller als zu raten.

"CNAME konnte nicht hinzugefügt werden" oder der Eintrag scheint nicht zu wirken. Fast immer ein übrig gebliebener A-, AAAA- oder anderer Eintrag, der bereits genau auf dieser Subdomain liegt. Löschen Sie ihn zuerst; ein Name kann keinen CNAME neben irgendetwas anderem tragen.

Die Domain löst auf, aber der Browser zeigt eine Zertifikatswarnung. Entweder ist das Zertifikat noch nicht fertig bereitgestellt (prüfen Sie erneut, nachdem der CNAME Zeit hatte, sich zu verifizieren), oder ein CAA-Eintrag auf der Domain blockiert die von der Plattform genutzte Zertifizierungsstelle. Prüfen Sie den CAA-Eintrag, falls vorhanden; er muss die ausstellende CA ausdrücklich erlauben.

Es funktionierte, brach dann Wochen später ohne Änderungen auf Plattformseite zusammen. Die häufigste Ursache ist, dass jemand anderes im Team die DNS aus einem unabhängigen Grund bearbeitet hat (einen Mail-Eintrag hinzugefügt, den Registrar gewechselt) und dabei unabsichtlich dieselbe Zone berührt hat, oder ein später für einen anderen Zweck hinzugefügter CAA-Eintrag, der jetzt die Zertifikatserneuerung blockiert. Deshalb lohnt es sich, den DNS-Eintrag für eine eigene QR-Domain irgendwo zu dokumentieren, wo das ganze Team ihn sehen kann, nicht nur im Dashboard des Anbieters.

Anfragen für Wildcard-Zertifikate schlagen fehl. Wildcards lassen sich nur über den DNS-01-Challenge-Typ (einen TXT-Eintrag) validieren, niemals über HTTP-01. Unterstützt der Custom-Domain-Ablauf einer Plattform keine DNS-01-Validierung, kann sie strukturell kein Wildcard anbieten, sondern nur einzelne Subdomains, jeweils ein CNAME und ein Zertifikat.

Häufig gestellte Fragen

Wie lange dauert die DNS-Propagierung bei einer eigenen QR-Code-Domain?

Bei einem korrekt vorbereiteten, niedrig eingestellten TTL-Wert sieht der Großteil des Internets die Änderung innerhalb von Minuten, sobald sie die autoritativen Nameserver erreicht hat. Die oft zitierten "bis zu 48 Stunden" sind eine Worst-Case-Obergrenze aus alten Setups mit hoher TTL und Verarbeitungsfenstern der Registrare, kein typisches Ergebnis bei einem modernen Setup.

Brauche ich ein eigenes SSL-Zertifikat für eine eigene QR-Code-Domain?

Nein, nicht bei einer sauber gebauten Plattform. Zertifikate für kundeneigene Domains werden automatisch über das ACME-Protokoll ausgestellt (dasselbe System hinter Let's Encrypt), sobald der CNAME verifiziert ist, und sie erneuern sich automatisch. Wenn Sie gebeten werden, eine Zertifikatsdatei manuell hochzuladen, ist das ein Zeichen für ein älteres, anfälligeres Setup.

Kann ich die Domain meines Kunden statt der eigenen Agentur-Domain verwenden?

Ja, technisch funktioniert es genau gleich: Der CNAME liegt in der DNS derjenigen Domain, in der der Eintrag angelegt wird. Die Entscheidung ist vertraglich, nicht technisch, und es lohnt sich, schriftlich festzuhalten, was mit diesem DNS-Eintrag passiert, wenn die Agenturbeziehung zu diesem Kunden endet.

Schadet eine Subdomain meinem SEO im Vergleich zur Hauptdomain?

Nicht bei einem QR-Weiterleitungslink im Speziellen. Google behandelt Subdomains und Unterverzeichnisse beim Ranking gleich, und ein Weiterleitungslink ist kein Inhalt, der aus eigener Kraft ranken muss; er muss lediglich vertrauenswürdig aussehen und zuverlässig funktionieren.

Schützt eine gebrandete Domain wirklich vor QR-Code-Phishing (Quishing)?

Nicht von allein. Eine Domain, die eine Agentur tatsächlich kontrolliert und verifiziert hält, ist vertrauenswürdiger als ein generischer Shortener, aber Angreifer registrieren gezielt überzeugende Marken-Doppelgänger-Domains, um genau diese Art von optischem Vertrauen auszunutzen. Der eigentliche Schutz ist die DNS- und Zertifikatshygiene, die die Agentur tatsächlich pflegt, plus Empfänger, die die Ziel-URL prüfen, nicht das bloße Vorhandensein einer eigenen Domain.

Kann ich die reine Root-Domain wie agentur.de statt einer Subdomain nutzen?

Nur, wenn Ihr DNS-Host ein ALIAS-, ANAME- oder CNAME-Flattening-Feature unterstützt, denn ein reiner CNAME-Eintrag kann laut DNS-Spezifikation nicht an der Root-Domain liegen. Die meisten Agenturen verwenden stattdessen eine Subdomain (links.agentur.de), gerade um diesen Umweg zu vermeiden.

Was ist der Unterschied zwischen einer eigenen Domain und einer White-Label-QR-Plattform?

Eine eigene Domain verändert, wie die URL des Weiterleitungslinks aussieht. White-Labeling ist breiter gefasst: Es kann auch bedeuten, das Branding des Anbieters von der Weiterleitungsseite selbst, aus kundenseitigen Berichten oder aus dem Dashboard zu entfernen, das der Kunde sieht. Eine Plattform kann das eine ohne das andere anbieten, daher lohnt es sich, beides zu prüfen, wenn Markenkonsistenz für das gesamte Kundenerlebnis wichtig ist, nicht nur für den Link.

Kann eine Agentur für verschiedene Kunden unterschiedliche Domains im selben Account nutzen?

Ja, das ist das normale Agenturmuster: Die Codes jedes Kunden leiten über dessen eigene Subdomain um (oder eine gemeinsam genutzte Agentur-Subdomain, je nach Vertrag), jeweils als unabhängiger CNAME und unabhängiges Zertifikat konfiguriert, ohne das Setup eines anderen Kunden im selben Account zu beeinträchtigen.

Die Kurzfassung

Eine eigene Domain für eine QR-Weiterleitung ist eine DNS-Änderung, keine Plattform-Migration: ein CNAME-Eintrag, der eine Subdomain auf die QR-Plattform zeigen lässt, mit einem TLS-Zertifikat, das eine gut gebaute Plattform automatisch über das ACME-Protokoll bereitstellt und erneuert. Sie geht typischerweise innerhalb einer Stunde live, sobald der Eintrag korrekt vorbereitet ist, nicht erst nach den sprichwörtlichen 48 Stunden. Sie hilft echt beim kundenseitigen Markenvertrauen und bei der vertraglichen Klarheit darüber, wer den Link kontrolliert; für SEO bringt sie im Grunde nichts, und sie ist für sich genommen kein Schutz gegen QR-Phishing, da Angreifer genau das optische Vertrauen ausnutzen, auf das auch eine legitime gebrandete Domain setzt. Bevor Sie eine bei irgendeinem Anbieter anfragen, sollten Agenturen klären, ob Root-Domain-Nutzung unterstützt wird, ob das Zertifikat automatisch ist, und wem der DNS-Eintrag vertraglich gehört, sobald eine Kundenbeziehung endet.