Netzwerk
Referenzleitfaden für DNS-Eintragstypen
Referenz der DNS-Eintragstypen, die für E-Mail- und Website-Betrieb nötig sind – A, MX, TXT, SPF, DKIM, DMARC und mehr – mit Zweck, Syntaxbeispielen und Stolperfallen zu jedem Typ.
DNS-Eintragstypen
| Typ | Zweck | Beispiel | Hinweis |
|---|---|---|---|
| A-Eintrag | Der grundlegendste Eintragstyp: verknüpft einen Domainnamen mit einer IPv4-Adresse und zeigt, wo ein Web- oder Mailserver tatsächlich liegt. | example.com. 3600 IN A 192.0.2.1 |
Eine zu kurze TTL (3600 Sekunden = 1 Stunde in diesem Beispiel) erhöht die Anfragen an den autoritativen Server und die Last; eine zu lange verzögert die Verbreitung bei einer IP-Änderung. |
| AAAA-Eintrag | Verknüpft einen Domainnamen mit einer IPv6-Adresse – im Grunde das IPv6-Pendant des A-Eintrags. | example.com. 3600 IN AAAA 2001:db8::1 |
Wird zusätzlich ein A-Eintrag gepflegt, können Netzwerke ohne IPv6-Unterstützung auf IPv4 zurückfallen (Dual-Stack-Betrieb). |
| CNAME-Eintrag | Behandelt einen Hostnamen als Alias eines anderen kanonischen Hostnamens – etwa wenn www.example.com auf example.com zeigt. | www.example.com. 3600 IN CNAME example.com. |
Ein Hostname mit CNAME darf keine weiteren Einträge (wie MX oder TXT) parallel haben (Einschränkung aus RFC 1034). An der Zonenwurzel (@) kann kein CNAME gesetzt werden. |
| MX-Eintrag | Legt fest, welcher Mailserver E-Mails für eine Domain empfangen soll. Mehrere Server können mit einem Prioritätswert angegeben werden. | example.com. 3600 IN MX 10 mail.example.com. |
Ein kleinerer Prioritätswert bedeutet höhere Priorität. Für Redundanz werden meist mehrere Server mit unterschiedlicher Priorität angegeben. Das Ziel eines MX-Eintrags muss ein Hostname mit A-Eintrag sein, kein CNAME. |
| TXT-Eintrag | Ein universeller Mehrzweckeintrag, der beliebigen Text an eine Domain anhängt. Wird für SPF, DKIM und DMARC sowie zur Bestätigung des Domainbesitzes und mehr genutzt. | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
Eine Domain kann mehrere TXT-Einträge haben, aber mehr als ein Eintrag für denselben Zweck (etwa SPF) führt zu Interpretationsfehlern – solche Einträge müssen zu einem zusammengeführt werden. |
| SPF-Eintrag (eine Art TXT-Eintrag) | Listet die Server (IP-Adressen) auf, die im Namen einer Domain E-Mails senden dürfen, und bietet so eine Absenderauthentifizierung gegen gefälschte Absender. Wird als TXT-Eintrag konfiguriert. | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
Pro Domain ist nur ein SPF-Eintrag gültig. Bei Ketten von "include"-Mechanismen aufpassen, da das Überschreiten des Limits von 10 DNS-Abfragen einen dauerhaften Fehler verursacht. Der eigene Eintragstyp (RRTYPE 99) wurde 2014 verworfen, heute wird SPF ausschließlich über TXT-Einträge abgebildet. |
| DKIM-Eintrag (eine Art TXT-Eintrag) | Fügt ausgehenden E-Mails eine digitale Signatur hinzu, damit Empfänger prüfen können, dass die Nachricht auf dem Weg nicht verändert wurde und von einem legitimen Absender stammt. Der öffentliche Schlüssel wird als TXT-Eintrag veröffentlicht. | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
Der Selektor (der vordere Teil des Hostnamens) unterscheidet sich je nach Versanddienst. Der private Schlüssel verbleibt auf dem Versandserver – im DNS wird nur der öffentliche Schlüssel veröffentlicht. |
| DMARC-Eintrag (eine Art TXT-Eintrag) | Legt auf Basis der SPF- und DKIM-Ergebnisse fest, wie ein Empfänger mit E-Mails umgehen soll, die die Authentifizierung nicht bestehen (zustellen, unter Quarantäne stellen oder ablehnen), und bietet einen Kanal für Sammelberichte. | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
Mit p=none nur zur Beobachtung zu beginnen und schrittweise auf quarantine und reject zu verschärfen, sobald keine Probleme mehr auftreten, ist der sichere Weg zur Einführung. |
| NS-Eintrag | Gibt an, welche Server die autoritativen DNS-Server für eine Domain (Zone) sind – der Ausgangspunkt für die Namensauflösung innerhalb dieser Domain. | example.com. 86400 IN NS ns1.example-dns.com. |
Stimmen die beim Registrar hinterlegten Nameserver nicht mit den NS-Einträgen in der Zone überein, wird die Namensauflösung instabil (sogenannte "lame delegation"). |
| SOA-Eintrag | Enthält die Verwaltungsinformationen einer Zone – primärer Server, E-Mail des Administrators, Seriennummer, Wiederholungsintervalle und mehr. Jede Zone muss genau einen besitzen. | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
Nach jeder Aktualisierung der Zonendatei muss die Seriennummer erhöht werden, sonst übernehmen sekundäre Server die Änderung nie per Zonentransfer. |
| CAA-Eintrag | Schränkt ein, welche Zertifizierungsstellen (CAs) Zertifikate für eine Domain ausstellen dürfen, und verhindert so, dass unbeabsichtigte CAs betrügerische Zertifikate ausstellen. | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
Hat eine Domain gar keinen CAA-Eintrag, gilt jede CA als zur Ausstellung berechtigt. Wildcard-Zertifikate benötigen zusätzlich ein eigenes issuewild-Tag. |
| PTR-Eintrag | Löst eine IP-Adresse zurück zu einem Hostnamen auf – die Umkehrung eines A-Eintrags. Wird in einer Reverse-Zone (in-addr.arpa / ip6.arpa) konfiguriert. | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
Viele Mailserver markieren E-Mails von Absendern ohne Reverse-PTR oder mit einem nicht zum A-Eintrag passenden PTR als Spam oder lehnen sie ab – das ist für Versandserver praktisch Pflicht. |
Tipps
- Bei Unsicherheit zu SPF, DKIM oder DMARC zunächst die aktuellen Einträge mit dem Werkzeug „SPF/DKIM/DMARC-Eintragsprüfung“ diagnostizieren und dann mit den Syntaxbeispielen dieser Seite vergleichen.
- Eine TTL von etwa einer Stunde (3600 Sekunden) ist für gewöhnliche Einträge ein sicherer Standardwert; kurz vor einer DNS-Migration auf etwa 300 Sekunden zu verkürzen beschleunigt die Umstellung, danach kann sie wieder erhöht werden.
- TXT-Eintragswerte über 255 Zeichen können automatisch in mehrere Zeichenketten aufgeteilt werden – beim Kopieren und Einfügen daher prüfen, ob die Anführungszeichen noch korrekt zusammenpassen.
- Wer zusätzlich das Format einer E-Mail-Adresse selbst prüfen möchte, findet das im Werkzeug „E-Mail-Adress-Formatprüfung“.
- Bei der Einführung eines neuen Versanddienstes DMARC zunächst mit p=none betreiben, ein bis zwei Wochen die Berichte beobachten und erst nach Bestätigung, dass keine Probleme vorliegen, auf eine durchsetzende Richtlinie umstellen – das ist der sicherere Weg.
Häufig gestellte Fragen
SPF prüft die Legitimität der Absender-IP-Adresse – also „von welchem Server wurde gesendet“ –, während DKIM die Integrität der Nachricht per digitaler Signatur prüft – also „ob der Inhalt verändert wurde“. Erst wenn beide bestanden werden, bietet die Absenderauthentifizierung wirksamen Schutz.
Rechtlich ist er nicht vorgeschrieben, aber große Empfänger wie Gmail und Yahoo Mail verlangen DMARC de facto von Massenversendern; ohne ihn steigt das Risiko, als Spam markiert oder abgelehnt zu werden, deutlich.
Häufige Ursachen sind ein MX-Ziel, das auf einen CNAME statt auf einen Hostnamen mit A-Eintrag zeigt, ein falsch gesetzter Prioritätswert oder ein Mailserver, der selbst nicht so konfiguriert ist, dass er E-Mails für diese Domain annimmt.
Einen A/AAAA-Eintrag verwenden, wenn die IP-Adresse fest ist und an der Domainwurzel (@) gesetzt werden soll; CNAME verwenden, wenn der Hostname als Alias für einen anderen Host dienen soll, etwa auf einen CDN-Endpunkt.
Im Normalbetrieb ist etwa eine Stunde (3600 Sekunden) üblich. Kurz vor einer Servermigration oder DNS-Umstellung auf etwa 300 Sekunden zu verkürzen sorgt dafür, dass die Änderung nach der Umstellung schneller wirkt.
Übrigens – die Geschichte hinter DNS-Einträgen und E-Mail-Authentifizierung
DNS ist vor allem dafür bekannt, Domainnamen mit IP-Adressen zu verknüpfen, doch tatsächlich gibt es neben A und AAAA noch viele weitere Eintragstypen mit jeweils eigener Rolle. Besonders bei der E-Mail-Zustellung ergeben mehrere Einträge – MX, TXT (das SPF/DKIM/DMARC trägt) und PTR – erst zusammen ein Urteil darüber, ob eine E-Mail „legitim und nicht gefälscht“ ist; fehlt auch nur einer, steigt das Risiko, im Spam-Ordner zu landen oder ganz abgelehnt zu werden.
Blickt man auf die Geschichte der Absenderauthentifizierung zurück, wurde SPF Anfang der 2000er-Jahre als Maßnahme gegen Spam vorgeschlagen, und DKIM, das auf die Erkennung manipulierter Nachrichteninhalte abzielt, wurde um 2007 standardisiert. Keines der beiden legte jedoch für sich genommen fest, was der Empfänger bei fehlgeschlagener Authentifizierung tun sollte – DMARC füllte diese Lücke 2012. DMARC bewertet die Ergebnisse von SPF und DKIM gemeinsam und liefert sowohl eine Durchsetzungsrichtlinie bei Fehlschlägen als auch einen Berichtsmechanismus, gewissermaßen als Kommandozentrale der Authentifizierung.
Manche DNS-Einträge haben sich aus historischen Gründen im Format verändert. Ein eigener Eintragstyp für SPF (RRTYPE 99) wurde 2006 in einem RFC einmal definiert, sorgte aber für Verwirrung bei der Umsetzung und wurde 2014 durch RFC 7208 offiziell verworfen – heute wird SPF ausschließlich über TXT-Einträge ausgedrückt. Ebenso besitzen DKIM und DMARC keinen eigenen Eintragstyp: Beide werden vollständig innerhalb von TXT-Einträgen mit einer bestimmten Syntax umgesetzt (Zeichenketten, die mit v=DKIM1 bzw. v=DMARC1 beginnen) – ein deutliches Zeichen dafür, wie erweiterbar DNS tatsächlich ist.