DNS-Check: Einträge einer Domain abfragen

Mit dem DNS-Check siehst du in wenigen Sekunden, welche Einträge eine Domain im DNS veröffentlicht. Du gibst einen Namen ein, etwa beispiel.de oder shop.beispiel.de, und bekommst für sieben Eintragstypen die aktuelle Antwort. Ein "https://" oder ein Pfad hinter dem Namen stört nicht, der Check schneidet beides ab. Das hilft nach einer Änderung beim Provider, beim Umzug zu einem neuen Hoster oder wenn Mails plötzlich nicht mehr ankommen.

Welche Einträge der Check abfragt

Der Check stellt für jeden Typ eine eigene Anfrage und zeigt die Antworten nebeneinander. Was die Einträge bedeuten, steht in den Grundnormen des DNS ^{[1, 2, 3]}:

• A: die IPv4-Adresse, unter der der Name erreichbar ist ^[2].
• AAAA: die IPv6-Adresse. Hat ein Server mehrere IPv6-Adressen, gibt es mehrere AAAA-Einträge ^[3].
• MX: die Mailserver, die E-Mails für die Domain annehmen ^[2].
• TXT: freie Textzeilen. Hier stehen unter anderem der SPF-Eintrag und Bestätigungscodes von Diensten wie Google oder Microsoft ^{[2, 5]}.
• NS: die Nameserver, die für die Domain zuständig sind ^[2].
• CNAME: ein Alias, der auf einen anderen Namen zeigt ^[2].
• SOA: der Kopf der Zone mit dem primären Nameserver, der Adresse des Verantwortlichen, einer Seriennummer und den Zeitwerten für den Abgleich der Nameserver ^[2].

Hinter jedem Wert steht die TTL in Sekunden. Sie gibt an, wie lange ein Resolver die Antwort zwischenspeichern darf, bevor sie als veraltet gilt ^[1]. Liefert ein Typ nichts, steht dort "kein Eintrag". Das ist oft richtig: Eine Subdomain ohne eigene Mail hat meist keinen MX-Eintrag, und viele Domains haben noch keine IPv6-Adresse.

So liest du das Ergebnis

Die Antworten kommen vom Resolver unseres eigenen Servers. Dein Browser schickt den Namen an unseren Server, der alle sieben Eintragstypen abfragt und das Ergebnis zurückgibt. Hat der Resolver den Eintrag schon im Cache, zeigt er dir diesen gespeicherten Stand. Die TTL ist dann kleiner als der Wert, den du beim Provider eingetragen hast, weil die Daten im Cache altern ^[1]. Wie sich das auf Änderungen auswirkt, erklären die Ratgeber TTL bei DNS und DNS-Änderung: wie lange dauert es?

Zwei Dinge wirken auf den ersten Blick seltsam. Ist ein Name ein Alias, liefert der Resolver bei der Frage nach A oder AAAA zuerst den CNAME und danach die Adresse des Zielnamens ^[1]. Im Feld A stehen dann ein Hostname und eine IP-Adresse untereinander. Und an einem Namen mit CNAME sollen keine weiteren Daten stehen ^[1]. Findest du bei einem Namen sowohl einen CNAME als auch eigene MX- oder TXT-Werte, lohnt sich ein Blick in die Zone. Mehr dazu im Ratgeber CNAME-Eintrag: wann er passt und wann nicht.

Beispiele für jeden Eintragstyp und ihre Schreibweise beim Provider findest du unter DNS-Einträge im Überblick.

Typische Prüfungen nach einer Änderung

Nach einem Umzug der Website prüfst du zuerst A und AAAA. Zeigen beide auf den neuen Server, kommt der Resolver unseres Servers schon dort an. Steht noch die alte Adresse da, hat er den alten Wert im Cache, und du wartest die angezeigte TTL ab. Eine AAAA-Adresse, die noch auf den alten Hoster zeigt, ist ein häufiger Grund dafür, dass eine Seite bei manchen Besuchern geht und bei anderen nicht.

Nach einem Wechsel der Nameserver zeigt der NS-Eintrag, ob die neuen Server schon ausgeliefert werden. Erst dann gelten die Einträge, die du beim neuen Anbieter angelegt hast. Die Schritte dazu stehen im Ratgeber Nameserver ändern. Der SOA-Eintrag hilft bei der Frage, ob eine Änderung schon angekommen ist: Seine Seriennummer ist die Versionsnummer der Zone ^[2]. Vergleichst du sie vor und nach der Änderung, siehst du, ob schon die neue Fassung ausgeliefert wird.

Für E-Mail sind MX und TXT wichtig. Unter MX müssen die Mailserver deines Anbieters stehen. Im TXT-Feld suchst du die Zeile, die mit "v=spf1" beginnt. Davon darf es nur eine geben, zwei SPF-Einträge an derselben Domain sind ein Fehler ^[5]. Wie SPF, DKIM und DMARC zusammenarbeiten, erklärt SPF, DKIM und DMARC im Zusammenspiel.

Wer eine Website neu startet oder umzieht, prüft neben dem DNS auch Weiterleitungen und Indexierung. Worauf es dabei ankommt, erklärt auf seo.domain-root.de der Ratgeber Website-Relaunch ohne Rankingverlust.

Grenzen des Checks

Der Check fragt genau den Namen ab, den du eingibst. Einträge, die unter einem eigenen Namen liegen, siehst du nur, wenn du diesen Namen eingibst. Das betrifft vor allem DMARC: Die Regel steht als TXT-Eintrag unter _dmarc.beispiel.de ^[6]. Solche Namen mit Unterstrich nimmt das Eingabefeld an, die Regel steht dann im Feld TXT. DKIM-Schlüssel liegen unter einem Namen aus Selektor und _domainkey, etwa selektor._domainkey.beispiel.de ^[10]. Den Selektor legt dein Mailanbieter fest.

Domains mit Umlauten kannst du so eingeben, wie du sie schreibst. Der Check wandelt sie in die ASCII-Form um, die mit "xn--" beginnt ^[7], und zeigt diese Form im Ergebnis. Auch Endungen in dieser Form, die Ziffern enthalten, nimmt das Feld an. Wie die Umwandlung funktioniert, steht im Ratgeber Umlaut-Domains und Punycode. Weitere Eintragstypen wie CAA, SRV oder die DNSSEC-Einträge DS und DNSKEY fragt der Check nicht ab.

Der Check zeigt die Sicht eines einzigen Resolvers. Dein Router oder dein Internetanbieter kann für kurze Zeit noch einen älteren Stand im Cache haben. Ob deine Website erreichbar ist, hängt außerdem vom Server ab, nicht nur vom DNS. Bei einem Ausfall hilft die Fehlersuche Schritt für Schritt.

Datenschutz bei der Abfrage

Die Abfrage läuft über unseren eigenen Server. Er fragt die Einträge bei seinem Resolver ab und schickt dir nur das Ergebnis zurück. Einen fremden Dienst bindet der DNS-Check dafür nicht ein. Den Namen, den du prüfst, speichern wir nicht in einer Datenbank. Er steht wie jeder Seitenabruf in den Log-Dateien des Servers.

Die geprüfte Domain steht nach dem Aufruf mit "?d=" in der Adresse der Seite. So kannst du ein Ergebnis als Link weitergeben. Was unsere Statistik und die Werbung dabei erfassen, steht in der Datenschutzerklärung.

1. Gesetz RFC 1034: Domain Names, Concepts and Facilities, Abschnitte 3.6 und 3.6.2. IETF. Stand November 1987. abgerufen am 29.10.2026
2. Gesetz RFC 1035: Domain Names, Implementation and Specification, Abschnitte 3.2.2, 3.3 und 3.4.1. IETF. Stand November 1987. abgerufen am 29.10.2026
3. Gesetz RFC 3596: DNS Extensions to Support IP Version 6. IETF. Stand Oktober 2003. abgerufen am 29.10.2026
4. Gesetz RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF. Stand April 2014. abgerufen am 29.10.2026
5. Gesetz RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), Abschnitt 4.5. IETF. Stand Mai 2026. abgerufen am 29.10.2026
6. Gesetz RFC 5890: Internationalized Domain Names for Applications (IDNA), Abschnitt 2.3.2.5. IETF. Stand August 2010. abgerufen am 29.10.2026
7. Gesetz RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, Abschnitte 3.5 und 3.6.2.1. IETF. Stand September 2011. 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.