DNS-Einträge im Überblick: A, AAAA, CNAME, MX und TXT

Jede Domain hat beim zuständigen Nameserver eine Zone, und in dieser Zone stehen Einträge, im Fachjargon Resource Records. Jeder Eintrag verbindet einen Namen mit einer Art von Daten: einer Adresse, einem anderen Namen, einem Mailserver oder einem Stück Text. Welche Typen es gibt und wie sie aufgebaut sind, legen RFC 1034 und RFC 1035 fest; viele Typen sind später dazugekommen ^{[1, 2]}. Die meisten Websites kommen mit fünf Typen aus. Ein paar weitere solltest du kennen, weil sie bei E-Mail, Zertifikaten und Fehlersuche auftauchen.

Woraus ein Eintrag besteht

Jeder Eintrag hat dieselben Felder: den Namen, für den er gilt, eine TTL, eine Klasse (im Internet immer IN), den Typ und die eigentlichen Daten ^[2]. Die TTL gibt in Sekunden an, wie lange ein Resolver die Antwort zwischenspeichern darf; der Wert 0 verbietet das Zwischenspeichern ^[1]. RFC 2181 hat den erlaubten Bereich auf 0 bis 2.147.483.647 Sekunden festgelegt ^[3]. Was der Wert für Änderungen bedeutet, erklärt der Beitrag TTL bei DNS.

Ein Name darf aus Teilen von höchstens 63 Zeichen bestehen, der ganze Name aus höchstens 255 Oktetten ^[2]. Das betrifft vor allem lange Subdomains, die von Programmen automatisch erzeugt werden.

A und AAAA: die Adressen

Der A-Eintrag enthält eine IPv4-Adresse mit 32 Bit, etwa 192.0.2.10 ^[2]. Der AAAA-Eintrag enthält eine IPv6-Adresse mit 128 Bit, etwa 2001:db8::10; er hat den Typwert 28 ^[4]. Ein Name kann mehrere A- und mehrere AAAA-Einträge haben, wenn ein Dienst unter mehreren Adressen erreichbar ist ^[2].

Fehlt der AAAA-Eintrag, ist eine Website nur über IPv4 erreichbar. Steht dort noch die IPv6-Adresse eines alten Servers, landen Besucher mit IPv6 auf dem falschen Rechner, während alle anderen die neue Seite sehen. Solche Fehler sind schwer zu finden, weil sie nur einen Teil der Besucher treffen. Beim Umzug auf einen neuen Server gehören deshalb beide Einträge auf die Liste.

CNAME: ein Name als Alias

Ein CNAME sagt, dass ein Name nur ein Alias ist und die echten Daten unter einem anderen Namen stehen. Der Resolver fragt dann dort weiter ^[1]. Zwei Regeln sind wichtig: Neben einem CNAME darf unter demselben Namen nichts anderes stehen, außer DNSSEC-Daten ^[3]. Und auf der Hauptdomain selbst ist er nicht erlaubt, weil dort SOA und NS stehen müssen ^[1]. Die Einzelheiten und die Auswege, die manche Anbieter dafür bauen, stehen im Beitrag CNAME-Eintrag.

MX: wohin E-Mails gehen

Der MX-Eintrag nennt die Server, die E-Mails für eine Domain annehmen. Er besteht aus einer Vorzugszahl und einem Hostnamen. Niedrigere Zahlen werden bevorzugt ^[2]; ein Eintrag mit 10 kommt also vor einem mit 20. Fällt der erste Server aus, versucht der Absender den nächsten. Das Ziel eines MX muss ein Name mit eigenen Adresseinträgen sein, kein CNAME ^[3]. Wie du den Eintrag bei deinem Anbieter setzt, beschreibt MX-Eintrag einrichten.

TXT: Text für Prüfungen und E-Mail-Schutz

TXT-Einträge waren ursprünglich für beschreibenden Text gedacht ^[2]. Heute tragen sie vor allem maschinenlesbare Angaben. Viele Dienste verlangen einen TXT-Eintrag mit einem Prüfwert, um festzustellen, dass dir die Domain gehört. Die drei wichtigsten Verfahren zum Schutz vor gefälschten Absendern nutzen ebenfalls TXT:

• SPF steht als TXT-Eintrag direkt auf der Domain, beginnt mit "v=spf1", und je Name darf es nur einen SPF-Eintrag geben ^[5]. Einen eigenen Typ SPF gibt es in SPF Version 1 nicht mehr ^[5].
• DKIM legt seine öffentlichen Schlüssel als TXT unter einer Subdomain mit dem Namen _domainkey ab, davor steht ein frei gewählter Selektor ^[6].
• DMARC steht als TXT-Eintrag unter _dmarc vor der Domain und beginnt mit "v=DMARC1" ^[7].

Wie SPF aufgebaut wird, steht unter SPF-Eintrag erstellen und prüfen. Wie Empfänger gefälschte Absender erkennen, erklärt betrug.domain-root.de im Beitrag Gefälschte Absender erkennen.

NS und SOA: wer für die Zone zuständig ist

NS-Einträge nennen die Nameserver, die für eine Domain verbindlich Auskunft geben ^[2]. Sie stehen zweimal: in der eigenen Zone und in der übergeordneten Zone, also bei .de oder .com. Dort zeigen sie Resolvern, wo sie weiterfragen müssen. Wer den DNS-Anbieter wechselt, ändert die NS-Einträge über den Registrar. Der Ablauf steht unter Nameserver ändern.

Den SOA-Eintrag gibt es genau einmal je Zone, an ihrer Spitze ^[1]. Er nennt den primären Nameserver, das Postfach des Verantwortlichen und eine Seriennummer, die bei jeder Änderung steigen sollte. Dazu kommen Zeitwerte für sekundäre Nameserver: wie oft sie nachsehen (REFRESH), wann sie es nach einem Fehler erneut versuchen (RETRY) und wann sie die Daten nicht mehr als gültig ausgeben (EXPIRE) ^[2]. Das Feld MINIMUM hat heute eine besondere Aufgabe: Zusammen mit der TTL des SOA bestimmt es, wie lange ein Resolver sich merkt, dass es einen Namen nicht gibt ^[8].

PTR, SRV und CAA

PTR für den Rückweg

Der PTR-Eintrag verweist auf einen Namen und wird vor allem in der Zone in-addr.arpa genutzt, um zu einer IP-Adresse den Hostnamen zu finden ^[2]. Gepflegt wird er bei dem, dem die IP-Adresse gehört, meist beim Hoster. Mehr dazu unter Reverse-DNS und PTR-Eintrag.

SRV für Dienste

Ein SRV-Eintrag gibt an, auf welchem Server und Port ein bestimmter Dienst läuft. Der Name hat die Form _dienst._protokoll.domain, die Daten bestehen aus Priorität, Gewicht, Port und Zielname ^[9]. Niedrigere Prioritäten werden zuerst versucht, das Gewicht verteilt die Last zwischen Servern gleicher Priorität ^[9]. Du begegnest SRV bei Telefonie, Chat-Protokollen und der automatischen Einrichtung von Mailprogrammen.

CAA für Zertifikate

Mit einem CAA-Eintrag legst du fest, welche Zertifizierungsstellen Zertifikate für deine Domain ausstellen dürfen. Die Eigenschaft issue erlaubt eine Stelle für normale Zertifikate, issuewild nur für Wildcard-Zertifikate, und iodef nennt eine Adresse für Meldungen über Verstöße ^[10]. Ein leerer issue-Wert verbietet jede Ausstellung ^[10]. Kurz erklärt ist das auch im Glossar unter CAA-Eintrag.

Die Typen auf einen Blick

Der HTTPS-Eintrag ist der jüngste in dieser Liste. RFC 9460 hat ihn im November 2023 zusammen mit SVCB eingeführt; unter anderem erlaubt er einen Alias an der Spitze einer Zone, wo kein CNAME stehen darf ^[11].

Typische Fehler beim Eintragen

Die meisten Probleme mit DNS-Einträgen gehen auf eine Handvoll wiederkehrender Fehler zurück. Die Oberflächen der Anbieter fangen manche davon ab, längst nicht alle.

• Ein CNAME steht neben anderen Einträgen desselben Namens, etwa neben einem TXT-Eintrag zur Bestätigung. Das widerspricht RFC 2181 ^[3].
• Für eine Domain gibt es zwei TXT-Einträge, die mit "v=spf1" beginnen, weil ein zweiter Dienst seinen eigenen Eintrag verlangt hat. Die Angaben gehören in einen gemeinsamen Eintrag ^[5].
• Ein MX zeigt auf einen Namen, der selbst ein CNAME ist ^[3].
• In einer Zonendatei fehlt der Punkt am Ende eines Namens. Namen ohne Punkt gelten dort als relativ, der Server hängt den Zonennamen an, und aus mail.beispiel.de wird mail.beispiel.de.beispiel.de ^[2].
• Wer eine Zonendatei von Hand pflegt, vergisst, die Seriennummer im SOA zu erhöhen. Sekundäre Nameserver erkennen die Änderung dann nicht und liefern weiter den alten Stand ^[2].

Ein Fehler, den keine Oberfläche meldet, ist ein Eintrag, der auf einen gekündigten Dienst zeigt. Solche verwaisten Einträge solltest du regelmäßig suchen und löschen.

Einträge selbst abfragen

Welche Einträge eine Domain gerade hat, zeigt der DNS-Check. Er fragt die Einträge über den Resolver unseres eigenen Servers ab. Was du dort siehst, ist die Antwort dieses Resolvers. Hast du gerade etwas geändert, kann er für die Dauer der TTL noch den alten Stand zeigen. Warum das so ist, steht unter DNS-Änderung: wie lange dauert es?

1. Gesetz RFC 1034: Domain Names, Concepts and Facilities. IETF. Stand November 1987. abgerufen am 29.10.2026
2. Gesetz RFC 1035: Domain Names, Implementation and Specification. IETF. Stand November 1987. abgerufen am 29.10.2026
3. Gesetz RFC 2181: Clarifications to the DNS Specification. IETF. Stand Juli 1997. abgerufen am 29.10.2026
4. Gesetz RFC 3596: DNS Extensions to Support IP Version 6. IETF. Stand Oktober 2003. abgerufen am 29.10.2026
5. 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
6. Gesetz RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. IETF. Stand September 2011. abgerufen am 29.10.2026
7. Gesetz RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC). IETF. Stand Mai 2026. abgerufen am 29.10.2026
8. Gesetz RFC 2308: Negative Caching of DNS Queries (DNS NCACHE). IETF. Stand März 1998. abgerufen am 29.10.2026
9. Gesetz RFC 2782: A DNS RR for specifying the location of services (DNS SRV). IETF. Stand Februar 2000. abgerufen am 29.10.2026
10. Gesetz RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. IETF. Stand November 2019. abgerufen am 29.10.2026
11. Gesetz RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). IETF. Stand November 2023. 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.