Registrierungsdatum einer Domain abfragen: Wann wurde eine Domain registriert?

Herauszufinden, wann eine Domain erstmals registriert wurde, ist eine kleine Aufgabe mit überraschend vielen Sonderfällen. Bei einer .com genügt ein einziger Befehl. Bei vielen länderspezifischen Domains wird die Antwort überhaupt nicht veröffentlicht, und bei einer Domain, die den Besitzer gewechselt hat, bedeutet das zurückgelieferte Datum womöglich nicht das, was Sie annehmen. Dieser Leitfaden zeigt, wie Sie die Abfrage sauber durchführen, wie Sie das Ergebnis lesen und was zu tun ist, wenn die Registry nichts liefert.

TL;DR / DIE WICHTIGSTEN PUNKTE

• Zwei Protokolle beantworten die Frage: WHOIS (Text, veraltet) und RDAP (JSON, aktuell). Für alles Skriptgesteuerte ist RDAP die bessere Wahl.
• Der Feldname variiert: „Creation Date“, „Created On“, „registered“, „Domain Registration Date“ — in RDAP ist es das Ereignis mit eventAction: "registration".
• Nicht jede Registry veröffentlicht ihn: Viele ccTLDs lassen Erstellungsdaten komplett weg, und manche betreiben gar keinen RDAP-Server, was zur Fehlermeldung „no registry RDAP server was identified“ führt.
• Das Datum beschreibt den Registrierungseintrag, nicht das Unternehmen: Transfers, Löschungen und Neuregistrierungen können es zurücksetzen, und ein Rebranding kappt die Verbindung zur Organisation vollständig.
• Massenabfragen sind über WHOIS/RDAP nicht praktikabel: Registries drosseln pro IP, und beide Protokolle beantworten konstruktionsbedingt immer nur eine Domain.
• Für Auswertungen auf Gesamtbestandsebene eignen sich Zonendaten: 1,538 Pakete — 716 TLD-Zonendateien, 716 angereicherte Zonensätze (NS, MX, IP, CMS), 79 Technologie-Listen, 27 kuratierte Datensätze — mit 285,582,781 Domains. Registrierungsdaten sind nur dort enthalten, wo die Quellzone sie veröffentlicht.
• Keine Kontaktdaten: Die Pakete enthalten ausschließlich Domain- und Infrastrukturattribute.

INHALTSVERZEICHNIS

1. Warum das Registrierungsdatum gefragt ist
2. So fragen Sie ein Registrierungsdatum ab
3. Was das Datum aussagt – und was nicht
4. Arbeiten auf Gesamtbestandsebene
5. Häufige Fehler
6. Häufig gestellte Fragen
7. Fazit
8. Weiterführende Ressourcen

Warum das Registrierungsdatum gefragt ist

Das Erstellungsdatum einer Domain ist eine der wenigen Registrierungsangaben, die die Schwärzung der WHOIS-Einträge nach der DSGVO überlebt haben – auch deshalb wird es so intensiv genutzt. Kontaktfelder sind verschwunden; Datumsangaben, Registrar und Nameserver bleiben.

Drei Fragestellungen machen den Großteil der Abfragen aus. Die erste ist die Verifizierung: Eine Website gibt an, seit 2009 aktiv zu sein – ein Erstellungsdatum von 2021 ist Anlass für eine Rückfrage. Die zweite ist die Risikobewertung: Domains, die erst vor wenigen Tagen registriert wurden, sind bei Phishing und Betrug überproportional vertreten, weshalb das Alter häufig in einen Risiko-Score einfließt, für sich genommen aber nur schwach aussagt. Die dritte ist der Domain-Kauf: Wer einen abgelaufenen oder auf dem Zweitmarkt angebotenen Namen bewertet, nutzt das Registrierungsalter als eines von mehreren Signalen dafür, ob der Name eine Historie mitbringt, die zu übernehmen sich lohnt.

Allen drei Fällen ist gemeinsam, dass das Datum ein Eingangswert ist, keine Schlussfolgerung. Es sagt Ihnen, wann ein Registrierungseintrag begonnen hat. Alles Weitere – wer die Domain betrieben hat, was darauf veröffentlicht wurde, ob sie den Besitzer gewechselt hat – erfordert andere Belege.

So fragen Sie ein Registrierungsdatum ab

RDAP, das aktuelle Protokoll. RDAP liefert JSON, sodass kein Freitext geparst werden muss. Das Datum steht im Array events:

curl -s https://rdap.org/domain/example.com | jq '.events[] | select(.eventAction=="registration")'

rdap.org fungiert als Bootstrap-Weiterleitung: Der Dienst ermittelt über die IANA-Registry den autoritativen Server der TLD und leitet die Anfrage dorthin weiter. Die Antwort enthält außerdem die Ereignisse expiration und last changed, den zuständigen Registrar sowie die Statuscodes der Domain.

WHOIS, das ältere Protokoll. Nach wie vor allgegenwärtig und weiterhin nützlich, insbesondere bei ccTLDs, die RDAP nie eingeführt haben:

whois example.com | grep -i -E 'creat|regist'

Rechnen Sie mit Abweichungen. Verschiedene Registries benennen dasselbe Feld „Creation Date“, „Created On“, „created“, „Domain Registration Date“ oder „registered“, und auch die Datumsformate unterscheiden sich. Jeder Parser, den Sie schreiben, muss mehrere Schreibweisen sowie mindestens ISO-8601 und einige regionale Formate verarbeiten können.

Ein ccTLD-Beispiel. Nehmen wir aajtak.in. Der .in-Namensraum wird von NIXI verwaltet, eine Abfrage geht daher an dessen WHOIS-Dienst:

whois aajtak.in

In der Regel erhalten Sie Erstellungs-, Aktualisierungs- und Ablaufdatum, den zuständigen Registrar, Statuscodes und Nameserver, während der Kontaktblock des Inhabers geschwärzt ist. Dieses Muster – technische Felder vorhanden, Kontaktfelder zurückgehalten – ist heute bei gTLDs wie auch bei den meisten ccTLDs der Normalfall.

Wenn es keinen RDAP-Server gibt. Die Fehlermeldung „no registry RDAP server was identified for this domain“ bedeutet, dass die TLD keinen Eintrag in der IANA-Bootstrap-Registry hat und ein RDAP-Client die Anfrage folglich nirgendwohin senden kann. Für gTLDs ist RDAP vertraglich vorgeschrieben, für ccTLDs dagegen optional, da diese nach nationalen Vorgaben betrieben werden. Weichen Sie für diese TLD auf WHOIS oder die Weboberfläche der Registry aus. Ein erneuter RDAP-Versuch hilft nicht – der Endpunkt existiert schlicht nicht.

Wenn das Datum überhaupt nicht veröffentlicht wird. Einige Registries lassen Erstellungsdaten bewusst aus ihren öffentlichen Antworten weg. Dann bleiben nur indirekte Alternativen, von denen keine autoritativ ist: Die früheste Erfassung in der Wayback Machine des Internet Archive liefert eine Obergrenze dafür, ab wann die Website live war, und der früheste Eintrag in den Certificate-Transparency-Logs zum Hostnamen zeigt, wann erstmals ein Zertifikat ausgestellt wurde. Beides ergibt Belege im Sinne von „spätestens seit“, was oft ausreicht – das Registrierungsdatum ist aber weder das eine noch das andere.

Was das Datum aussagt – und was nicht

Es spiegelt den Registrierungseintrag wider, nicht die Organisation

Ein 2003 gegründetes Unternehmen kann eine Domain halten, die 2018 angelegt wurde – weil es sich umbenannt, einen besseren Namen gekauft oder mehrere Auftritte zusammengeführt hat. Eine 2003 angelegte Domain kann heute in ganz anderen Händen liegen. Das Datum ist eine Eigenschaft des Eintrags, und der Eintrag übersteht Besitzerwechsel, ohne sie zwangsläufig auszuweisen.

Löschung und Neuregistrierung setzen es zurück

Läuft eine Domain ab, durchläuft sie Redemption und Pending Delete und wird anschließend von jemand anderem neu registriert, zeigt der Eintrag üblicherweise das neue Erstellungsdatum. Das frühere Leben der Domain ist im aktuellen Eintrag unsichtbar. Am stärksten wiegt das bei der Bewertung von Zweitmarkt-Namen: Ein Name, der als „registriert seit 2006“ angeboten wird, kann zwischenzeitlich verfallen und neu gestartet sein.

Das Alter allein ist ein schwaches Risikosignal

Neu registrierte Domains sind bei Missbrauch überrepräsentiert, was das Alter zu einem sinnvollen Merkmal in einem Scoring-Modell macht. Als isolierte Regel taugt es wenig, denn auch jedes seriöse neue Unternehmen hat eine frisch registrierte Domain. Kombinieren Sie es mit Signalen, die eigenständige Information tragen: ob die Domain auflöst, ob E-Mail konfiguriert ist, in welchem Hosting-Netz sie liegt, ob überhaupt eine echte Website ausgeliefert wird.

Domain-Alter ist kein SEO-Rankingfaktor in der oft beschriebenen Form

Suchmaschinen betonen durchgängig, dass das Domain-Alter für sich genommen kein Ranking-Signal ist. Was mit dem Alter korreliert, ist die über die Zeit angesammelte Historie aus Links, Inhalten und Nutzung – ein realer Effekt, der aber davon abhängt, was die Domain geleistet hat, nicht davon, wie lange sie existiert. Eine alte Domain, auf der nie etwas veröffentlicht wurde, bringt nichts davon mit.

Was es sauber belegt

Ein Erstellungsdatum ist ein belastbarer Nachweis für genau eine eng gefasste Aussage: Dieser Registrierungseintrag existierte vor diesem Datum nicht. Das reicht, um eine „gegründet seit“-Angabe zu widerlegen, um in einer Untersuchung einen Zeitraum einzugrenzen oder um beim Clustern einer Kampagne Domains zu isolieren, die in einem bestimmten Zeitfenster registriert wurden.

Arbeiten auf Gesamtbestandsebene

Alles bisher Gesagte betrifft eine einzelne Domain. Sobald es um viele Domains geht – wie viele davon im letzten Quartal in einer Zone registriert wurden, welche Hosting-Netze die neuesten Domains nutzen –, scheiden WHOIS und RDAP aus. Beide beantworten eine Domain pro Anfrage, Registries drosseln pro IP, und ein Job über auch nur hunderttausend Domains wird lange vor dem Ende ausgebremst.

Die Alternative sind Daten auf Zonenebene, die als Dateien ausgeliefert werden. Der Katalog von WebTrackly umfasst 1,538 Pakete: 716 TLD-Zonendateien, 716 angereicherte Zonensätze mit Nameservern, MX-Einträgen, aufgelösten IPs und erkanntem CMS, 79 Technologie-Listen und 27 kuratierte Datensätze. Zusammen decken die Zonenpakete 285,582,781 Domains ab, davon 163,422,083 .com; der Datensatz aller registrierten Domains enthält 272,614,863 Zeilen. WordPress wird auf 21,639,326 Domains erkannt, Joomla auf 567,680.

Was ein Paket enthält

Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.

Registrierungsdaten erscheinen nur dort, wo die Quellzone sie veröffentlicht – bei vielen ccTLDs sind sie nicht verfügbar, und die Spalte fehlt dann, statt geschätzt zu werden. Es gibt weder eine Spalte für Domaininhaber noch eine für Kontaktdaten: keine E-Mail-Adressen, keine Telefonnummern, keinerlei personenbezogene Daten.

Registrierungsaktivität ohne Datumsspalte ableiten

Fehlen Datumsangaben, lässt sich Registrierungsaktivität dennoch messen – über den Vergleich von Snapshots. Kaufen Sie dasselbe Paket zu zwei Zeitpunkten: Die Domains, die in der neueren Datei stehen, in der älteren aber nicht, sind genau die im Zwischenraum registrierten:

-- domains added between two snapshots
SELECT n.domain, n.ns, n.mx
FROM read_csv_auto('snapshots/com-2026-07-01.csv') n
LEFT JOIN read_csv_auto('snapshots/com-2026-04-01.csv') o USING (domain)
WHERE o.domain IS NULL;

-- and which name servers the new registrations chose
SELECT ns, count(*) AS new_domains
FROM (
  SELECT n.domain, n.ns
  FROM read_csv_auto('snapshots/com-2026-07-01.csv') n
  LEFT JOIN read_csv_auto('snapshots/com-2026-04-01.csv') o USING (domain)
  WHERE o.domain IS NULL
)
GROUP BY ns ORDER BY new_domains DESC LIMIT 20;

Für die Fragen, die tatsächlich gestellt werden, ist das oft besser als eine Datumsspalte, weil die Infrastrukturattribute gleich mitkommen. Voraussetzung ist lediglich, dass Sie jede heruntergeladene Datei aufbewahren und mit Datum versehen.

So kommen Sie an die Dateien

Unter /zones/ finden Sie Zonendateien und angereicherte Sätze, unter /datasets/ kuratierte Sammlungen und unter /packages/ den vollständigen Katalog; die Zeilenzahlen werden vor dem Kauf angezeigt. Pakete beginnen bei $3.50 und stehen sofort zum Download bereit, exportiert werden sie frisch im Moment des Kaufs. Pro kostet $29/Monat (50 Pakete, 10 Datensätze, 30,000 API-Aufrufe), Enterprise $99/Monat (200 Pakete, 50 Datensätze, 300,000 API-Aufrufe) – siehe /pricing/.

unzip com-enriched.zip
head -3 com-enriched.csv
wc -l com-enriched.csv

# list zone-file packages via the API
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

# technology packages matching a keyword
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

Die API erschließt den Paketkatalog – was es gibt, was es kostet, wie viele Zeilen enthalten sind. Sie nimmt keinen Domainnamen entgegen und liefert auch keine Fakten dazu; Registrierungsdaten je Domain kommen aus WHOIS oder RDAP. Referenz unter /api/.

Häufige Fehler

Fehler 1: Das Erstellungsdatum als Gründungsdatum des Unternehmens lesen

Der Eintrag beschreibt die Registrierung, nicht die Organisation. Rebrandings, Zweitmarktkäufe und Konsolidierungen kappen diese Verbindung. Gleichen Sie mit einem Handelsregister oder der Unternehmenshistorie der Website ab, bevor Sie eine Aussage über das Unternehmen treffen.

Fehler 2: Annehmen, dass jede Registry das Datum veröffentlicht

Mehrere ccTLDs lassen Erstellungsdaten vollständig aus ihren öffentlichen Antworten weg. Dann liefern Wayback-Erfassungen und Certificate-Transparency-Einträge eine „spätestens seit“-Grenze – nützlich, aber eben nicht das Registrierungsdatum, und sie sollte auch nicht als solches dargestellt werden.

Fehler 3: Erneut anfragen, wenn RDAP keinen Server meldet

„No registry RDAP server was identified for this domain“ bedeutet, dass die TLD in der IANA-Bootstrap-Registry fehlt. Es gibt keinen Endpunkt, den man erreichen könnte. Weichen Sie für diese TLD auf WHOIS aus, statt eine Retry-Logik einzubauen.

Fehler 4: Eine Massenpipeline auf Einzelabfragen aufbauen

Registries drosseln nach IP, und beide Protokolle arbeiten konstruktionsbedingt domainweise. Ein großer Job wird ausgebremst und liefert unvollständige Ergebnisse, mit denen sich keine Prozentaussagen treffen lassen. Nehmen Sie den Gesamtbestand aus Daten auf Zonenebene und reservieren Sie Abfragen für die Teilmenge, die einen autoritativen Status braucht.

Fehler 5: Das Alter als eigenständige Risikoregel verwenden

Neu registrierte Domains sind bei Missbrauch überrepräsentiert – aber ebenso jedes seriöse Unternehmen, das in diesem Monat gestartet ist. Nutzen Sie das Alter als eines von mehreren Merkmalen – Auflösung, Mail-Konfiguration, Hosting-Netz, Vorhandensein echter Inhalte – und nicht als Ausschlusskriterium.

Fehler 6: Überinterpretieren, was ein einzelner Snapshot zeigt

Eine Datei beschreibt einen Zustand. Wachstum, Abwanderung und Migration erfordern zwei Beobachtungen. Archivieren und datieren Sie jeden Download; ein verworfener Snapshot ist ein Vergleich, den Sie nie mehr anstellen können.

Häufig gestellte Fragen

F: Wie finde ich heraus, wann eine Domain registriert wurde?
A: Fragen Sie RDAP ab und lesen Sie das Ereignis mit eventAction: "registration", oder führen Sie whois aus und suchen Sie nach einem Feld namens „Creation Date“, „Created On“, „created“ oder „registered“. Für Skripte ist RDAP vorzuziehen, weil es strukturiertes JSON zurückgibt.

F: Warum wechselt der Feldname ständig zwischen den TLDs?
A: WHOIS erzwingt kein Antwortschema, daher benennt und formatiert jede Registry die Felder auf eigene Weise. RDAP standardisiert das – der wichtigste praktische Grund, es zu bevorzugen.

F: Warum gibt es für manche Domains kein Erstellungsdatum?
A: Manche Registries veröffentlichen es nicht. Es gibt keinen Umweg, der das echte Datum liefert; Wayback-Erfassungen und Certificate-Transparency-Einträge geben eine Obergrenze dafür, ab wann die Domain in Gebrauch war.

F: Was bedeutet „no registry RDAP server was identified for this domain“?
A: Die TLD hat keinen RDAP-Eintrag in der IANA-Bootstrap-Registry, der Client kann also nicht bestimmen, wohin er die Anfrage senden soll. Für gTLDs ist RDAP Pflicht, für ccTLDs optional. Nutzen Sie für diese TLD stattdessen WHOIS.

F: Ändert sich das Registrierungsdatum, wenn eine Domain verkauft wird?
A: Ein regulärer Transfer erhält es in der Regel. Eine Domain, die abläuft, gelöscht und erneut registriert wird, zeigt im Allgemeinen das neue Erstellungsdatum, während die frühere Historie im aktuellen Eintrag unsichtbar bleibt.

F: Kann ich Registrierungsdaten in großen Mengen abfragen?
A: Nicht über WHOIS oder RDAP. Beide arbeiten domainweise und sind ratenbegrenzt. Für Auswertungen auf Gesamtbestandsebene nutzen Sie Dateien auf Zonenebene und vergleichen datierte Snapshots, um die Registrierungsaktivität abzuleiten.

F: Bietet WebTrackly eine Domain-Abfrage an?
A: Nein. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Einen Abfragedienst für einzelne Domains gibt es nicht.

F: Enthalten die Pakete Registrierungsdaten?
A: Nur dort, wo die Quellzone sie veröffentlicht. Wo die Registry keine Datumsangaben ausgibt, fehlt die Spalte, statt geschätzt zu werden.

F: Enthalten die Pakete Kontaktdaten?
A: Nein. Sie enthalten Domain, Nameserver, MX, aufgelöste IP und erkanntes CMS. Keine E-Mail-Adressen, Telefonnummern oder Inhaberidentitäten.

F: Was kostet das?
A: Pakete ab $3.50 als Einmalkauf. Pro kostet $29/Monat (50 Pakete, 10 Datensätze, 30,000 API-Aufrufe); Enterprise $99/Monat (200 Pakete, 50 Datensätze, 300,000 API-Aufrufe). Siehe /pricing/.

Fazit

Für eine einzelne Domain ist die Abfrage des Registrierungsdatums eine einzige RDAP-Anfrage oder ein einziger whois-Aufruf – mit den Einschränkungen, dass der Feldname variiert, manche Registries nichts veröffentlichen und manche TLDs überhaupt keinen RDAP-Endpunkt haben. Lesen Sie das Ergebnis eng: Es belegt, wann der Registrierungseintrag begonnen hat, nicht, wann ein Unternehmen gegründet wurde, und auch nicht, wer den Namen heute kontrolliert.

Für viele Domains sind die domainweisen Protokolle schlicht das falsche Werkzeug. Dateien auf Zonenebene liefern den gesamten Bestand auf einmal – mit Nameservern, Mail-Routing, aufgelösten Adressen und erkanntem CMS – und der Vergleich datierter Snapshots rekonstruiert die Registrierungsaktivität selbst für Zonen, die gar keine Datumsangaben veröffentlichen. Das Schema ist bewusst schmal gehalten und enthält keine personenbezogenen Daten; das vorab zu wissen, bewahrt ein Projekt davor, im letzten Schritt zu scheitern.

Zum Katalog der Zonendateien →

Weiterführende Ressourcen

• Paketkatalog — 1,538 herunterladbare Domain-Datenbanken
• Zonendateien nach TLD — .com, .net, .de und über 700 weitere
• Kuratierte Datensätze — alle registrierten Domains, MX-Server, E-Commerce
• API-Dokumentation — Katalogzugriff mit Bearer-Token
• Preise — Einmalkäufe ab $3.50