DNS-Records erklärt: A, AAAA, CNAME, MX und TXT
DNS-Records verständlich erklärt: Dieser Nachschlage-Artikel zeigt dir mit Tabellen und konkreten Beispielwerten, was A, AAAA, CNAME, MX und TXT (SPF, DKIM, DMARC) bedeuten, wann du sie brauchst und wie du sie mit dig und nslookup prüfst.
Wer Domains, Mailserver oder Webhosting betreut, schlägt DNS-Records ständig nach: Welcher Eintrag zeigt wohin, warum darf am Apex kein CNAME stehen, und wieso landet eine Umstellung erst nach 24 Stunden? Dieser Artikel ist dein kompaktes Nachschlagewerk für Admins im Mittelstand. Du bekommst zu jedem wichtigen Record-Typ die Bedeutung, die Zonefile-Syntax, konkrete Beispielwerte und die Befehle zum Prüfen. Schwerpunkt sind A, AAAA, CNAME, MX und TXT; NS, PTR und SRV runden das Bild ab.
Kurzfassung: A zeigt auf IPv4, AAAA auf IPv6, CNAME ist ein Alias (nie am Root und nie neben anderen Records), MX steuert das Mailrouting (niedrigere Prioritätszahl = bevorzugt), TXT trägt SPF, DKIM, DMARC und Domain-Verifizierungen. Die TTL bestimmt, wie lange Resolver einen Eintrag cachen. Vor einem Umzug die TTL 24 bis 48 Stunden vorher senken, sonst hängen Caches am alten Wert.
Voraussetzungen
- Zugang zum DNS-Verwaltungsbereich deines Providers oder zu einem eigenen autoritativen Nameserver.
- Ein Werkzeug zum Abfragen: unter Linux/macOS
dig(im Paketdnsutilsbzw.bind-utils), unter Windowsnslookup(vorinstalliert). - Grundverständnis von Domainnamen: ein FQDN ist der voll qualifizierte Name (z. B.
www.example.com.mit Punkt am Ende), der Apex oder Root ist die Domain ohne Subdomain (z. B.example.com, in Zonefiles als@). - Für E-Mail-Themen: Zugriff auf die Mailsystem-Doku deines Anbieters, um SPF-, DKIM- und DMARC-Werte korrekt zu setzen.
Schritt 1: A und AAAA verstehen (IPv4 und IPv6)
Der A-Record bildet einen Hostnamen auf eine IPv4-Adresse ab, der AAAA-Record auf eine IPv6-Adresse. Das sind die grundlegendsten Einträge: Ohne sie findet ein Browser deinen Webserver nicht. IPv6 wird in kanonischer Kurznotation nach RFC 5952 gespeichert (Kleinbuchstaben, führende Nullen weggelassen, längste Nullgruppe zu :: verkürzt).
; A-Record (IPv4)
example.com. 3600 IN A 192.0.2.1
; AAAA-Record (IPv6, kanonische Notation nach RFC 5952)
example.com. 3600 IN AAAA 2001:db8::1Prüfen kannst du beide Typen mit dig (Linux/macOS) oder nslookup (Windows):
# IPv4 abfragen (kurz: nur die Adresse)
dig +short example.com A
# IPv6 abfragen
dig example.com AAAA
# Windows-Aequivalent fuer die IPv6-Adresse
nslookup -type=AAAA example.comFür denselben Hostnamen kannst du gleichzeitig einen A- und einen AAAA-Record führen (Dual-Stack). Ein Client wählt dann je nach Konnektivität IPv4 oder IPv6.
Schritt 2: CNAME als Alias richtig setzen
Ein CNAME (Canonical Name) ist ein Alias: Er verweist einen Namen auf einen anderen kanonischen Domainnamen, der letztlich auf einen A- oder AAAA-Record auflösen muss. Typischer Einsatz ist www, das auf die Hauptdomain oder auf einen Hostnamen deines CDN zeigt.
; www zeigt als Alias auf die Hauptdomain
; Ziel MUSS ein FQDN sein, am besten mit Punkt am Ende
www.example.com. 3600 IN CNAME example.com.Die wichtigste Regel: Ein Name mit CNAME darf laut RFC 1034 keine weiteren Records tragen. Steht für denselben Namen schon ein TXT, MX oder anderer Eintrag, ist ein CNAME nicht erlaubt. Daraus folgt direkt das Apex-Problem im nächsten Schritt.
SituationCNAME erlaubt?Hinweis
Subdomain ohne weitere Records (z. B. www)
Ja
Ziel muss auf A/AAAA auflösen
Apex/Root der Domain (@)
Nein
SOA und NS sind dort Pflicht, Koexistenz verboten
Name, der bereits MX oder TXT hat
Nein
Kein zweiter Record neben CNAME
MX- oder NS-Ziel
Nein
Diese müssen direkt auf A/AAAA zeigen
Schritt 3: CNAME am Apex umgehen (ALIAS, ANAME, Flattening)
Der Domain-Apex (die nackte example.com) muss zwingend einen SOA- und NS-Record tragen, meist auch MX. Weil ein CNAME nicht neben anderen Records existieren darf, ist ein CNAME am Apex technisch unmöglich. Trotzdem willst du oft, dass example.com auf einen Cloud-Hostnamen zeigt, dessen IP wechselt.
Drei Lösungswege:
- A/AAAA direkt eintragen: Wenn das Ziel eine feste IP hat, trägst du sie einfach als A/AAAA am Apex ein.
- ALIAS- bzw. ANAME-Record: Ein providerseitiger Pseudo-Record, der sich nach außen wie ein A-Record verhält, intern aber wie ein CNAME aufgelöst wird.
- CNAME-Flattening: Der Provider (z. B. Cloudflare) löst den CNAME im Hintergrund auf und liefert dem Client direkt die A/AAAA-Antwort.
Welche Variante verfügbar ist, hängt vom DNS-Anbieter ab. Funktional liefern alle drei am Ende eine IP-Adresse für den Apex.
Schritt 4: MX-Records und die Prioritätslogik
Der MX-Record (Mail Exchanger) legt fest, welcher Server E-Mails für deine Domain annimmt. Jeder MX-Eintrag besteht aus einer Prioritätszahl und einem Mailserver-Hostnamen. Entscheidend: Eine niedrigere Zahl bedeutet höhere Priorität. Server mit Priorität 10 wird also vor 20 kontaktiert; der höhere Wert dient als Fallback.
; Primärer Mailserver (bevorzugt) und Backup
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 backup-mail.example.com.Tragen mehrere MX-Records dieselbe Prioritätszahl, verteilt sich die Last gleichmäßig (Load Balancing). Wichtig: Das MX-Ziel muss auf einen A/AAAA-Record zeigen, nicht auf einen CNAME, sonst ist der Eintrag nicht spezifikationskonform.
# Mailserver inkl. Prioritaet anzeigen
dig example.com MX
# Windows-Aequivalent
nslookup -type=MX example.comPrioritätswertBedeutungBeispiel
Niedrig (z. B. 10)
Bevorzugter Server, wird zuerst versucht
10 mail.example.com.
Höher (z. B. 20)
Fallback/Backup, nur wenn 10 nicht erreichbar
20 backup-mail.example.com.
Gleich (z. B. 10 und 10)
Lastverteilung über beide Server
10 mx1... und 10 mx2...
Schritt 5: TXT-Records für SPF, DKIM und DMARC
Der TXT-Record speichert Freitext in doppelten Anführungszeichen. Pro String sind maximal 255 Zeichen erlaubt; längere Werte werden in mehrere Chunks aufgeteilt und vom Resolver konkateniert. In der Praxis steckt darin fast immer die E-Mail-Authentifizierung oder eine Domain-Verifizierung.
SPF (Sender Policy Framework)
SPF legt fest, welche Server für deine Domain senden dürfen. Der Record beginnt mit v=spf1 und endet mit einem all-Mechanismus. Es darf nur einen einzigen SPF-TXT-Record je Domain geben.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com -all"QualifiziererBedeutungEmpfehlung
-all
HardFail: alles andere abweisen
Empfohlen für produktiv
~all
SoftFail: markieren, aber annehmen
Für Testphase
?all
Neutral: keine Aussage
Kein Schutz
+all
Allow: jeder darf senden
Gefährlich, vermeiden
Mechanismen sind unter anderem a, mx, ip4:, ip6:, include: und exists:. Beachte das 10-Lookup-Limit nach RFC 7208: Maximal 10 DNS-abfragende Mechanismen (include, a, mx, ptr, exists) sind erlaubt. ip4:, ip6: und all zählen nicht mit. Ohne Maske gilt ip4 als /32 und ip6 als /128.
DKIM (DomainKeys Identified Mail)
DKIM signiert ausgehende Mails kryptografisch. Der öffentliche Schlüssel wird unter selector._domainkey.DEINE-DOMAIN veröffentlicht; der Selector ist frei wählbar (z. B. s2024q3). Empfohlen sind 2048-bit-Schlüssel.
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."DMARC (Domain-based Message Authentication)
DMARC verknüpft SPF und DKIM mit einer Richtlinie und liegt unter _dmarc.DEINE-DOMAIN (RFC 7489). Pflicht sind die Tags v=DMARC1 (immer zuerst) und p= mit dem Wert none, quarantine oder reject.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"DMARC-TagBedeutungDefault
v=DMARC1
Version, muss zuerst stehen
Pflicht
p=
Policy: none / quarantine / reject
Pflicht
sp=
Policy für Subdomains
erbt von p
pct=
Prozentsatz der geprüften Mails
100
rua=
Adresse für Aggregat-Reports
-
adkim/aspf
Ausrichtung: r=relaxed / s=strict
r
Bewährtes Vorgehen 2025/2026: SPF mit -all, DKIM mit 2048-bit und Selector, DMARC zunächst mit p=none zum Monitoring, dann schrittweise auf quarantine und reject anheben. Prüfen kannst du die Records so:
# SPF/Verifizierung am Apex
dig example.com TXT
# DKIM (Selector einsetzen)
dig selector._domainkey.example.com TXT
# DMARC
dig _dmarc.example.com TXT
# DMARC ueber einen bestimmten Resolver pruefen (Windows)
nslookup -type=TXT _dmarc.example.com 8.8.8.8Schritt 6: NS, PTR und SRV kurz erklärt
Über die fünf Hauptrecords hinaus begegnen dir drei weitere Typen regelmäßig:
- NS-Record: Legt die autoritativen Nameserver für eine Zone fest. Empfohlen sind höchstens 7, technisch maximal 10 pro Delegation.
- PTR-Record: Reverse-DNS, bildet eine IP zurück auf einen Namen. Er liegt nicht in deiner Vorwärtszone, sondern in der Reverse-Zone (oft beim IP-Provider). Wichtig für die Mail-Reputation.
- SRV-Record: Veröffentlicht Host und Port für einen Dienst. Das Format ist Priorität, Weight, Port, Ziel; der Name trägt ein Unterstrich-Präfix wie
_sip._tcp..
; SRV: Prioritaet Weight Port Ziel
_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.
# Autoritative Nameserver abfragen
dig example.com NS
# Reverse-Lookup (PTR)
dig -x 192.0.2.1
# Gezielt einen Resolver befragen (hier Google)
dig @8.8.8.8 example.com ASchritt 7: TTL verstehen und Umzüge planen
Die TTL (Time To Live) gibt in Sekunden an, wie lange ein Resolver einen Record cachen darf, bevor er erneut nachfragt. Eine niedrige TTL bedeutet schnelle Änderungen, aber mehr Last; eine hohe TTL ist effizient, aber träge bei Umstellungen.
TTL (Sekunden)EntsprichtTypischer Einsatz
300
5 Minuten
Häufige Änderungen, kurz vor einem Umzug
3600
1 Stunde
Sinnvoller Default für A/AAAA
86400
24 Stunden
Statische Einträge (NS, MX, lange stabile A)
Die zentrale Umzugsregel: Senkst du die TTL von 86400 auf 300 und änderst sofort den Record, halten Resolver, die noch mit dem alten Wert 86400 gecacht haben, bis zu 24 Stunden am alten Ziel fest. Der alte, hohe TTL bestimmt die Wartezeit, nicht der neue. Plane einen Umzug deshalb so:
Umzugs-Fahrplan:
1. 24-48 h vorher: TTL auf 300 senken
2. Alten (hohen) TTL vollständig abwarten
3. Record auf neue IP/Ziel aendern
4. Erreichbarkeit pruefen (dig +short)
5. Nach erfolgreicher Umstellung TTL wieder erhoehen (z. B. 3600)Typische Fehler
- CNAME am Apex/Root: Nicht erlaubt, weil dort bereits SOA- und NS-Records existieren und ein CNAME laut RFC 1034 nicht neben anderen Records stehen darf. Lösung: A/AAAA direkt eintragen oder ALIAS/ANAME bzw. CNAME-Flattening nutzen.
- Mehrere SPF-Records: Zwei oder mehr
v=spf1-Einträge auf einer Domain ergeben einenPermError, und die gesamte SPF-Prüfung schlägt fehl. Fasse alle Sender mitinclude:in EINEN Record zusammen. - TTL zu spät gesenkt: Wird der TTL erst zum Umzugszeitpunkt gesenkt, hängt der alte hohe Wert noch bis zu 24 Stunden in den Caches. Immer 24 bis 48 Stunden vorher senken.
- SPF 10-Lookup-Limit überschritten: Zu viele
include:führen zumPermError, SPF wird ignoriert. Derptr-Mechanismus ist zudem veraltet und sollte vermieden werden. - MX zeigt auf einen CNAME: Nicht spezifikationskonform. MX-Ziele müssen direkt auf A/AAAA zeigen.
- +all in SPF oder dauerhaft p=none: Beides bietet praktisch keinen Schutz. Produktiv
-allbzw.p=quarantineoderp=rejectanstreben. - TXT-Strings über 255 Zeichen: Lange DKIM-Schlüssel müssen in mehrere mit Anführungszeichen getrennte Chunks aufgeteilt werden. Fehlende oder inkonsistente Quotes verursachen Validierungsfehler.
- DMARC/DKIM am falschen Namen: DMARC gehört an
_dmarc.DEINE-DOMAIN, DKIM anselector._domainkey.DEINE-DOMAIN, nicht an den Apex. - Trailing Dot vergessen: In Zonefiles muss das Ziel von CNAME/MX/NS als FQDN mit Punkt am Ende stehen, sonst hängt der Server die Zone-Origin an (
mail.example.com.example.com).
Häufige Fragen
Was ist der Unterschied zwischen A und AAAA?
Der A-Record verweist auf eine IPv4-Adresse (z. B. 192.0.2.1), der AAAA-Record auf eine IPv6-Adresse (z. B. 2001:db8::1). Für denselben Host kannst du beide gleichzeitig führen, damit IPv4- und IPv6-Clients dich erreichen.
Warum darf am Root kein CNAME stehen?
Am Apex sind SOA- und NS-Records zwingend vorhanden. Ein CNAME darf laut RFC 1034 nicht neben anderen Records existieren, also ist er dort unmöglich. Nutze stattdessen A/AAAA, einen ALIAS/ANAME-Record oder CNAME-Flattening deines Providers.
Was bedeutet die Zahl beim MX-Record?
Das ist die Priorität. Eine niedrigere Zahl bedeutet höhere Priorität, der Server wird also zuerst kontaktiert. Höhere Werte sind Fallback-Server. Gleiche Werte verteilen die Last auf mehrere Server.
Wie viele SPF-Records darf eine Domain haben?
Genau einen. Mehrere v=spf1-TXT-Records führen zu einem PermError, und SPF gilt als ungültig. Alle berechtigten Sender müssen über include: in einem einzigen Record stehen.
Wie lange dauert eine DNS-Änderung?
So lange, wie der zuvor gültige (alte) TTL angibt, plus die Verteilzeit. Hattest du vorher 24 Stunden TTL, können Caches bis zu 24 Stunden am alten Wert hängen. Deshalb senkst du die TTL rechtzeitig vor einer Änderung.
Wofür brauche ich einen TXT-Record?
Vor allem für die E-Mail-Authentifizierung mit SPF, DKIM und DMARC sowie für Domain-Verifizierungen (etwa bei Cloud-Diensten). TXT-Records sind Freitext und werden in doppelte Anführungszeichen gesetzt.
Fazit
DNS-Records folgen klaren Regeln: A und AAAA liefern die IP-Adressen, CNAME ist ein Alias mit dem strikten Verbot, am Apex oder neben anderen Records zu stehen, MX steuert die Mailzustellung über Prioritäten, und TXT trägt mit SPF, DKIM und DMARC die gesamte E-Mail-Authentifizierung. Wer zusätzlich die TTL-Logik beherrscht und Umzüge mit rechtzeitig gesenkter TTL plant, vermeidet die häufigsten Stolperfallen. Mit den dig- und nslookup-Befehlen aus diesem Artikel prüfst du jeden Eintrag in Sekunden. Speichere die Tabellen als Spickzettel, dann hast du beim nächsten Nachschlagen alles parat.
Weiterführende Anleitungen und Quellen
- Exchange Online: SPF, DKIM und DMARC für die Domäne einrichten
- Feste IP, Gateway und DNS unter Windows und Linux setzen
- DHCP- und DNS-Rolle auf dem Windows Server konfigurieren
- Weitere Anleitungen in der Kategorie Netzwerk
Quellen: Cloudflare DNS-Dokumentation zu Record-Typen, Gcore zu DNS-TTL und Best Practices, dmarcian zur SPF-Syntax, EasyDMARC zu DMARC-Tags sowie die RFCs 1034, 5952, 7208 und 7489 (Stand: 2026-06-02).
