DNS-Einträge erklärt: A, AAAA, CNAME, MX, TXT und CAA

DNS steht für Domain Name System und ist das Verzeichnis des Internets: Es übersetzt einen Namen wie cyberscale.dev in die Adresse eines Servers und sagt außerdem, wer Mails für die Domain annimmt, wer Zertifikate ausstellen darf und welche Server im Namen der Domain senden dürfen. Jede dieser Auskünfte ist ein DNS-Eintrag (englisch Resource Record), eine einzelne Zeile in der Zone der Domain. Der Typ der Zeile entscheidet, wofür sie gilt: A für die Website, MX für die Post, TXT für fast alles, was mit Absenderprüfung zu tun hat.

Geändert wird ein Eintrag dort, wohin die NS-Einträge der Domain zeigen, und das ist nicht immer der Anbieter, bei dem die Domain gekauft wurde. Wer im Kundenbereich des Registrars einen Eintrag ändert, während die Nameserver längst bei Cloudflare oder beim Webhoster liegen, ändert eine Zone, die niemand fragt. Das ist der häufigste Grund für „ich habe es eingetragen, aber es wirkt nicht“.

Wie ein DNS-Eintrag aufgebaut ist#

Jeder Eintrag hat dieselben fünf Teile. So sieht die Antwort für diese Domain aus, abgefragt am 19.10.2026:

cyberscale.dev.       600    IN   A       75.2.60.5
www.cyberscale.dev.   600    IN   CNAME   verdant-dasik-8926b2.netlify.app.

• Name: wofür der Eintrag gilt, die Domain selbst oder ein Name darunter wie www. Der Punkt am Ende heißt „vollständig, nichts mehr anhängen“.
• TTL: wie viele Sekunden ein Resolver die Antwort zwischenspeichern darf, hier 600, also zehn Minuten.
• Klasse: praktisch immer IN für Internet.
• Typ: A, AAAA, CNAME, MX, TXT und so weiter.
• Wert: die eigentliche Auskunft, je nach Typ eine Adresse, ein Name oder ein Text.

Die Grundlage sind RFC 1034 und RFC 1035 aus dem Jahr 1987. Seither sind Typen dazugekommen, am Aufbau der Zeile hat sich nichts geändert.

Die Typen im Überblick#

A und AAAA: wohin die Website zeigt#

Ein A-Eintrag (A Record) verknüpft einen Namen mit einer IPv4-Adresse, ein AAAA-Eintrag mit einer IPv6-Adresse (RFC 3596). Beide dürfen nebeneinander und mehrfach stehen. Mehrere A-Einträge für denselben Namen sind kein Widerspruch, sondern Verteilung: Der Resolver bekommt alle und der Browser nimmt einen davon.

Ein Fehler, der beim Umzug gern übersehen wird: Der A-Eintrag wird auf den neuen Server umgestellt, der AAAA-Eintrag zeigt noch auf den alten. Geräte mit IPv6 landen dann auf der alten Seite, alle anderen auf der neuen, und der Fehler lässt sich je nach Netz mal nachstellen, mal nicht. Wer umzieht, stellt beide um oder löscht den alten AAAA-Eintrag.

CNAME: ein Name für einen anderen Namen#

Ein CNAME sagt: Dieser Name ist nur ein anderer Name für jenen. www.cyberscale.dev zeigt oben auf einen Namen des Hosters, und erst dessen A-Einträge liefern die Adresse. Der Vorteil: Wechselt der Hoster seine Adressen, muss in der eigenen Zone nichts geändert werden.

Die Regel dazu ist streng. Neben einem CNAME darf unter demselben Namen nichts anderes stehen (RFC 1034, Abschnitt 3.6.2, bekräftigt in RFC 2181, Abschnitt 10.1). Deshalb ist ein CNAME auf der Domain selbst, der sogenannten Apex beispiel.at ohne www, nicht zulässig: Dort müssen SOA und NS stehen, meist auch MX und TXT. Viele Oberflächen verweigern den Eintrag, manche nehmen ihn an, und dann verschwinden Mail und SPF.

Anbieter lösen das unterschiedlich. Cloudflare etwa erlaubt einen CNAME an der Apex und liefert nach außen stattdessen die A-Einträge des Ziels aus (CNAME flattening), andere nennen dasselbe ALIAS oder ANAME. Ohne so eine Funktion bekommt die Apex einen A-Eintrag mit der Adresse, die der Hoster nennt, und nur www den CNAME.

MX: wer die Post annimmt#

Der MX-Eintrag nennt die Server, die Mails für die Domain annehmen, jeweils mit einer Zahl davor. Kleiner bedeutet zuerst. Für die alte Domain dieses Magazins:

cyberscale.io.   3600   IN   MX   10 mail3.meinehp.at.

Ein MX muss auf einen Hostnamen zeigen, nicht auf eine IP-Adresse und nicht auf einen CNAME (RFC 2181, Abschnitt 10.3). Warum die Zahl eine Reihenfolge ist und keine Gewichtung, und warum ein falscher MX gefährlicher ist als ein fehlender, steht in MX-Eintrag: Priorität und typische Fehler.

TXT: der Sammelplatz#

Ein TXT-Eintrag ist Freitext, und genau deshalb steht dort so viel. Für die Mail-Sicherheit sind es drei Einträge an drei Stellen:

cyberscale.io.                3600  IN  TXT  "v=spf1 mx include:_spf.meinehp.at ~all"
_dmarc.cyberscale.io.         3600  IN  TXT  "v=DMARC1; p=quarantine;"
selector._domainkey.beispiel.at.    IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN…"

• SPF steht auf der Domain selbst und listet die Server, die im Namen der Domain senden dürfen. Wie man ihn aufbaut und mit include nicht über das Limit von zehn Abfragen kommt: SPF-Eintrag erstellen und prüfen.
• DKIM steht unter <selector>._domainkey. Den Namen des Selectors liefert der Mailanbieter, und wer ihn nicht kennt, findet ihn im Header einer eigenen Mail: DKIM-Selector finden.
• DMARC steht unter _dmarc und sagt dem Empfänger, was mit Mails passieren soll, die SPF und DKIM nicht bestehen. Die Einrichtung im Zusammenhang erklärt SPF, DKIM und DMARC einrichten, den Weg von none zu reject DMARC-Policy.

Dazu kommen TXT-Einträge, die nichts mit Mail zu tun haben: Bestätigungscodes für die Search Console, Microsoft 365 oder andere Dienste. Sie stören nicht, solange sie unterschiedlich beginnen. Und unter _mta-sts steht ein TXT, der verschlüsselte Zustellung erzwingt, beschrieben in MTA-STS und TLS-RPT.

Eine Domain darf nur einen SPF-Eintrag haben. Zwei TXT-Einträge, die beide mit v=spf1 beginnen, machen SPF ungültig, der Empfänger wertet das als Fehler (permerror, RFC 7208, Abschnitt 3.2). Das passiert, wenn ein neuer Dienst eine fertige SPF-Zeile mitliefert und sie jemand neben die alte setzt, statt sie zu ergänzen. Ob das bei deiner Domain so ist, zeigt der E-Mail-Check, einen zusammengeführten Eintrag baut der SPF-Generator.

Ein Text in einem TXT-Eintrag ist auf 255 Zeichen je Zeichenkette begrenzt. Längere Werte wie ein DKIM-Schlüssel mit 2048 Bit werden in mehrere Zeichenketten geteilt, die der Empfänger ohne Leerzeichen zusammensetzt (RFC 7208, Abschnitt 3.3 beschreibt das für SPF). Die meisten Oberflächen erledigen das selbst. Wer den Schlüssel von Hand teilt und dabei ein Leerzeichen oder Anführungszeichen mitkopiert, hat einen ungültigen DKIM-Eintrag. Wie man den prüft, steht im selben Beitrag zum Selector, einen neuen Schlüssel erzeugt der DKIM-Generator.

CAA: wer Zertifikate ausstellen darf#

Ein CAA-Eintrag legt fest, welche Zertifizierungsstellen für die Domain Zertifikate ausstellen dürfen (RFC 8659). Öffentliche Zertifizierungsstellen müssen ihn vor jeder Ausstellung prüfen (Baseline Requirements des CA/Browser Forum). Fehlt er, darf jede.

beispiel.at.   IN   CAA   0 issue "letsencrypt.org"
beispiel.at.   IN   CAA   0 issuewild ";"
beispiel.at.   IN   CAA   0 iodef "mailto:sicherheit@beispiel.at"

issue erlaubt eine Stelle für normale Zertifikate, issuewild für Platzhalter-Zertifikate wie *.beispiel.at, hier mit ";" ganz verboten, und iodef nennt eine Adresse für Meldungen über abgelehnte Anträge. Wie viele Einträge das werden können, zeigt Let's Encrypt selbst: Die Domain letsencrypt.org erlaubte am 19.10.2026 sechs Zertifizierungsstellen, jede für beide Arten.

Vor dem Setzen nachsehen, wer heute die Zertifikate ausstellt. Wer einen CAA-Eintrag nur für Let's Encrypt setzt, während der Hoster für eine Subdomain eine andere Stelle nutzt, bekommt beim nächsten Erneuern dort kein Zertifikat mehr. Der Fehler fällt Wochen später auf, wenn das alte Zertifikat abläuft.

NS, SOA, PTR und SRV in Kürze#

NS nennt die Nameserver, die für die Zone zuständig sind. Sie stehen zweimal: beim Registrar in der übergeordneten Zone, etwa .at oder .de, und in der eigenen Zone. Wer den DNS-Anbieter wechselt, ändert sie beim Registrar.

SOA (Start of Authority) ist der Kopf der Zone: der primäre Nameserver, eine Kontaktadresse, eine Seriennummer und vier Fristen. Die letzte Zahl bestimmt, wie lange ein Resolver sich merkt, dass ein Name nicht existiert (RFC 2308). Deshalb wirkt ein frisch angelegter Eintrag manchmal träger als die Änderung eines bestehenden: Wer ihn kurz vorher abgefragt hat, hat sich das „gibt es nicht“ gemerkt.

PTR ist die Gegenrichtung, von der IP-Adresse zum Namen. Er steht nicht in der Zone der Domain, sondern beim Inhaber der IP-Adresse, also beim Hoster oder Zugangsanbieter. Für Mailserver ist er Pflicht: PTR-Record für den Mailserver prüfen und setzen.

SRV nennt für einen Dienst Priorität, Gewicht, Port und Server (RFC 2782). Mailprogramme können darüber ihre Einstellungen finden (RFC 6186). Bei Gmail zum Beispiel, abgefragt am 19.10.2026:

_imaps._tcp.gmail.com.        86400  IN  SRV  5 0 993 imap.gmail.com.
_submission._tcp.gmail.com.   86400  IN  SRV  5 0 587 smtp.gmail.com.

Die Zahl vor dem Port ist die Priorität, die zweite ein Gewicht für Server mit gleicher Priorität. 993 ist der Port für IMAP mit Verschlüsselung, 587 der für das Einliefern von Mails an den Ausgangsserver.

TTL: wie lange eine Antwort gilt#

Die TTL (Time to Live) ist die Zahl, die den meisten Ärger erklärt. Sie sagt jedem Resolver, wie lange er eine Antwort aufbewahren darf, bevor er neu fragen muss. Ein Resolver, der die Antwort mit TTL 3600 gerade geholt hat, liefert eine Stunde lang dieselbe, egal was in der Zone inzwischen steht.

Daraus folgt das ganze Vorgehen für Änderungen. Die Wartezeit nach einer Änderung ist nach oben durch die alte TTL begrenzt, durch den Wert, der vor der Änderung galt. Nichts wird im Netz „verteilt“: Die neue Antwort steht sofort auf dem zuständigen Nameserver, der Rest der Welt erfährt sie, wenn die alten Kopien ablaufen.

1. Einen Tag vor einem Umzug die TTL der betroffenen Einträge auf 300 Sekunden senken.
2. Die alte TTL abwarten. Stand dort 86400, ist das ein ganzer Tag.
3. Den Eintrag ändern, nach spätestens fünf Minuten ist die neue Adresse überall angekommen.
4. Danach die TTL wieder auf 3600 oder mehr setzen.

Die NS-Einträge beim Registrar haben eine eigene TTL, die die übergeordnete Zone vorgibt. Bei cyberscale.dev waren es am 19.10.2026 86400 Sekunden, ein Tag. Ein Wechsel des DNS-Anbieters braucht deshalb immer länger als eine einzelne Änderung, und daran lässt sich nichts beschleunigen.

DNS-Einträge abfragen#

Unter Linux und macOS mit dig, unter Windows mit nslookup oder PowerShell:

dig +short A cyberscale.dev
dig +short NS cyberscale.dev
dig +short TXT _dmarc.cyberscale.io

nslookup -type=MX cyberscale.io
Resolve-DnsName cyberscale.io -Type TXT

Ohne +short zeigt dig die TTL in der zweiten Spalte, und zwar die verbleibende: Fragt man denselben Resolver eine Minute später noch einmal, ist sie um 60 kleiner. Die verbindliche Antwort liefert nur der zuständige Nameserver selbst, mit @ davor gefragt:

dig @curitiba.ns.porkbun.com A cyberscale.dev

Steht dort schon der neue Wert und beim eigenen Resolver noch der alte, ist alles richtig eingetragen und nur die TTL läuft noch.

Ohne Kommandozeile liefert Googles öffentlicher Resolver dieselbe Antwort im Browser, etwa für cyberscale.io, Typ TXT. Für die Einträge rund um die Post, MX, SPF, DKIM und DMARC auf einmal, mit Bewertung, gibt es den E-Mail-Check. Ob die Adressen hinter den MX-Namen auf einer Sperrliste stehen, zeigt der Blacklist-Check.

Wo man DNS-Einträge ändert#

Zuerst klären, wer die Zone verwaltet: dig +short NS deinedomain.at. Die Antwort nennt die Nameserver, und deren Betreiber ist die Stelle, an der geändert wird. Drei Fälle kommen bei Betrieben in Österreich und Deutschland fast immer vor:

• Domain, Website und Mail beim selben Hoster. Die Nameserver gehören dem Hoster, die Einträge stehen im Kundenbereich, je nach Anbieter unter DNS-Verwaltung, DNS-Einstellungen, Zoneneditor oder Nameserver-Einträgen.
• Domain beim Registrar, Nameserver bei einem anderen Dienst, etwa Cloudflare. Dann ist die DNS-Seite im Kundenbereich des Registrars wirkungslos, auch wenn sie sich bearbeiten lässt.
• Mail bei Microsoft 365 oder Google Workspace. Die nennen die nötigen Einträge, setzen sie aber nicht selbst, außer der Hoster hat eine Anbindung dafür. Eingetragen wird beim DNS-Anbieter.

Wo bei verbreiteten Anbietern die Schalter für DKIM und DMARC sitzen, mit Klickpfaden, steht in DKIM und DMARC beim Hoster einschalten.

Typische Fehler#

• CNAME auf der Domain selbst. Nicht zulässig, siehe oben. Folge: MX und TXT werden ignoriert, die Post bleibt aus.
• Zwei SPF-Einträge. Einen davon löschen und die Angaben in einem zusammenführen.
• Der Name doppelt. Viele Oberflächen hängen die Domain selbst an. Wer _dmarc.beispiel.at ins Namensfeld schreibt, bekommt _dmarc.beispiel.at.beispiel.at. Ins Feld gehört nur _dmarc. Die Abfrage danach zeigt sofort, ob es stimmt.
• MX auf eine IP-Adresse oder einen CNAME. Unzulässig, manche Absender stellen trotzdem zu, andere nicht.
• Verwaiste Einträge für Subdomains. Ein CNAME zeigt noch auf einen gekündigten Dienst. Wer dort den Namen neu registriert, betreibt dann eine Subdomain der fremden Domain. Microsoft beschreibt diesen Angriff als Übernahme von Subdomains über verwaiste DNS-Einträge. Bei jeder Kündigung eines Dienstes den Eintrag gleich mitlöschen.
• AAAA vergessen. Siehe A und AAAA oben.
• Änderung ohne gesenkte TTL. Die alte Antwort hält sich dann bis zu einem Tag, und in der Zeit wird an der falschen Stelle gesucht.

Was nicht hilft#

Eine Karte voller grüner Punkte abwarten. Sogenannte Propagation-Checker fragen eine Handvoll öffentlicher Resolver und zeigen, was die gerade gespeichert haben. Das ist eine Stichprobe, kein Fortschrittsbalken. Die Antwort des zuständigen Nameservers ist der einzige Stand, der zählt.

Den Eintrag mehrmals ändern, weil er „nicht greift“. Jede Änderung startet die Wartezeit bei den Resolvern, die schon die vorletzte Fassung haben, von neuem und macht die Fehlersuche schwerer.

Den DNS-Zwischenspeicher am eigenen Rechner leeren und daraus schließen, dass es jetzt überall geht. ipconfig /flushdns leert nur den Speicher des eigenen Betriebssystems. Der Resolver des Zugangsanbieters und jeder Absender, der dir eine Mail schicken will, haben ihre eigene Kopie.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Die meisten DNS-Fragen in Betrieben drehen sich um die Post. Der E-Mail-Schutz für 390 € setzt SPF, DKIM und DMARC beim bestehenden Anbieter, schrittweise bis reject, mit vier Wochen Auswertung der Berichte. Wer vorher wissen will, was die eigene Zone hergibt, prüft sie kostenlos mit dem E-Mail-Check.

Häufige Fragen#

Stand 27.11.2026. Quellen abgerufen und Abfragen per DNS-over-HTTPS (Cloudflare) am 19.10.2026.