DNSSEC und DMARC: das Fundament unter der Authentifizierung

Von Thomas · virtueller CISO · 2026-08-07

Eine vollständige E-Mail-Authentifizierung passt in eine Handvoll DNS-Einträge: ein TXT an der Wurzel der Domain für SPF, ein TXT unter selektor._domainkey für DKIM, ein TXT unter _dmarc für die Richtlinie. Das ist elegant — keine Infrastruktur, die auszurollen wäre, keine Software, die installiert werden müsste. Es ist zugleich eine Abhängigkeit: die drei Protokolle sind genau so viel wert wie die DNS-Antwort, die sie transportiert. Ein Angreifer, der anstelle des legitimen Servers antworten kann, bricht weder SPF noch DKIM noch DMARC; er ersetzt sie. DNSSEC ist die Schicht, die eine solche Vertauschung erkennbar macht.

Wer das Zusammenspiel dieser drei Protokolle erst kennenlernt, findet in was DMARC ist die Grundlagen, bevor es um das geht, worauf sie ruhen.

Was DNSSEC signiert, und was nicht

DNSSEC (RFC 4033 bis 4035) fügt jedem Eintragssatz einer Zone eine kryptografische Signatur hinzu. Ein signierter TXT-Eintrag wird von einem RRSIG begleitet; der öffentliche Schlüssel, mit dem sich dieser prüfen lässt, steht in einem DNSKEY; und der Fingerabdruck dieses Schlüssels wird beim Elternteil hinterlegt, in einem DS-Eintrag. Genau dieser Fingerabdruck beim Elternteil bildet das Kettenglied: Die Root signiert die TLD, die TLD signiert die Domain, und ein validierender Resolver verfolgt diese Kette bis zu einem Vertrauensanker zurück, den er von vornherein kennt.

Die Unterscheidung zwischen DNSKEY und DS verdient einen kurzen Halt, denn sie ist die Quelle eines häufigen Fehlalarms. Eine Zone kann durchaus einen DNSKEY veröffentlichen und sämtliche Einträge signieren, ohne dass beim Elternteil ein DS existiert. Technisch ist die Zone signiert. Praktisch steht sie nicht in der Vertrauenskette: Nichts verbindet ihren Schlüssel mit der Root, also kann kein Resolver ihre Signatur von einer Fälschung unterscheiden, die ein Angreifer mit einem eigenen DNSKEY erzeugt hat. Deshalb entscheidet sich die Frage „ist diese Domain durch DNSSEC geschützt?" am DS und nicht am DNSKEY.

Was DNSSEC liefert, ist Authentizität und Integrität der DNS-Antworten. Was es nicht liefert, ist Vertraulichkeit: Eine DNSSEC-Anfrage läuft im Klartext, und jeder Beobachter im Netz sieht, welche Domains abgefragt werden. Die Verschlüsselung des DNS-Transports gehört zu getrennten Mechanismen (DoH, DoT), die eine andere Frage beantworten und die Signatur nicht ersetzen.

Der konkrete Angriff: ein permissives SPF ausliefern

Das direkteste Szenario verlangt nicht, die Kryptografie von DKIM zu brechen. Es verlangt, schneller oder aus einer privilegierten Position auf die TXT-Anfrage zu antworten, die der empfangende Server stellt.

Ein Server, der eine Nachricht entgegennimmt, fragt das DNS nach dem SPF der absendenden Domain. Platziert ein Angreifer dort seine eigene Antwort — Cache Poisoning, eine Position auf dem Netzwerkpfad, ein kompromittierter Resolver —, kann er zurückgeben:

v=spf1 +all

Der Empfänger wendet an, was er bekommen hat. Jeder beliebige Server wird damit zum autorisierten Absender, und die gefälschte Nachricht besteht SPF. Die legitime Domain hat an ihrer Konfiguration nichts verändert; sie hat schlicht keine Möglichkeit zu beweisen, dass die ausgelieferte Antwort die ihre war.

Dieselbe Logik gilt für DKIM, mit noch stärkerer Wirkung. Der öffentliche Schlüssel wird im DNS veröffentlicht, unter dem Selektor, den der Signatur-Header der Nachricht nennt. Ein Angreifer, der die DNS-Antwort für diesen Selektor kontrolliert, veröffentlicht seinen eigenen öffentlichen Schlüssel, signiert die gefälschte Nachricht mit dem passenden privaten Schlüssel und erhält eine Signatur, die einwandfrei validiert. Die Kryptografie von DKIM ist intakt; entführt wurde die Verteilung des Schlüssels.

Was das speziell für DMARC ändert

DMARC bringt eine Eigenschaft mit, die weder SPF noch DKIM besitzen: Das Ausbleiben einer Antwort ist selbst ein verwertbares Ergebnis.

Findet ein Empfänger unter _dmarc.beispiel.de keinen Eintrag, wendet er überhaupt keine Richtlinie an. Keine Ablehnung, keine Quarantäne — die Nachricht wird behandelt, als käme sie von einer Domain, die DMARC nie veröffentlicht hat. Ein Angreifer muss also nicht einmal einen glaubwürdigen Eintrag fälschen: es genügt, die Antwort verschwinden zu lassen. Ein gefälschtes NXDOMAIN oder ein durch v=DMARC1; p=none ersetzter Eintrag erzeugen denselben Effekt — der Schutz erlischt, ohne dass irgendetwas es dem Inhaber der Domain meldet.

Aus diesem Grund bleibt eine in einer unsignierten Zone veröffentlichte p=reject-Richtlinie ein asymmetrischer Schutz. Sie stoppt das Massen-Spoofing, das ohne jede DNS-Manipulation auskommt — die überwältigende Mehrheit der Kampagnen. Sie stoppt keinen Angreifer, der sich auf die Auflösung setzen kann, und genau das ist das Profil eines gezielten Angriffs. Der Weg von p=none zu p=reject bleibt die Priorität; DNSSEC ist dessen Ergänzung, nicht dessen Voraussetzung.

Was DNSSEC nicht löst

Die Zonensignierung als Antwort auf Spoofing zu präsentieren, wäre irreführend. Sie ist keine.

DNSSEC garantiert, dass die ausgelieferten SPF-, DKIM- und DMARC-Einträge tatsächlich die sind, die die Domain veröffentlicht hat. Sind diese Einträge abwesend, permissiv oder falsch konfiguriert, liefert DNSSEC sie getreu so aus, wie sie sind — ein authentisches v=spf1 +all bleibt ein v=spf1 +all. Die Signatur schützt die Übertragung der Richtlinie, niemals deren Qualität. Eine signierte Domain ohne DMARC ist exakt so leicht zu usurpieren wie eine unsignierte Domain ohne DMARC.

Die zweite Grenze ist betrieblicher Natur: Die Validierung muss irgendwo stattfinden. Die großen öffentlichen Resolver validieren, und ein erheblicher Teil der Mailserver stützt sich auf sie, aber ein Resolver, der nicht validiert, ignoriert Signaturen schlicht. Eine signierte Domain ist damit nur auf den Pfaden geschützt, auf denen jemand prüft — was eine reale Verbesserung bleibt, aber keine Ende-zu-Ende-Garantie.

Die dritte Grenze, und das ist der eigentliche Preis: DNSSEC scheitert geschlossen. Eine abgelaufene Signatur, ein schlecht sequenzierter Schlüsselwechsel, ein DS, der mit dem tatsächlichen Schlüssel nicht mehr übereinstimmt — und ein validierender Resolver antwortet mit SERVFAIL, das heißt, die Domain existiert für ihn nicht mehr. Nicht nur für die Post: für das Web, für die API, für alles. Die einprägsamsten DNSSEC-Ausfälle sind keine Angriffe, es sind Signaturabläufe an einem Sonntagmorgen. Die Kehrseite des Schutzes ist eine betriebliche Disziplin, die vor dem Signieren zu akzeptieren ist.

Die Verbindung zu MTA-STS und DANE

Die Existenz von MTA-STS erklärt sich aus genau dieser Debatte, und die Gegenüberstellung erhellt beide Protokolle.

DANE (RFC 7672) veröffentlicht den Fingerabdruck des TLS-Zertifikats des Mailservers in einem TLSA-Eintrag. Der Mechanismus ist elegant und hängt von keiner Zertifizierungsstelle ab — aber er setzt DNSSEC voraus: Ohne Signatur wäre der veröffentlichte Fingerabdruck genauso fälschbar wie das Zertifikat, das er zu bezeugen vorgibt. DANE ohne DNSSEC ergibt buchstäblich keinen Sinn.

MTA-STS wurde für Betreiber entworfen, die DNSSEC nicht ausrollen konnten oder wollten. Es verlagert das Vertrauen auf HTTPS und das Ökosystem der Zertifizierungsstellen: Die Richtlinie wird über https://mta-sts.beispiel.de/.well-known/mta-sts.txt abgeholt, und maßgeblich ist das TLS-Zertifikat dieses Servers. Beide Protokolle beantworten denselben Bedarf — das Downgrade der SMTP-Verschlüsselung zu verhindern — mit zwei unterschiedlichen Vertrauenswurzeln. Eine bereits signierte Zone macht DANE ohne Zusatzaufwand verfügbar; eine unsignierte Zone macht MTA-STS zur einzigen Option.

Den Zustand einer Zone prüfen

Die Kontrolle besteht aus einer einzigen Anfrage, und sie zielt auf das DS beim Elternteil:

dig DS beispiel.de +short

Eine nicht leere Antwort weist auf eine signierte Delegation hin. Eine leere Antwort bedeutet, dass die Zone nicht in der Vertrauenskette steht, unabhängig davon, was der DNSKEY veröffentlicht. Eine nützliche ergänzende Lesart besteht darin, den Resolver selbst nach seinem Validierungszustand zu fragen:

dig beispiel.de +dnssec +multi

Das Vorhandensein des ad-Flags (authenticated data) in der Antwort zeigt an, dass der Resolver die Kette validiert hat. Sein Fehlen ist für sich genommen nicht schlüssig: Es bedeutet „nicht validiert", was sowohl eine unsignierte Zone als auch einen nicht validierenden Resolver abdeckt.

Ein Punkt verdient im Betrieb Aufmerksamkeit: Ein SERVFAIL auf einer Zone, die signiert sein sollte, ist nicht dasselbe wie fehlendes DNSSEC. Es ist exakt das, was ein validierender Resolver bei einer gebrochenen Signatur zurückgibt — also ein laufender Vorfall und keine noch zu vervollständigende Konfiguration. Beides zu verwechseln führt dazu, „DNSSEC zu aktivieren" bei einer Domain zu diagnostizieren, deren Kette gerade gerissen ist.

Der Zustand der Delegation erscheint auch in der E-Mail-Sicherheits-Scorecard, neben SPF, DKIM, DMARC, BIMI und MTA-STS: Die gemeinsame Lektüre verhindert, jedes Protokoll als getrenntes Thema zu behandeln, obwohl alle auf demselben Fundament ruhen. Festgestellt wird dort die signierte Delegation — das Vorhandensein des DS beim Elternteil — und nicht die vollständige Validierung der Kette (DS ↔ DNSKEY ↔ RRSIG, Algorithmen, Ablaufdaten), die Sache eines eigenen Validators ist. Für die DMARC-Richtlinie selbst liefert der kostenlose DMARC-Analyzer die ausführliche Bilanz.

Die Reihenfolge der Arbeiten

Die Reihenfolge ergibt sich daraus, was am frühesten schützt.

Eine Domain ohne DMARC wendet DNSSEC auf eine Konfiguration an, die vor nichts schützt: Die Signatur garantiert die Treue einer Richtlinie, die es nicht gibt. Die sinnvolle Sequenz beginnt also damit, SPF und DKIM zu veröffentlichen, dann DMARC im Beobachtungsmodus, und dann die Richtlinie bis p=reject zu härten. Dieser Weg entfernt das Massen-Spoofing — das reale Volumen der Angriffe.

DNSSEC kommt danach, und es kommt umso früher, je stärker eine Domain gezielten Angriffen ausgesetzt ist: Banken, Gesundheitswesen, Verwaltung, jeder Sektor, in dem ein Gegner sowohl Mittel als auch ein konkretes Interesse hat. Für solche Domains lässt eine unsignierte p=reject-Richtlinie den einen Weg offen, der noch zählt, wenn alles andere geschlossen ist.

Zwei technische Details lohnen sich zum Zeitpunkt des Signierens. Algorithmus 13 (ECDSAP256SHA256) erzeugt deutlich kompaktere Signaturen als Algorithmus 8 (RSASHA256), was die Antwortgrößen und das Fragmentierungsrisiko senkt; das ist heute die vernünftige Vorgabe. Und die meisten DNS-Hoster erledigen den Schlüsselwechsel inzwischen automatisch, was die historische Hauptursache für Ausfälle beseitigt — vorausgesetzt, das beim Registrar hinterlegte DS wird von derselben automatischen Kette aktualisiert und nicht von Hand eingefroren.

Und schließlich hat die Grenze von zehn DNS-Anfragen bei SPF nichts mit DNSSEC zu tun, doch in der Praxis begegnen sich beide: Eine signierte Zone liefert umfangreichere Antworten, und ein SPF-Eintrag, der diese Obergrenze bereits streift, gehört saniert, bevor der Zone irgendetwas hinzugefügt wird.

Kurz gefasst

DNSSEC ersetzt weder SPF noch DKIM noch DMARC. Es schützt den Kanal, über den diese drei Protokolle übertragen werden — und ohne es kann ein Gegner, der die Auflösung manipulieren kann, ein permissives SPF ausliefern, einen falschen DKIM-Schlüssel veröffentlichen oder die DMARC-Richtlinie verschwinden lassen, ohne die anvisierte Domain je zu berühren.

Die richtige Einordnung lautet: Die E-Mail-Authentifizierung wird zuerst ausgerollt, weil sie das Volumen stoppt; die Zonensignierung wird danach ausgerollt, weil sie die verbleibende Tür schließt. Und für tatsächlich anvisierte Domains heißt „danach" bald.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos