DNS-Check
Alle wichtigen DNS-Records einer Domain auf einen Blick — A, AAAA, NS, SOA, CNAME, MX, TXT und CAA. Jeder Record wird auf Deutsch erklärt, und eine automatische Mini-Diagnose weist auf typische Auffälligkeiten hin.
Es werden die DNS-Records der Domain über DNS-over-HTTPS (Cloudflare) abgefragt. Reverse-DNS (PTR) und DNSSEC/DANE haben eigene Werkzeuge.
Vertiefende Prüfungen
Für E-Mail-spezifische Analysen: Domain-Check (SPF/DKIM/DMARC), MTA-STS und der Microsoft-365-Check.
Wie eine DNS-Abfrage abläuft
Das Domain Name System übersetzt Namen in technische Angaben — meist in IP-Adressen, oft aber auch in Mailserver-Namen, Textwerte oder Zertifikatsregeln. Fragt ein Programm nach beispiel.de, wendet es sich zunächst an einen auflösenden Nameserver, den Resolver. Der arbeitet sich von der Wurzelzone über die Registry der Top-Level-Domain bis zu den autoritativen Nameservern der Domain vor und liefert das Ergebnis zurück.
Autoritativ ist dabei immer nur der Nameserver, der die Zone tatsächlich hält. Alle anderen Stationen geben Kopien weiter, die für eine bestimmte Zeit zwischengespeichert werden. Genau deshalb sehen zwei Personen an unterschiedlichen Anschlüssen kurz nach einer Änderung verschiedene Antworten. Der DNS-Check auf dieser Seite fragt über DNS-over-HTTPS bei Cloudflare an und zeigt damit den Stand, den ein öffentlicher Resolver gerade ausliefert.
Die Record-Typen im Einzelnen
A und AAAA
Der A-Record verweist auf eine IPv4-Adresse, der AAAA-Record auf eine IPv6-Adresse. Beide dürfen mehrfach vorkommen; Clients verteilen sich dann auf die Adressen. Fehlt der AAAA-Record, erreichen Sie Besucher in reinen IPv6-Netzen nur über Übergangstechniken des Providers.
NS
Die NS-Records nennen die autoritativen Nameserver der Zone. Zwei voneinander unabhängige Server gelten seit RFC 2182 als Mindestmaß, damit die Domain einen Ausfall übersteht. Weichen die im Check angezeigten NS-Records von den bei Ihrem Registrar hinterlegten ab, bearbeiten Sie womöglich eine Zone, die gar nicht ausgeliefert wird.
SOA
Der Start-of-Authority-Record beschreibt die Verwaltung der Zone: den primären Nameserver, die Kontaktadresse, die Seriennummer sowie die Intervalle für Abgleich und Ablauf. Der letzte Wert steuert, wie lange negative Antworten zwischengespeichert werden — wie lange also ein „gibt es nicht" nachwirkt, nachdem Sie den Eintrag angelegt haben.
CNAME
Ein CNAME verweist auf einen anderen Namen statt auf eine Adresse. Neben einem CNAME darf für denselben Namen kein weiterer Record stehen. Auf dem Zonen-Apex, also direkt auf beispiel.de ohne Subdomain, ist ein CNAME deshalb nicht zulässig. Viele DNS-Anbieter umgehen das mit ALIAS-, ANAME- oder Flattening-Funktionen.
MX
MX-Records legen fest, welche Server Post für die Domain annehmen. Die vorangestellte Zahl ist eine Priorität, bei der der kleinere Wert zuerst versucht wird. Ein MX-Record muss auf einen Namen mit eigenem A- oder AAAA-Record zeigen; ein Verweis auf einen CNAME ist laut RFC 2181 nicht vorgesehen und wird von manchen Mailservern abgelehnt.
TXT
TXT-Records tragen freien Text und sind dadurch zum Sammelplatz geworden: SPF, DKIM, DMARC, Domainbestätigungen von Cloud-Diensten. Für SPF gilt dabei eine harte Regel — pro Domain darf es nur einen SPF-Record geben. Zwei davon führen laut RFC 7208 zu einem PermError, womit die Prüfung insgesamt scheitert.
CAA
Der CAA-Record bestimmt, welche Zertifizierungsstellen für die Domain ausstellen dürfen. Ohne CAA darf es jede. Mit issue begrenzen Sie TLS-Zertifikate, mit issuewild Wildcards, und seit RFC 9495 regelt issuemail zusätzlich S/MIME-Zertifikate. Wer CAA setzt, sollte alle tatsächlich genutzten Stellen aufführen, sonst schlägt die nächste Verlängerung fehl.
Was hier nicht auftaucht
PTR-Records für Reverse-DNS liegen nicht in Ihrer Zone, sondern beim Betreiber des IP-Netzes. SRV-Records für Dienste wie Autodiscover oder SIP werden gezielt unter eigenen Namen abgelegt. Beides prüfen Sie am sinnvollsten dort, wo der jeweilige Dienst konfiguriert ist.
TTL und der Mythos der Verbreitungszeit
Jeder Record trägt eine TTL, eine Gültigkeitsdauer in Sekunden. Sie legt fest, wie lange ein Resolver die Antwort behalten darf, bevor er erneut nachfragt. Der oft zitierte Satz, eine DNS-Änderung brauche 24 bis 48 Stunden, beschreibt keinen Verteilvorgang: Es wird nichts an die Welt verschickt. Es läuft lediglich der Cache ab, den andere Server noch halten.
Daraus folgt ein einfaches Vorgehen bei geplanten Umstellungen. Senken Sie die TTL des betroffenen Records rechtzeitig vorher auf einen niedrigen Wert, etwa 300 Sekunden, und warten Sie mindestens die alte TTL ab. Nehmen Sie dann die eigentliche Änderung vor. Läuft alles stabil, setzen Sie die TTL wieder herauf, weil hohe Werte die Zahl der Abfragen senken und Ausfälle des Nameservers besser überbrücken.
Ein Sonderfall betrifft Einträge, die es noch nicht gab. Hier greift nicht die TTL des Records, sondern der letzte Wert aus dem SOA-Record. Wer eine Adresse abfragt, bevor er sie anlegt, wartet anschließend länger als nötig auf das Ergebnis.
Fehler, die uns in der Praxis am häufigsten begegnen
Zwei SPF-Records nebeneinander. Entsteht fast immer, wenn ein zweiter Dienst hinzukommt und dessen Anleitung wörtlich befolgt wird. Richtig ist, den vorhandenen Record um einen weiteren include zu ergänzen.
MX zeigt auf einen CNAME. Funktioniert bei vielen Absendern und scheitert bei einzelnen — ein Fehlerbild, das schwer zu greifen ist, weil Post überwiegend ankommt.
Alte Einträge nach einem Umzug. Verwaiste A-Records auf abgeschaltete Server oder SPF-Freigaben für längst gekündigte Dienste. Beides fällt erst auf, wenn jemand die Zone durchsieht.
CAA ohne die tatsächlich genutzte Stelle. Der Fehler zeigt sich nicht sofort, sondern bei der nächsten automatischen Zertifikatsverlängerung.
Zone am falschen Ort gepflegt. Die Domain wurde zu einem neuen Anbieter delegiert, gearbeitet wird aber weiter in der alten Oberfläche. Der Vergleich der NS-Records mit der Angabe beim Registrar klärt das in einer Minute.
Weiterführende Prüfungen
Der DNS-Check zeigt die Grundstruktur einer Zone. Für den E-Mail-Betrieb gehört mehr dazu: Der Domain-Check bewertet SPF, DKIM und DMARC im Zusammenhang und prüft die Transportverschlüsselung der Mailserver. Wie streng Ihre Domain verschlüsselten Transport verlangt, sehen Sie im MTA-STS-Check.
Liegt das Postfach bei Microsoft 365, deckt der Microsoft-365-Check die dortigen Besonderheiten ab, etwa die beiden gültigen Formate der DKIM-CNAMEs. Wenn Sie einen neuen SPF- oder DMARC-Record aufsetzen, helfen der SPF-Generator und der DMARC-Generator. Hintergründe zu den Standards sammelt die FAQ.