Wer Domains, Mailserver oder Webhosting betreut, schlägt DNS-Records regelmäßig nach: Welcher Eintrag zeigt wohin, warum darf am Apex kein CNAME stehen, und warum greift eine Umstellung erst nach 24 Stunden? Dieser Artikel liefert zu jedem wichtigen Record-Typ Bedeutung, Zonefile-Syntax, Beispielwerte und die Befehle zum Prüfen. Schwerpunkt sind A, AAAA, CNAME, MX und TXT; NS, PTR und SRV ergänzen das Bild.

Voraussetzungen

Zugang zur DNS-Verwaltung Ihres Providers oder zu einem eigenen autoritativen Nameserver.
Ein Abfragewerkzeug: unter Linux und macOS dig (Paket dnsutils bzw. bind-utils), unter Windows nslookup (vorinstalliert) oder Resolve-DnsName in PowerShell.
Grundbegriffe: Ein FQDN ist der voll qualifizierte Name (z. B. www.example.com. mit Punkt am Ende), der Apex die Domain ohne Subdomain (z. B. example.com, im Zonefile @).
Für E-Mail-Einträge: die Dokumentation Ihres Mailanbieters mit den vorgegebenen SPF-, DKIM- und DMARC-Werten.

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. IPv6-Adressen schreiben Sie am besten in der Kurznotation nach RFC 5952 (Kleinbuchstaben, ohne führende Nullen, längste Nullgruppe als ::).

; A-Record (IPv4)
example.com.        3600 IN A     192.0.2.1

; AAAA-Record (IPv6)
example.com.        3600 IN AAAA  2001:db8::1

Für denselben Hostnamen können Sie A und AAAA gleichzeitig führen (Dual-Stack); der Client wählt je nach Anbindung.

# IPv4 abfragen (nur die Adresse)
dig +short example.com A

# IPv6 abfragen
dig +short example.com AAAA

# Windows
nslookup -type=AAAA example.com

Verifizieren: dig +short gibt genau die eingetragene Adresse zurück. Eine leere Ausgabe bedeutet: Record fehlt oder ist noch nicht beim abgefragten Resolver angekommen.

Schritt 2: CNAME als Alias richtig setzen

Ein CNAME (Canonical Name) verweist einen Namen auf einen anderen Domainnamen, der letztlich auf A oder AAAA auflösen muss. Typischer Einsatz ist www, das auf die Hauptdomain oder einen CDN-Hostnamen zeigt.

; www zeigt als Alias auf die Hauptdomain
; Ziel als FQDN mit Punkt am Ende
www.example.com.    3600 IN CNAME example.com.

Ein Name mit CNAME darf laut RFC 1034 keine weiteren Records tragen. Hat derselbe Name schon TXT, MX oder einen anderen Eintrag, ist kein CNAME möglich.

Situation	CNAME erlaubt?	Hinweis
Subdomain ohne weitere Records (z. B. www)	Ja	Ziel muss auf A/AAAA auflösen
Apex der Domain (@)	Nein	SOA und NS sind dort Pflicht
Name, der bereits MX oder TXT hat	Nein	Kein weiterer Record neben CNAME
Ziel eines MX- oder NS-Records	Nein	Muss direkt auf A/AAAA zeigen (RFC 2181)

Verifizieren: dig www.example.com zeigt in der ANSWER SECTION zuerst den CNAME und darunter den A-Record des Ziels.

Schritt 3: CNAME am Apex umgehen (ALIAS, ANAME, Flattening)

Der Apex (example.com) trägt zwingend SOA und NS, meist auch MX. Deshalb ist ein CNAME dort nicht möglich. Soll example.com trotzdem auf einen Cloud-Hostnamen mit wechselnder IP zeigen, gibt es drei Wege:

A/AAAA direkt eintragen: bei fester Ziel-IP.
ALIAS- bzw. ANAME-Record: ein Pseudo-Record des Providers, der nach außen wie A/AAAA antwortet, intern aber wie ein CNAME aufgelöst wird.
CNAME-Flattening: Der Provider (z. B. Cloudflare) löst den CNAME im Hintergrund auf und liefert direkt A/AAAA aus.

Welche Variante verfügbar ist, hängt vom DNS-Anbieter ab.

Verifizieren: dig example.com A liefert eine IP-Adresse und keinen CNAME; dig example.com SOA und dig example.com NS antworten weiterhin.

Schritt 4: MX-Records und die Prioritätslogik

Der MX-Record (Mail Exchanger) legt fest, welcher Server E-Mails für die Domain annimmt. Er besteht aus Prioritätszahl und Hostname. Eine niedrigere Zahl bedeutet höhere Priorität: 10 wird vor 20 versucht.

; Primärer Mailserver und Backup
example.com.        3600 IN MX    10 mail.example.com.
example.com.        3600 IN MX    20 backup-mail.example.com.

Prioritätswert	Bedeutung	Beispiel
Niedrig (z. B. 10)	Bevorzugter Server, wird zuerst versucht	`10 mail.example.com.`
Höher (z. B. 20)	Fallback, nur wenn 10 nicht erreichbar	`20 backup-mail.example.com.`
Gleich (z. B. 10 und 10)	Absender wählen zufällig, Last verteilt sich	`10 mx1...` und `10 mx2...`

Das MX-Ziel muss auf A/AAAA zeigen, nicht auf einen CNAME.

dig +short example.com MX

# Windows
nslookup -type=MX example.com

Verifizieren: Die Ausgabe listet alle Mailserver mit Priorität, und dig +short mail.example.com A liefert für jedes Ziel eine IP-Adresse.

Schritt 5: TXT-Records für SPF, DKIM und DMARC

Der TXT-Record speichert Freitext in doppelten Anführungszeichen, höchstens 255 Zeichen pro String; längere Werte werden in mehrere Strings geteilt und vom Empfänger zusammengesetzt. Meist enthält er E-Mail-Authentifizierung oder eine Domain-Verifizierung.

SPF (Sender Policy Framework)

SPF legt fest, welche Server für die Domain senden dürfen. Der Record beginnt mit v=spf1 und endet mit einem all-Mechanismus. Pro Domain ist nur ein SPF-Record erlaubt.

example.com.        3600 IN TXT   "v=spf1 include:_spf.google.com -all"

Qualifizierer	Bedeutung	Empfehlung
`-all`	HardFail: alle anderen abweisen	Produktivbetrieb
`~all`	SoftFail: markieren, aber annehmen	Testphase
`?all`	Neutral: keine Aussage	Kein Schutz
`+all`	Jeder darf senden	Nicht verwenden

Mechanismen sind u. a. a, mx, ip4:, ip6:, include: und exists:. Nach RFC 7208 sind höchstens 10 DNS-Abfragen erlaubt (include, a, mx, ptr, exists, redirect); ip4:, ip6: und all zählen nicht. ptr gilt als veraltet.

DKIM (DomainKeys Identified Mail)

DKIM signiert ausgehende Mails. Der öffentliche Schlüssel liegt unter selector._domainkey.example.com; den Selector gibt Ihr Mailsystem vor oder Sie wählen ihn frei (z. B. s2026). Verwenden Sie RSA-Schlüssel mit 2048 Bit.

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

DMARC (Domain-based Message Authentication)

DMARC verknüpft SPF und DKIM mit einer Richtlinie und liegt unter _dmarc.example.com. Maßgeblich ist seit Mai 2026 RFC 9989, der RFC 7489 ablöst. Der Record beginnt mit v=DMARC1; p= legt die Richtlinie fest (none, quarantine oder reject).

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

DMARC-Tag	Bedeutung	Default
`v=DMARC1`	Version, muss als erstes Tag stehen	Pflicht
`p=`	Richtlinie: none / quarantine / reject	ohne p gilt none
`sp=`	Richtlinie für Subdomains	erbt von p
`np=`	Richtlinie für nicht existierende Subdomains	erbt von sp bzw. p
`t=`	Testmodus: `y` = Richtlinie nicht anwenden, nur beobachten	n
`rua=`	Adresse für Aggregat-Reports	keine
`adkim`/`aspf`	Ausrichtung: r = relaxed, s = strict	r

Das frühere Tag pct= ist in RFC 9989 entfallen; t=y ersetzt die Einführung mit pct=0. Empfänger werten pct teilweise noch aus, neue Records sollten es nicht mehr enthalten.

Bewährtes Vorgehen: SPF mit -all, DKIM mit 2048 Bit, DMARC zunächst mit p=none und rua= zum Beobachten, nach Auswertung der Reports schrittweise quarantine und reject.

# SPF und Verifizierungen am Apex
dig +short example.com TXT

# DKIM (Selector einsetzen)
dig +short selector._domainkey.example.com TXT

# DMARC
dig +short _dmarc.example.com TXT

Verifizieren: dig +short example.com TXT zeigt genau einen String mit v=spf1, die DKIM- und DMARC-Abfragen liefern je einen Record. Den Header einer an ein externes Postfach gesendeten Testmail prüfen Sie auf spf=pass, dkim=pass und dmarc=pass in Authentication-Results.

Schritt 6: NS, PTR und SRV kurz erklärt

NS-Record: legt die autoritativen Nameserver einer Zone fest; mindestens zwei, möglichst in getrennten Netzen.
PTR-Record: Reverse-DNS, bildet eine IP auf einen Namen ab. Er liegt in der Reverse-Zone, meist beim IP-Provider, und ist für die Mail-Zustellung wichtig.
SRV-Record: veröffentlicht Host und Port eines Dienstes im Format Priorität, Gewicht, Port, Ziel; der Name trägt ein Präfix wie _sip._tcp..

; SRV: Priorität  Gewicht  Port  Ziel
_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.

# Autoritative Nameserver
dig +short example.com NS

# Reverse-Lookup (PTR)
dig +short -x 192.0.2.1

# Gezielt einen Resolver befragen
dig @8.8.8.8 +short example.com A

Verifizieren: dig +short example.com NS listet mindestens zwei Nameserver, und für den Mailserver passen PTR und A-Record zusammen (Forward-Confirmed Reverse DNS).

Schritt 7: TTL verstehen und Umzüge planen

Die TTL (Time To Live) gibt in Sekunden an, wie lange ein Resolver einen Record zwischenspeichern darf. Niedrige TTL bedeutet schnelle Änderungen und mehr Abfragen, hohe TTL das Gegenteil.

TTL (Sekunden)	Entspricht	Typischer Einsatz
300	5 Minuten	Häufige Änderungen, vor einem Umzug
3600	1 Stunde	Üblicher Standard für A/AAAA
86400	24 Stunden	Statische Einträge (NS, MX, stabile A-Records)

Senken Sie die TTL von 86400 auf 300 und ändern sofort den Record, halten Resolver mit dem alten Cache-Eintrag bis zu 24 Stunden am alten Ziel fest. Die alte TTL bestimmt die Wartezeit, nicht die neue.

Umzugsplan:
1. Mindestens eine alte TTL vorher (bei 86400: 24 h) TTL auf 300 senken
2. Alte TTL vollständig abwarten
3. Record auf neue IP bzw. neues Ziel ändern
4. Erreichbarkeit prüfen (dig +short)
5. Nach erfolgreicher Umstellung TTL wieder erhöhen (z. B. 3600)

Verifizieren: Die zweite Spalte in dig example.com A zeigt die verbleibende TTL im Cache des Resolvers. Die Abfrage beim autoritativen Server (dig @<ns-server> example.com A) muss den neuen Wert zeigen, bevor Sie den Record ändern.

Typische Fehler

CNAME am Apex: nicht erlaubt. Lösung: A/AAAA direkt, ALIAS/ANAME oder CNAME-Flattening (Schritt 3).
Mehrere SPF-Records: Zwei v=spf1-Einträge ergeben PermError, die SPF-Prüfung schlägt fehl. Fassen Sie alle Sender in einem Record zusammen.
SPF-Limit von 10 Abfragen überschritten: Zu viele include: führen ebenfalls zu PermError. Ersetzen Sie Includes durch ip4:/ip6:, wo möglich.
TTL zu spät gesenkt: Der alte, hohe Wert bleibt bis zu seiner vollen Dauer in den Caches.
MX zeigt auf einen CNAME: nicht zulässig; MX-Ziele müssen direkt auf A/AAAA zeigen.
+all in SPF oder dauerhaft p=none: bietet keinen Schutz. Streben Sie -all und p=quarantine bzw. p=reject an.
TXT-Strings über 255 Zeichen: Lange DKIM-Schlüssel müssen in mehrere Strings mit eigenen Anführungszeichen geteilt werden; viele Provider-Oberflächen erledigen das automatisch.
DMARC oder DKIM am falschen Namen: DMARC gehört an _dmarc.example.com, DKIM an selector._domainkey.example.com, nicht an den Apex.
Punkt am Ende vergessen: Im Zonefile muss das Ziel von CNAME, MX und NS als FQDN mit Punkt enden, sonst hängt der Server die Zone an (mail.example.com.example.com).

Häufige Fragen

Was ist der Unterschied zwischen A und AAAA?

A verweist auf eine IPv4-Adresse, AAAA auf eine IPv6-Adresse. Beide können für denselben Host parallel bestehen.

Warum darf am Apex kein CNAME stehen?

Am Apex stehen zwingend SOA und NS, und ein CNAME darf nicht neben anderen Records existieren. Alternativen beschreibt Schritt 3.

Was bedeutet die Zahl beim MX-Record?

Die Priorität: Die niedrigste Zahl wird zuerst versucht, höhere Werte dienen als Fallback, gleiche Werte verteilen die Last.

Wie viele SPF-Records darf eine Domain haben?

Genau einen. Mehrere führen zu PermError.

Wie lange dauert eine DNS-Änderung?

Bis die zuvor gültige TTL in allen Caches abgelaufen ist. Bei 24 Stunden TTL können Resolver bis zu 24 Stunden den alten Wert liefern.

Wofür brauche ich einen TXT-Record?

Für SPF, DKIM und DMARC sowie für Domain-Verifizierungen bei Cloud-Diensten.

Fazit

A und AAAA liefern die IP-Adressen, CNAME ist ein Alias, der weder am Apex noch neben anderen Records stehen darf, MX steuert die Mailzustellung über Prioritäten, und TXT trägt SPF, DKIM und DMARC. Planen Sie Umzüge mit rechtzeitig gesenkter TTL und prüfen Sie jeden Eintrag mit dig oder nslookup.

Weiterführende Anleitungen und Quellen

Quellen: RFC 1034, RFC 7208 (SPF), RFC 9989 (DMARC), RFC 2181 und RFC 5952.