Testen, ob eine Domain gefälscht werden kann

Wie man das Ergebnis liest

Sind alle drei Antworten günstig (p=reject oder p=quarantine, mit abgedeckten sp/np): Die exakte Domain ist nicht direkt fälschbar. Das ist eine gute Basis, aber keine totale Garantie — die Konfiguration gehört regelmäßig auf Drift geprüft (neue nicht ausgerichtete Quelle, Wechsel des DNS-Dienstleisters), samt Überwachung der oben erwähnten Nebenvektoren.

Existiert der Eintrag, steht aber im p=none: Das ist die Beobachtungsphase, ein legitimer Schritt des Deployments — aber die Domain bleibt technisch fälschbar, solange die Richtlinie nicht verschärft ist. Kein Notfall, solange methodisch das Quelleninventar entsteht (siehe p=reject erreichen, ohne die Mails zu zerstören), aber eben auch kein Schutz.

Existiert kein Eintrag: Die Domain ist ohne jede Barriere fälschbar, genau als hätte es nie DMARC gegeben. Das ist der häufigste Fall bei Organisationen, die schlicht nie von dem Thema gehört haben — und die gute Nachricht ist, dass der erste Schritt (einen Eintrag im p=none zu veröffentlichen) kostenlos und sofort ist.

Warum dieser Test wiederholt werden muss, nicht punktuell

Eine heute korrekt geschützte Domain kann morgen wieder verwundbar werden, aus Gründen, die nichts mit einem Angriff zu tun haben: ein Wechsel des DNS-Hosters, der versehentlich den Eintrag löscht, eine Migration der E-Mail-Plattform, die die SPF-Konfiguration ändert, ohne DMARC anzurühren, oder ein simpler Bedienfehler bei einem technischen Eingriff. Deshalb verdient dieser Fälschbarkeits-Test, periodisch wiederholt zu werden, nicht nur einmal bei der ersten Compliance durchgeführt — idealerweise nach jeder Änderung der E-Mail-Infrastruktur und in regelmäßigen Abständen, auch ohne bekannte Änderung.

Ein Ergebnisbeispiel, Zeile für Zeile

Um diesen Test greifbar zu machen, hier, wie man einen realen DMARC-Eintrag Zeile für Zeile interpretiert, wie er beim Abfragen von _dmarc.exemple-unternehmen.de auftauchen könnte:

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@exemple-unternehmen.de

Zerlegen wir, was jedes Tag verrät. v=DMARC1 bestätigt, dass ein gültiger DMARC-Eintrag existiert — erste Frage positiv beantwortet. p=quarantine weist auf eine teilweise Durchsetzungsrichtlinie auf der Root-Domain hin — zweite Frage, gemischte Antwort: Es ist nicht none (also nicht völlig offen), aber es ist auch nicht reject (also nicht der maximale Schutz). sp=none ist hier das aufschlussreichste Detail: Die Subdomains haben keinerlei Durchsetzungsrichtlinie — dritte Frage, klar ungünstige Antwort. Ein Angreifer, dem die Fälschung der Root-Domain misslingt (dank quarantine), kann problemlos auf eine Subdomain ausweichen, wo sp=none das Feld frei lässt.

Diese Art von Zwischenkonfiguration — weder völlig offen noch völlig geschlossen — ist in Wirklichkeit sehr verbreitet und illustriert gut, warum die drei Fragen des Tests zusammen gestellt werden müssen: Eine günstige Antwort auf eine sagt nichts über die anderen beiden.

Warum dieser Test jeder anderen E-Mail-Sicherheitsdiskussion vorausgeht

Eine häufige Falle in Organisationen, die anfangen, sich für E-Mail-Sicherheit zu interessieren: direkt zu ausgefeilten Diskussionen zu springen — braucht es BIMI, welche Überwachungslösung für ähnliche Domains wählen, wie schult man die Teams gegen CEO-Fraud — ohne diesen grundlegenden Drei-Fragen-Test geprüft zu haben. Das ist ein kostspieliger Priorisierungsfehler: Alle diese fortgeschrittenen Maßnahmen setzen implizit voraus, dass die direkte Fälschung der exakten Domain bereits geschlossen ist. Zeit und Budget in die Überwachung ähnlicher Domains zu investieren, während die Hauptdomain offen bleibt, gleicht dem Anbringen einer ausgefeilten Alarmanlage an den Fenstern eines Hauses, dessen Eingangstür nicht einmal abgeschlossen ist.

Deshalb sollte dieser Test der allererste Schritt jeder E-Mail-Sicherheitsdiskussion in einer Organisation sein — vor dem Budget, vor der Werkzeugwahl, vor sogar der Entscheidung, wer das Projekt intern trägt. Die Antwort bedingt alles, was folgt.

Der Fall der Domains, die nie Mails senden

Ein oft vergessener Aspekt dieses Tests: Was tun mit den Domains im eigenen Bestand, die aber nie Post senden — Defensivmarken, alte Produktnamen, vorsorglich reservierte Domains? Die Antwort auf den Fälschbarkeits-Test für diese Domains sollte immer „maximal geschützt" sein, und zwar sofort, ohne Beobachtungsphase. Da nie eine legitime Mail von ihnen ausgeht, besteht keinerlei Risiko eines Fehlalarms, p=reject; sp=reject; np=reject direkt auf einer geparkten Domain zu veröffentlichen. Das ist oft der am schnellsten zu korrigierende Test der ganzen Liste: ein paar Minuten DNS-Konfiguration, ohne jede vorherige Überwachungsperiode, anders als bei einer aktiven Domain, wo das Inventar der legitimen Quellen Zeit braucht. Viele Organisationen entdecken, während sie dieses Inventar machen, dass sie weit mehr schlafende Domains besitzen, als sie dachten — alte Markennamen, bei einer Unternehmensübernahme gekaufte und seither nie bereinigte Domains, vorsorglich reservierte Varianten — und dass jede davon jahrelang weit offen blieb, kostenloses Ziel, das niemand überwachte.

Den Test in der Praxis machen

Diese drei Punkte manuell zu prüfen, erfordert das Abfragen der DNS-Einträge der Domain mit einem Abfragewerkzeug (dig, oder die Oberfläche des DNS-Hosters), dann das Interpretieren der DMARC-Syntax — zugänglich, aber es erfordert ein Minimum an technischer Vertrautheit, um sich nicht in einem Syntaxdetail zu irren.

Die schnellste und zuverlässigste Methode bleibt, die Domain durch den kostenlosen DMARC-Analyzer laufen zu lassen, der diese drei Prüfungen automatisch durchführt und in wenigen Sekunden ein klares Ergebnis liefert — aktuelle Richtlinie, Abdeckung der Subdomains, und Ausrichtung der Quellen, falls bereits ein Eintrag existiert. Es ist das Äquivalent eines Schwachstellen-Scanners, aber für eine einzige präzise und grundlegende Frage: Lässt sich diese Domain heute fälschen? Anders als ein generischer Schwachstellen-Scanner, der eine lange Liste zu sortierender und zu priorisierender Ergebnisse produziert, gibt dieser Test eine direkt umsetzbare Antwort, ohne Fachwissen, um sie zu interpretieren, noch zusätzliches Triaging, bevor entschieden wird, was zuerst zu beheben ist.

Der häufige Irrtum: „wir sind bei Microsoft, also sind wir geschützt"

Ein Missverständnis kehrt in fast jedem Gespräch über E-Mail-Sicherheit wieder: die Annahme, dass die Nutzung eines großen Anbieters — Microsoft 365, Google Workspace — automatisch bedeutet, dass die Domain gegen Fälschung geschützt ist. Das ist falsch, und der Test entlarvt es sofort. Diese Anbieter liefern die Werkzeuge, um SPF, DKIM und DMARC zu konfigurieren, aber sie richten nichts von sich aus ein. Eine völlig neue Microsoft-365-Domain hat oft ein korrektes SPF (weil der Anbieter es beim Onboarding vorschlägt), aber überhaupt keinen DMARC-Eintrag — und ist damit ebenso fälschbar wie eine Domain ganz ohne Anbieter. Der Test misst die tatsächlich veröffentlichte Konfiguration, nicht den Ruf des Anbieters, und genau deshalb ist er so aufschlussreich: Er erzwingt den Blick auf die reale DNS-Konfiguration, statt auf eine beruhigende, aber unbegründete Annahme.

Dasselbe gilt in die andere Richtung: Eine kleine, selbst gehostete Domain mit einem sorgfältig konfigurierten p=reject ist besser geschützt als die eines Großkonzerns, der DMARC nie über p=none hinausgebracht hat. Der Schutz hängt nicht von der Größe der Organisation oder dem Prestige des Anbieters ab, sondern allein von den drei faktischen Antworten des Tests. Diese Erkenntnis ist oft der Moment, in dem eine Organisation begreift, dass E-Mail-Sicherheit eine bewusste Handlung ist, kein Nebenprodukt der Anbieterwahl.

Zusammengefasst

Zu wissen, ob eine Domain fälschbar ist, erfordert weder tiefes Fachwissen noch ein langes Audit — drei faktische Fragen genügen: Existiert ein DMARC-Eintrag, in welcher Richtlinie, und sind die Subdomains abgedeckt. Das ist der Ausgangspunkt jeder Schutzstrategie gegen Fälschung, und die Frage, die man sich regelmäßig neu stellen muss, nicht nur beim Start eines Sicherheitsprojekts — eine heute korrekt konfigurierte Domain ist keine Garantie, es morgen ohne kontinuierliche Überwachung zu bleiben. Ein Test, der heute drei Minuten dauert, kann einen Vorfall verhindern, dessen Lösung weit mehr als drei Minuten kostet — an Zeit, an Geld und an wieder aufzubauendem Kundenvertrauen, wobei keines der drei so schnell zurückkehrt, wie es verloren ging.