DMARC in Deutschland: Ergebnisse einer umfassenden Studie der .de-TLD

Nutzungsanalyse von 11,6 Millionen .de-Domains

Michael Hudak

16. Juli 2025

Einleitung: Absicherung der Domain

Methodik: Wie wir 11,6 Millionen .de-Domains analysierten

DMARC-Konfiguration im Detail: Richtlinien und Berichte

Bonus-Analyse: Eingehende DMARC DNS-Abfragen

Zusammenfassung

Abstrakt

E-Mail ist ständigen Bedrohungen wie Spoofing und Phishing ausgesetzt. Um dem entgegenzuwirken, verifizieren E-Mail-Authentifizierungsprotokolle wie SPF und DKIM die Herkunft von E-Mails. Es fehlten jedoch klare Anweisungen für den Umgang mit Authentifizierungsfehlern und die Berichterstattung.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) füllt diese Lücke. DMARC baut auf SPF und DKIM auf, indem es den Abgleich der Absender sicherstellt, den Domaininhabern die Möglichkeit gibt, Richtlinien für nicht authentifizierte E-Mails festzulegen, und Berichte über die Authentifizierungsergebnisse bereitstellt.

Unsere Analyse von über 11,6 Millionen .de-Domains ergab, dass 14 % einen DMARC-Eintrag haben. Von den Domains mit einem MX-Eintrag, d. h. sie sind für den E-Mail-Versand konfiguriert, verfügen 17 % über DMARC. Bei fast der Hälfte aller Domains ist die Richtlinie jedoch auf none eingestellt, was DMARC für diese unwirksam macht.

Das bedeutet, dass nur etwa 7 % aller Domains potenziell gegen E-Mail-Spoofing geschützt sind.

E-Mail ist ein grundlegender Bestandteil der modernen Kommunikation und erfüllt verschiedene Funktionen, von Geschäftstransaktionen und persönlicher Korrespondenz bis hin zu Marketing und Informationsverbreitung. Ihre weite Verbreitung macht sie jedoch auch zu einer Quelle für bösartige Aktivitäten. E-Mail-Spoofing, also Fälschung von Absenderadressen, und Phishing, bei dem betrügerische E-Mails verwendet werden, um unrechtmäßig an sensible Informationen zu gelangen, stellen aktuelle Bedrohungen dar, die das Vertrauen untergraben, den Ruf schädigen und finanzielle Schäden anrichten.

Um solchen Bedrohungen zu begegnen, wurden Mechanismen zur E-Mail-Authentifizierung entwickelt. Ihre Hauptfunktion besteht darin, zu überprüfen, ob der Eigentümer der Domain eine E-Mail autorisiert hat, die vorgibt, von einer bestimmten Domain zu stammen.

SPF

Sender Policy Framework (SPF) ist ein solches Protokoll, das es Domainbesitzern erlaubt, in ihren DNS-Einträgen (Domain Name System) die IP-Adressen autorisierter Mailserver aufzuführen. Die empfangenden Mailserver können diese Liste anschließend prüfen, um herauszufinden, ob die IP-Adresse des sendenden Servers autorisiert ist.

DKIM

DomainKeys Identified Mail (DKIM) ermöglicht das kryptografische Signieren ausgehender E-Mails. Domainbesitzer veröffentlichen einen öffentlichen kryptografischen Schlüssel in ihren DNS-Einträgen, und sendende Mailserver fügen eine digitale Signatur, die mit dem entsprechenden privaten Schlüssel erzeugt wurde, an E-Mail-Nachrichten an. Die Empfängerserver können dann den öffentlichen Schlüssel über DNS abrufen, um die Signatur zu validieren und so die Integrität der Nachricht zu überprüfen und ihren Ursprung zu authentifizieren.

DMARC

Obwohl SPF und DKIM grundlegende Überprüfungen bereitstellen, boten sie ursprünglich keine Möglichkeiten für Domainbesitzer, um explizite Anweisungen für Nachrichten zu erteilen, die diese Prüfungen nicht bestanden. Sie boten auch keine standardisierten Berichtsfunktionen. DMARC wurde entwickelt, um diese Einschränkungen zu beheben. DMARC verwendet SPF und DKIM und führt den Abgleich von Absenderadressen ein, die sicherstellt, dass die Domain in der sichtbaren From-Headerzeile mit den Domains übereinstimmt, die durch SPF und/oder DKIM validiert wurden. Darüber hinaus ermöglicht DMARC den Domainbesitzern, den Empfängern per DNS-Eintrag mitzuteilen, wie sie mit unautorisierten E-Mails umgehen sollen. Dafür gibt es die sogenannte Policy, z.B. p=none für die Überwachung, p=quarantine für die Verschiebung in die Quarantäne, oder p=reject für die komplette Ablehnung der E-Mail. DMARC umfasst auch eine Berichterstattung, die Domainbesitzer mit Rückmeldungen von Empfängerservern über Nachrichten versorgen, die vorgeben, von ihrer Domain zu stammen. Die Berichte enthalten Authentifizierungsergebnisse und Quell-IP-Adressen. Weitere Informationen über DMARC finden Sie in unserem Artikel. Wir haben auch E-Mail-Spoofing beschrieben.

Die Einführung von DMARC ist für moderne Unternehmen von großer Bedeutung. Sie verbessert den Schutz vor Domain-Missbrauch für Phishing und Spoofing und schützt so die Markenintegrität und die Sicherheit der Empfänger.

Ungeachtet der Vorteile ist ein Verständnis der praktischen Verbreitung und der Konfiguration von DMARC wichtig. Um dies zu klären, wurde eine umfassend angelegte Analyse durchgeführt, die sich auf die deutsche Top-Level-Domain (.de) konzentrierte. Die Untersuchung umfasste die Prüfung von DNS-Einträgen von über 11,6 Millionen aktiven .de-Domains. Ziel war es, die Verbreitung des DMARC-Einsatzes zu bestimmen, die konfigurierten Richtlinien zu bewerten und den Reifegrad der E-Mail-Authentifizierung innerhalb einer prominenten länderspezifischen Top-Level-Domain zu ermitteln.

Die Analyse des DMARC-Implementierungsstatus, selbst innerhalb einer einzelnen Top-Level-Domain, stellt ein bedeutendes Unterfangen dar. Daher wurde eine Methodik entwickelt, die auf eine umfangreiche Datenerfassung und strenge Analyseverfahren setzt. Die vorliegende Untersuchung konzentriert sich ausschließlich auf Organisationsdomains, die unter der Top-Level-Domain `.de` registriert sind, und schließt Subdomains von der Analyse aus.

Datenerfassung

Wir haben Domainnamen aus verschiedenen Quellen zusammengetragen, um eine umfassende Liste zu erstellen. Dazu gehören der Common Crawl URL-Index (insbesondere die Version CC-MAIN-2024-30), verschiedene öffentlich zugängliche Domainlisten und kommerzielle Domaindaten (Stand März 2025). Auf die Verwendung von .de-Zonendateien wurde in dieser Studie verzichtet, da diese in der Regel nicht von der DENIC freigegeben werden.

Die Rohdaten wurden auf Qualität und Eindeutigkeit geprüft. Wir haben die Domainvalidität anhand der Public Suffix List überprüft, um ungültige Einträge herauszufiltern, und uns ausschließlich auf Organisationsdomains konzentriert.

Es ist zu beachten, dass diese aggregierten Listen Domains enthalten können, die inzwischen abgelaufen sind oder nie registriert wurden. Außerdem besteht die Möglichkeit, dass einige Quellen Honeypots oder digitale Wasserzeichen (eindeutige Domainnamen, die eingefügt werden, um die Nutzung der Liste nachzuverfolgen) enthalten. In unserem spezifischen Quellenmix sind uns jedoch keine solcher Domains aufgefallen.

Datenerhebung

Wir verwendeten massdns, einen leistungsstarken Stub-Resolver, der für seine Fähigkeit bekannt ist, eine große Anzahl von DNS-Lookups gleichzeitig zu verarbeiten.

Wir wählten absichtlich ein Profil mit geringer Parallelisierung für massdns mit den Parametern hashmap-size 2, resolve-count 3 und retry never. Diese Konfiguration wurde gewählt, um die Last auf den öffentlichen Resolvern zu minimieren. Erste Tests zeigten, dass Wiederholungsversuche bei dieser Konfiguration extrem selten waren, sodass die Einstellung retry never akzeptabel war.

Um die Zuverlässigkeit zu gewährleisten und eine Überlastung eines einzelnen Anbieters zu vermeiden, haben wir massdns so konfiguriert, dass es einen Pool von 27 vertrauenswürdigen, öffentlichen DNS-Resolver abfragt, darunter bekannte Dienste wie Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1) und Quad9 (9.9.9.9). Die Abfragen wurden auf mehrere AWS EC2 Spot-Instanzen verteilt, um die Arbeitslast effektiv zu verwalten.

Alle DNS-Antworten (einschließlich Erfolge, Timeouts, Fehler wie NXDOMAIN usw.) wurden im newline-delimited JSON (ndjson)-Format protokolliert, einschließlich Metadaten wie Time-To-Live (TTL)-Werte und die spezifischen Resource Record (RR)-Daten innerhalb der ndjson-Ausgabe. Der gesamte Rohdatensatz belief sich auf etwa 20 GB.

Aufgrund der parallelen Datenerfassung über mehrere Instanzen war es möglich, dass dieselbe Domain mehr als einmal abgefragt wurde. Diese doppelten DNS-Antworteinträge wurden in der späteren Datenverarbeitungsphase identifiziert und herausgefiltert.

Für jede Domain in unserer Liste haben wir speziell nach den folgenden DNS-Eintragstypen gefragt:

• MX-Einträge (Mail Exchanger) für die Domain selbst.
• TXT (Text)-Einträge für die Domain selbst.
• TXT-Records für die entsprechende _dmarc-Subdomain (z. B. _dmarc.example.de) zum Abrufen der DMARC-Richtlinie.

Die DNS-Datenerfassung erfolgte in einem bestimmten Zeitraum zwischen dem 17. April 2025 und dem 23. April 2025. Die Abfrage von MX- und organisatorischen TXT-Einträgen dauerte etwa 4 Tage, während die spezifischen _dmarc-TXT-Einträge in 2 Tagen abgefragt wurden.

Verarbeitung der Daten

Die ndjson-Rohdaten wurden mit selbsterstellten Python-Skripten verarbeitet. Jede Zeile (die ein JSON-Objekt für eine einzelne DNS-Anfrage und -Antwort darstellt) wurde geparst und analysiert. Die relevanten Informationen wurden in einem strukturierten, für die Analyse geeigneten Format zusammengefasst.

In Anbetracht der Komplexität und der möglichen Variationen in der Syntax der DMARC-Datensätze haben wir speziell für dieses Projekt eine eigene Python-Bibliothek entwickelt. Diese Bibliothek wurde so konzipiert, dass sie robust gegen Parsing-Fehler ist und sich streng an die DMARC-Spezifikation in RFC 7489 hält.

Für SPF-Datensätze (die in TXT-Datensätzen auf der Ebene der Organisationsdomain zu finden sind) führten wir eine gezielte Analyse anstelle eines vollständigen, rekursiven Parsings durch. Unsere Skripte konzentrierten sich darauf, das Vorhandensein von SPF-Datensätzen zu identifizieren und Schlüsseleigenschaften zu extrahieren, wie z. B. den all-Mechanismus (~all, -all, ?all). SPF-Einträge wurden nicht rekursiv aufgelöst, da dies mehr DNS-Anfragen erfordern würde.

Um die Genauigkeit unserer Erfassungs- und Verarbeitungspipeline sicherzustellen, führten wir manuelle Validierungsprüfungen durch. Es wurde eine Zufallsstichprobe von Domains ausgewählt, deren relevante DNS-Einträge (MX, TXT, _dmarc.TXT) manuell mit dem Standard-Befehlszeilentool dig abgefragt wurden. Die über dig erhaltenen Ergebnisse wurden mit den von unserem System verarbeiteten Daten verglichen, um die Konsistenz und Korrektheit zu bestätigen.

Es wurden Optimierungen implementiert, um die Belastung der DNS-Server während der Datenerfassung so gering wie möglich zu halten. Die mit dieser Methode beschafften Datensätze stammen aus öffentlich zugänglichen Einträgen und sind selbst offen zugänglich. Darüber hinaus wurden bei der Verwaltung aller gesammelten Informationen ethische Standards und Datenschutzpraktiken eingehalten, um einen verantwortungsvollen Umgang während des gesamten Prozesses zu gewährleisten.

Unsere Ergebnisse zeigen, dass 1 627 705 Domains (14,08 %) einen gültigen DMARC-Eintrag besitzen. 8 965 078 Domains (77,57 %) haben mindestens einen MX-Eintrag, was auf eine beträchtliche Anzahl von Domains schließen lässt, die aktiv E-Mails senden und empfangen.

7 405 449 Domains haben einen MX-Eintrag, aber kein DMARC, was auf eine erhebliche Schutzlücke hinweist. Interessanterweise haben 68 076 Domains keinen MX-Eintrag, aber einen gültigen DMARC-Eintrag, was sich zwar nicht direkt auf die Zustellbarkeit von E-Mails für diese Domains auswirkt, aber auf ein Bewusstsein für die Bedeutung von DMARC hinweist. Darüber hinaus verfügen 1 559 629 Domains sowohl über einen MX- als auch einen DMARC-Eintrag, was eine vollständigere E-Mail-Konfiguration darstellt.

Ein genauerer Blick auf die DMARC-Richtlinien selbst zeigt unterschiedliche Ansätze. Von den gültigen DMARC-Einträgen ist ein beträchtlicher Teil (786 091 Einträge oder 47,05 %) mit einer p=none-Richtlinie konfiguriert. Während p=none wertvolle Berichte ermöglicht, ohne die E-Mail-Zustellung zu beeinträchtigen, blockiert es nicht aktiv betrügerische E-Mails. Dies trägt zu der Beobachtung bei, dass nur 7,65 % aller gültigen DMARC-Datensätze "effektiv" sind (d. h. eine andere Richtlinie als "none" haben).

Neben DMARC untersuchte unsere Studie auch die breitere E-Mail-Authentifizierungslandschaft. Wir fanden heraus, dass 6 342 102 Domains (54,88 %) einen SPF-Eintrag haben, was auf ein gutes Niveau der grundlegenden Absenderauthentifizierung hinweist. Allerdings haben 4 776 255 Domains (41,33 %) sowohl einen MX- als auch einen SPF-Eintrag, aber keinen DMARC-Eintrag, was darauf hindeutet, dass viele Domains ein gewisses Maß an E-Mail-Authentifizierung eingeführt haben, aber DMARC noch nicht für eine umfassende Durchsetzung der Richtlinien und Berichterstattung implementiert haben. Insgesamt haben 411 689 Domains (3,6 %) aller analysierten Domains eine gültige E-Mail-Auth-Konfiguration (SPF und DMARC ohne p=none). Es ist auch erwähnenswert, dass nur 0,06 % aller DMARC-Datensätze eine ungültige Syntax aufweisen, was auf eine allgemein gute Einhaltung der Syntax- und Formatierungsstandards hindeutet.

Abgesehen von unserem primären Fokus auf die DMARC-Verbreitung innerhalb der TLD .de gab es eine interessante Beobachtung: ein signifikantes Volumen an DNS-Anfragen, die speziell auf DMARC-Einträge auf Domains abzielen, die nicht aktiv für E-Mails genutzt werden.

Details der Beobachtung

Über einen Zeitraum von einem Monat haben wir die DNS-Abfrageprotokolle für acht Domains unter unserer Kontrolle überwacht, die sich auf verschiedene Top-Level-Domains (TLDs), einschließlich .de und .net, erstreckten. Obwohl diese Domains nicht aktiv in einer Weise genutzt werden, die DMARC-bezogene Abfragen auslösen sollte, beobachteten wir durchschnittlich etwa 73 TXT-Abfragen pro Domain und Tag, inklusive für die Subdomain _dmarc.

Methodik

Das DNS für diese acht Domains wird mit Amazon Web Services (AWS) Route 53 verwaltet. Route 53 ist der Cloud-DNS-Webdienst von AWS. Wir haben Route 53 so konfiguriert, dass detaillierte Abfrageprotokolle in AWS CloudWatch Logs exportiert werden.

Die gesammelten Protokolle erfassen Informationen über jede DNS-Anfrage, die für die gehosteten Zonen empfangen wird. Wir haben diese Protokolle dann aufgenommen und analysiert und insgesamt 118 001 DNS-Anfragen über alle Datensatztypen (A, AAAA, NS, MX, TXT usw.) für diese acht Domains während des Beobachtungsmonats verarbeitet. Unsere Analyse filterte speziell nach TXT-Datensatzanfragen, die an die DMARC-Subdomain gerichtet waren.

Warum ist dies bemerkenswert?

Diese Abfrageaktivität der dmarc-Datensätze ist besonders bemerkenswert, weil die überwachten Domains speziell so konfiguriert waren, dass sie keine E-Mail-Aktivitäten durchführen. Es handelte sich nicht um neu registrierte Domains, sondern um von uns erworbene "fallengelassene" Domains mit unterschiedlicher Historie, die zum Zeitpunkt der Überwachung inaktiv waren und nicht als absichtliche Honeypots eingerichtet wurden. Außerdem versenden wir keine E-Mails von diesen Domains.

Darüber hinaus waren ihre E-Mail-Authentifizierungsrichtlinien absichtlich streng: Der SPF-Eintrag (v=spf1 -all) verbietet ausdrücklich jedem Server, E-Mails in ihrem Namen zu versenden. Die DMARC-Richtlinie war auf p=reject eingestellt und wies die Empfänger an, alle E-Mails zurückzuweisen, die die Authentifizierungsprüfungen nicht bestanden - was angesichts der SPF-Richtlinie alle E-Mails umfassen würde, die angeblich von diesen Domains stammen. Folglich sollten Standard-DMARC-Vorgänge, wie z. B. die Erstellung von Berichten, die durch E-Mail-Zustellungsversuche ausgelöst werden, nicht stattfinden. Tatsächlich erhielten wir trotz der Konfiguration von Meldeadressen (rua und ruf) während des Beobachtungszeitraums keine DMARC-Meldungen, was das Fehlen eines legitimen E-Mail-Verkehrs oder von Auslösern für Standardmeldungen bestätigt. Daher gibt es für die häufigen externen Abfragen, die auf die dmarc-Datensätze abzielen, keine herkömmliche operative Erklärung, die mit der E-Mail-Zustellung oder DMARC-Meldemechanismen zusammenhängt.

Mögliche Erklärungen

Was könnte also die Ursache für diese Abfragen sein? Wir spekulieren über mehrere Möglichkeiten:

• Aktivitäten zur Reconnaissance: Böswillige Akteure oder automatische Erkundungstools können systematisch DMARC-Einträge für eine große Anzahl von Domains abfragen. Dies hilft Ihnen, die Sicherheitslage potenzieller Ziele abzubilden, zu verstehen, welche Domains die E-Mail-Authentifizierung erzwingen, oder einfach die Domainkonfigurationen als Teil umfassenderer Scanning-Aktivitäten zu inventarisieren. Das Vorhandensein (oder Nichtvorhandensein) und die Richtlinienebene (none, quarantine, reject) eines DMARC-Datensatzes können wertvolle Informationen liefern.
• Falsch konfigurierte Security Scanner: Automatisierte Schwachstellen-Scanner oder Sicherheitstools des Unternehmens sind möglicherweise falsch konfiguriert. Sie könnten bei jeder Domain, auf die sie stoßen oder die sie auflösen, Überprüfungen auf DMARC-Einträge durchführen, unabhängig davon, ob von der Domain erwartet wird, dass sie E-Mails versendet.
• Automatisierte Tools und Domain-Gültigkeitsprüfungen: Verschiedene internetweite Messplattformen, Bots oder Tools zur Überprüfung des Zustands und der Verfügbarkeit von Domains oder zur Erfassung allgemeiner Statistiken können DMARC-Abfragen als Teil ihrer Standard-DNS-Abfrage-Suite enthalten.
• Sicherheitsforscher: Andere Sicherheitsforscher, die groß angelegte Studien zur E-Mail-Authentifizierung oder DNS-Nutzung durchführen, könnten DMARC-Einträge in weiten Teilen des Internets abfragen, ähnlich wie unsere eigene Studie, was zu Abfragen gegen unsere überwachten Domains führt.

Relevanz: Verbreitetes Interesse an DMARC

Dieses zusätzliche Ergebnis steht zwar nicht im direkten Zusammenhang mit unserer zentralen .de-Analyse, verdeutlicht jedoch einen wichtigen Punkt: Es scheint ein weit verbreitetes, automatisiertes Interesse an DMARC-Konfigurationen im Internet zu geben, das weit über Domains hinausgeht, die aktiv an der E-Mail-Kommunikation beteiligt sind. Die Menge der Anfragen, die an im Wesentlichen inaktive Domains gerichtet sind, deutet darauf hin, dass verschiedene Akteure das Vorhandensein eines DMARC-Datensatzes und die damit verbundenen Richtlinien als ein wichtiges Signal ansehen. Es unterstreicht die wahrgenommene Bedeutung von DMARC in der breiteren Internet-Sicherheitslandschaft.

Projekte wie OpenIntel sind Beispiele für groß angelegte passive DNS-Datensammlungen, die wertvolle Einblicke in allgemeine DNS-Verkehrsmuster liefern. Solche Plattformen konzentrieren sich jedoch in der Regel nicht auf das von uns beobachtete spezifische Phänomen - die gezielte Abfrage von DMARC-Einträgen auf Domains, die keine E-Mails versenden. Unsere Beobachtung bietet einen kleinen Einblick in dieses spezifische, aktive Überwachungsverhalten im Zusammenhang mit der DMARC-Einführung selbst.

E-Mail-Authentifizierungsprotokolle wie SPF, DKIM und insbesondere DMARC sind für die Sicherheit des modernen E-Mail-Ökosystems von entscheidender Bedeutung. Unsere umfassende Analyse von mehr als 11,6 Millionen .de-Domains zeigt, dass es bei der Einführung von DMARC erhebliche Fortschritte gibt, wobei 7 % der Domains einen potenziell sicheren DMARC-Eintrag haben. Dies deutet auf einen Mangel an Bewusstsein und Engagement bei der Bekämpfung von E-Mail-basierten Bedrohungen wie Spoofing und Phishing hin.

Die beobachtete weit verbreitete, automatisierte Abfrage von DMARC-Einträgen auf Domains, die keine E-Mails versenden, unterstreicht die Bedeutung von DMARC in der breiteren Internet-Sicherheitslandschaft und deutet darauf hin, dass verschiedene Akteure - von Sicherheitsforschern bis hin zu potenziellen böswilligen Entitäten - DMARC-Konfigurationen aktiv überwachen und ihre Rolle bei der Bewertung der Sicherheitslage einer Domain erkennen.

Letztlich erfordert der Weg zu einer vollständig sicheren E-Mail-Umgebung kontinuierliche Anstrengungen. Unternehmen sollten der Implementierung und ordnungsgemäßen Konfiguration von DMARC Priorität einräumen und sich auf Durchsetzungsrichtlinien zubewegen, um ihre Markenintegrität zu schützen und die Empfänger zu bewahren. Da sich die digitale Bedrohungslandschaft weiterentwickelt, ist eine umfassende E-Mail-Authentifizierung nicht nur eine technische Empfehlung, sondern eine grundlegende Notwendigkeit für eine vertrauenswürdige Kommunikation.

DMARC Referenzblatt

DMARC Berichtsdaten

Quellcode des Forschungsprojekts