Zum Inhalt springen
← Blog

DMARC-Analyzer: die Funktionen, die wirklich zählen

Von Thomas · virtueller CISO · 19. August 2026

Die Entscheidung, DMARC mit einem Tool zu unterlegen, ist gefallen. Gute Nachricht. Schlechte Nachricht: Die Kategorie „DMARC-Analyzer" reicht vom Gadget, das XML umformatiert, bis zum Copiloten, der genau nennt, welche Quelle zu korrigieren ist und wie. Dazwischen liegt ein Abgrund. Dieser Leitfaden erklärt nicht, wie man einen Bericht liest — darum geht es in den besten Tools zur Analyse der DMARC-Berichte, einem Überblick, der die Tool-Kategorien durchgeht. Hier stehen wir einen Schritt später: Ein Tool ist auszuwählen, und dafür braucht es eine objektive Kriterienliste. Ob das Tool kostenlos ist oder mehrere hundert Euro im Monat kostet, diese Kriterien gelten gleichermaßen. Einmal angewandt, verraten sie innerhalb von zehn Minuten, ob ein Kandidat die investierte Zeit verdient.

Ein Wort vorab: Nicht jedes Kriterium unten zählt für jeden gleich viel. Der Besitzer einer einzigen Domain mit zwei stabilen Versandquellen braucht weit weniger Funktionen als ein Dienstleister, der fünfzig Kunden-Domains verwaltet. Ich weise jedes Mal darauf hin. Das Ziel ist nicht der Kauf des teuersten Tools, sondern des richtigen — und manchmal reicht das kostenlose völlig aus.

Kriterium 1 — Quellenidentifikation, nicht nur IPs

Das ist das Königskriterium. Ein roher DMARC-Bericht meldet, dass 412 Nachrichten von 40.107.22.15 gesendet wurden. Ein Analyzer, der seinen Namen verdient, nennt diese IP als Microsoft 365 Exchange Online. Der Unterschied ist nicht kosmetisch: Beim Blick auf eine nackte IP lässt sich nichts entscheiden. Unklar bleibt, ob es der eigene Tenant ist, ein legitimer Dienstleister oder ein Betrüger. In dem Moment, in dem das Tool „das ist der M365-Tenant" oder „das ist die E-Mail-Plattform" nennt, wird aus Beobachtung Handlung.

Ein gutes Tool reichert jede Quell-IP mit dem Namen der Organisation (dem ASN) an, dem Land und idealerweise einer Erkennung des Dienstes (Microsoft, Google Workspace, eine Marketing-Plattform, ein Cloud-Hoster). Ohne diese Schicht vergehen ganze Abende damit, IPs in WHOIS-Abfragen zu kopieren. Das ist genau die Arbeit, die ein Tool abnehmen soll. Zeigt ein Kandidat IPs, benennt sie aber nie, gehört er von der Liste gestrichen: Er überlässt den schweren Teil.

Dieses Kriterium zählt für alle, von der einzelnen Domain bis zur Flotte von fünfzig. Niemand will rohe IPs lesen.

Kriterium 2 — Ausrichtungs-Aufschlüsselung pro Quelle

DMARC zu bestehen ist nicht einfach „bestehen": Es ist ausgerichtet bestehen. Eine Quelle kann SPF haben, das für den Umschlag besteht, aber nicht für das sichtbare From:, oder eine gültige DKIM-Signatur, die auf der falschen Domain liegt. Diese Feinheiten bestimmen genau, was zu korrigieren ist. Ein Tool, das nur „87 % Konformität" meldet, ohne SPF und DKIM pro Quelle aufzuschlüsseln, lässt beim Was tun blind.

Zu sehen sein muss, Quelle für Quelle: Besteht SPF? Ist es ausgerichtet? Besteht DKIM? Ist es ausgerichtet? Diese vier Kästchen, für jeden Absender, sind die Behebungs-Roadmap. Eine Quelle, bei der DKIM besteht, aber nicht ausgerichtet ist, wird durch Veröffentlichen des richtigen Schlüssels behoben — ein völlig anderer Eingriff als bei einer Quelle, deren SPF sein Lookup-Limit überschreitet. Steigt der Analyzer nicht auf diese Ebene hinab, bleibt für immer unklar, welcher Hebel zu betätigen ist. Um die zugrunde liegende Mechanik zu verstehen, erläutert aggregierte DMARC-Berichte verstehen, was jedes Feld bedeutet.

Ein wesentliches Kriterium für jeden mit mehr als einer Quelle. Eine sehr einfache Ein-Quellen-Domain kann darauf verzichten, aber sobald es zwei Dienstleister gibt, wird die Aufschlüsselung pro Quelle unverzichtbar.

Kriterium 3 — Trend über die Zeit, keine Momentaufnahme

Ein einzelner Bericht ist eine Momentaufnahme. Er zeigt den Zustand eines Tages. Das Problem: Viele Quellen senden nicht jeden Tag. Die Plattform, die den monatlichen Newsletter versendet, das HR-Tool, das einmal im Monat Gehaltsabrechnungen erstellt, der Event-Dienstleister, der nur zweimal im Jahr schreibt — keiner wird in einer Momentaufnahme erscheinen, die am falschen Tag gemacht wurde. Eine auf einer einzigen Momentaufnahme verschärfte Policy riskiert, eine legitime Quelle zu zerstören, die schlicht noch nicht sichtbar war.

Ein echter Analyzer bewahrt eine Historie und zeigt die Entwicklung: Quellen, die auftauchen, solche, die sich langsam verschlechtern, solche, die nur gelegentlich senden. Ohne Historie lässt sich die Entscheidung, auf reject zu gehen, nicht mit Zuversicht treffen, weil unklar bleibt, ob die Berichte dauerhaft sauber sind oder nur heute. Es ist auch das, was einen Vorher-Nachher-Vergleich bei einer Konfigurationsänderung erlaubt: Ein DKIM-Schlüssel wird veröffentlicht, und die Ausrichtungskurve soll in den folgenden Tagen steigen.

Dieses Kriterium zählt umso mehr, je komplexer das Ökosystem wird. Eine Domain mit zwei täglichen Quellen sieht schnell, ob alles sauber ist; eine Domain mit monatlichen Quellen braucht mehrere Wochen Historie vor jeder Entscheidung.

Kriterium 4 — Umsetzbare Behebung, kein XML-Dump

Das ist das Kriterium, das reife Tools wirklich von Betrachtern trennt. Viele Analyzer bleiben bei „hier sind die Daten, hübsch formatiert" stehen. Das ist besser als rohes XML, aber es lässt immer noch die gesamte Interpretationsarbeit offen. Ein reifes Tool nennt, was zu tun ist: „Die Marketing-Plattform signiert mit DKIM unter ihrer eigenen Domain, nicht der des Absenders — hier ist der zu veröffentlichende Eintrag" oder „diese SPF-Quelle überschreitet das Lookup-Limit, der Eintrag muss abgeflacht werden".

Der Unterschied in der Praxis: Ohne Rat scheitert eine Quelle sichtbar, aber warum und wie sie zu reparieren ist, bleibt Ratearbeit — oft eine Stunde Websuche. Mit Rat reicht das Tool die präzise Korrektur, in Prioritätsreihenfolge. Genau hier hebt sich der Copilot von DMARC.com, Thomas, ab: Er liefert nicht noch ein Dashboard, sondern verwandelt die Daten in einen Aktionsplan, ausgerichtet auf den Weg von p=none zu p=reject. Visualisierung nennt das was; Rat nennt das was zu tun ist. Die beiden spielen nicht in derselben Liga.

Dieses Kriterium zählt für alle, und besonders für jeden ohne DMARC-Experten zur Hand. Wo der Experte im Haus sitzt, mögen gute Daten reichen; sonst ist der Rat Gold wert.

Kriterium 5 — Alarme bei den Ereignissen, die zählen

DMARC ist kein einmaliges Projekt, es ist kontinuierliches Monitoring. Und niemand meldet sich jeden Tag an einem Dashboard an. Deshalb ist der Alarm ein strukturierendes Kriterium: Das Tool muss warnen, wenn etwas Aufmerksamkeit verdient, ohne dass jemand danach suchen muss. Zwei Ereignisse zählen besonders. Das erste: Eine neue Quelle taucht auf — ein nie gesehener Dienst beginnt im Namen der Domain zu senden. Das ist entweder ein neuer legitimer Dienstleister zum Ausrichten oder ein Fälschungsversuch. In beiden Fällen zählt es, das so schnell wie möglich zu erfahren. Das zweite: Eine bekannte Quelle, die zu scheitern beginnt — ein DKIM-Schlüssel, der abgelaufen ist, ein SPF-Eintrag, der sich geändert hat, und schon fällt eine bislang saubere Quelle.

Ein Tool ohne Alarm verurteilt dazu, Probleme zufällig zu entdecken, oder schlimmer, wenn ein Kunde sich beschwert, eine E-Mail nie erhalten zu haben. Ein Tool, das alarmiert, verhält sich wie ein gutes Alarmsystem: still, wenn alles in Ordnung ist, hörbar, wenn etwas nicht stimmt. Zu prüfen ist also, bei welchen Ereignissen das Tool alarmieren kann und über welchen Kanal (E-Mail, Webhook, Integration).

Dieses Kriterium gewinnt mit der Größe der Flotte an Bedeutung. Eine sehr stabile Einzeldomain kann ohne Alarme leben; bei mehreren Domains ist der Alarm der einzige realistische Weg, einen Vorfall auf einer Sekundärdomain nicht zu verpassen.

Kriterium 6 — Multi-Domain- und Subdomain-Abdeckung

Wer nur eine einzige Domain ohne aktive Subdomains verwaltet, kann dieses Kriterium überspringen. Sonst ist es entscheidend. Zwei Dimensionen verbergen sich dahinter. Erstens Multi-Domain: Lassen sich alle Domains (Tochtergesellschaften, Marken, geparkte Domains) aus einer konsolidierten Ansicht überwachen, oder braucht es so viele Oberflächen wie Domains? Ein Vorfall auf einer Sekundärdomain bleibt unbemerkt, wenn jede Domain in ihrem eigenen Silo isoliert ist. Zweitens Subdomains: DMARC regelt die Subdomain-Policy über die Tags sp (existierende Subdomains) und np (nicht existierende Subdomains). Ein Angreifer, der beispiel.de nicht mehr fälschen kann, wird mail.beispiel.de versuchen. Ein guter Analyzer zeigt den Verkehr pro Subdomain und hilft, sp und np einzustellen, nicht nur die Root-Policy.

Für einen Dienstleister oder eine große Organisation ist das oft das Auswahlkriterium Nummer eins. Für einen Einzelunternehmer mit einer einzigen Domain ist es Überfluss. Ehrlichkeit zur eigenen Situation kommt vor der Zahlung für eine Abdeckung, die am Ende niemand nutzt.

Kriterium 7 — Umgang mit forensischen (RUF) Berichten unter Wahrung der Privatsphäre

Forensische (RUF) Berichte sind ein anderes Tier als aggregierte (RUA). Wo RUA nur IPs und Statistiken enthält, kann RUF echte Nachrichten-Header transportieren — und damit potenziell personenbezogene Daten. Nicht alle Tools verarbeiten sie, und unter denen, die es tun, machen es nicht alle sauber. Ein guter Analyzer muss, wenn er RUF verarbeitet, dies mit Schutzvorkehrungen tun: Schwärzung sensibler Daten, kurze und konfigurierbare Aufbewahrung, kontrolliertes Hosting. Ein Tool, das rohe forensische Berichte aufsaugt und sie unbegrenzt auf einer undurchsichtigen Cloud speichert, schafft ein Compliance-Problem, das vorher nicht bestand.

Zu beachten: Viele Ökosysteme reduzieren heute den Einsatz von RUF, und es ist völlig vertretbar, es deaktiviert zu lassen. Der Wachsamkeitspunkt beim Kauf ist: Wenn das Tool RUF anbietet, wie schützt es diese Daten? Dieses Kriterium wiegt vor allem für Organisationen unter starken Vertraulichkeitsanforderungen (öffentlicher Sektor, Gesundheit, Finanzen). Für einen einfachen Anwendungsfall reicht RUA reichlich.

Kriterium 8 — Datenaufbewahrung und Export

Zwei Fragen an jeden Kandidaten. Wie lange bewahrt das Tool die Historie auf? Und lassen sich die Daten jederzeit exportieren? Die Aufbewahrung bestimmt die Fähigkeit, langsame Abweichungen zu erkennen: Eine Quelle, die sich über drei Monate verschlechtert, ist in sieben Tagen Historie nicht zu sehen. Viele kostenlose Angebote begrenzen auf 7 oder 30 Tage; für echtes Monitoring ist ein Ziel von 90 bis 180 Tagen gesünder. Der Export ist die Anti-Lock-in-Versicherung: Wer das Tool wechseln, die Daten ins eigene SIEM einspeisen oder einfach ein Archiv behalten will, muss die Berichte herausholen können. Ein Tool, das die Daten einsperrt, macht seine Nutzer zu Gefangenen.

Dieses Kriterium zählt für alle, aber die Latte steigt mit den Compliance-Anforderungen. Ist einem Prüfer die Haltung über die Zeit nachzuweisen, wird kurze Aufbewahrung zu einem echten Handicap.

Kriterium 9 — Signalisierung der BIMI-Bereitschaft

Letztes Kriterium, eher vorausschauend. Gehört das Logo in den Posteingängen (BIMI) zu den Zielen, nennt das ideale Tool den Stand auf diesem Weg. BIMI erfordert eine durchsetzende Policy (quarantine oder reject, oft reject) plus, für das verifizierte Abzeichen, ein Zertifikat. Ein Analyzer, der „reject ist erreicht, der BIMI-Schritt ist frei" oder „dies fehlt noch" meldet, verwandelt ein Marketing-Ziel in eine konkrete Checkliste. Es ist kein Ausschlusskriterium, aber ein schönes Reifezeichen: Ein Tool, das an BIMI denkt, ist ein Tool, das über bloßes Parsen hinausdenkt.

Dieses Kriterium spricht vor allem Marken an, für die die Sichtbarkeit im Posteingang einen Geschäftswert hat. Für alle anderen ist es ein Bonus, keine Notwendigkeit.

Ein konkretes Beispiel: zwei Analyzer, eine Domain

Nichts geht über einen Vergleich. Nehmen wir eine reale Domain: ein KMU, das von seinem Microsoft-365-Tenant und von einer E-Mail-Plattform für seine Kampagnen sendet. Zwei Quellen, ein Ziel: auf reject gehen, ohne die Kampagnen zu zerstören.

Der erste Analyzer empfängt die Berichte, parst sie und zeigt ein gut präsentiertes Dashboard: „1.240 Nachrichten analysiert, 78 % DMARC-Konformität", mit einem Kreisdiagramm und der Liste der sendenden IPs. Es ist sauber. Es ist lesbar. Und es bringt nirgendwohin: Sichtbar ist, dass es 22 % Fehlschläge gibt, aber unbekannt bleibt, woher sie genau kommen, warum es sie gibt und wie sie sich beheben lassen. Rohes XML wurde gegen hübsches XML getauscht. Die Interpretationsarbeit bleibt vollständig auf den Schultern des Anwenders liegen.

Der zweite Analyzer betrachtet dieselben Berichte und meldet in Klartext: „Die Marketing-Plattform und der M365-Tenant senden beide ohne Ausrichtung. Für M365: SPF besteht, aber DKIM ist nicht aktiviert — die DKIM-Signierung im Admin-Center einschalten. Für die Marketing-Plattform: Sie signiert mit DKIM unter ihrer eigenen Domain — diesen CNAME-Eintrag in die eigene DNS-Zone aufnehmen, um ihre Signatur mit der Domain des Absenders auszurichten. Sobald beide Korrekturen in Kraft sind, liegt die Ausrichtung bei ~99 % und die Verschärfung auf reject ist gefahrlos." Da ist der Unterschied. Der erste zeigt ein Problem; der zweite reicht die Lösung, in Reihenfolge, mit dem exakten zu veröffentlichenden DNS-Eintrag.

Welchen wählen? Die Antwort ist offensichtlich, sobald man es so formuliert. Der zweite spart Stunden der Recherche und, vor allem, er bringt voran Richtung reject. Der erste lässt am Startpunkt zurück, mit hübscheren Farben. Genau das deckt Kriterium 4 ab: Visualisierung ist keine Behebung. Um zu vertiefen, wie man mehrere Kandidaten vergleicht, entfaltet wie man ein DMARC-Tool wählt eine vollständige Methode, und DMARC-Tool kostenlos oder kostenpflichtig klärt, wann das kostenlose reicht und wann es an die Kasse geht.

Warnsignale bei der Bewertung eines Tools

Bestimmte Anzeichen sollten zum Rückzug führen. In loser Reihenfolge die wichtigsten roten Flaggen:

  • Das Tool zeigt IPs, benennt sie aber nie. Bleibt der Besitzer von 40.107.22.15 Ratearbeit, liegt der schwerste Teil weiter beim Anwender. Kriterium 1 nicht erfüllt, weiter.
  • Kein SPF/DKIM-Detail pro Quelle. Eine globale Konformitätszahl ohne Aufschlüsselung ist hübsch, aber nicht umsetzbar. Was zu beheben ist, bleibt unbekannt.
  • Keine Historie, nur der gegenwärtige Moment. Ohne Trend fällt die Policy-Entscheidung auf einer Momentaufnahme — und zerstört eine monatliche Quelle, die nie sichtbar war.
  • Null Alarme. Warnt das Tool vor nichts, kommen Vorfälle über eine Kundenbeschwerde ans Licht. Ein vergessenes Dashboard ist nutzlos.
  • Undurchsichtige Aufbewahrung oder unmöglicher Export. Bleibt unklar, wie lange die Daten bleiben und wie sie sich abrufen lassen, ist die Unterschrift eine für den Lock-in.
  • RUF ohne Schutzvorkehrungen gespeichert. Ein Tool, das rohe forensische Berichte aufsaugt und sie unbegrenzt auf einer diffusen Cloud behält, fabriziert ein Datenschutzrisiko.
  • Nur generischer Rat. „Einen DMARC-Eintrag veröffentlichen", ohne die realen Quellen anzusehen, ist ein Blogartikel, als Produkt verkleidet. Rat muss in echten Daten verankert sein.
  • Unmöglich ohne Kreditkarte zu testen. Ein guter Analyzer zeigt die eigenen Quellen, bevor er zur Zahlung auffordert. Eine Bindung im Blindflug verdient Misstrauen.

Kein Tool kreuzt jedes Kästchen perfekt an, aber zwei oder drei dieser roten Flaggen zusammen, und es ist ein Spielzeug, kein Arbeitswerkzeug.

In einem Satz

Ein echter DMARC-Analyzer identifiziert die Quellen, schlüsselt ihre Ausrichtung auf, bewahrt die Historie und nennt, was zu beheben ist — nicht nur, wie das Problem aussieht. Die Wahl folgt der eigenen Realität: eine einzelne stabile Domain kommt mit dem Wesentlichen aus, eine Multi-Domain-Flotte verlangt Alarme und breite Abdeckung. Und „kostenpflichtig" heißt nicht „besser": Das richtige Tool ist das, das zum Kontext passt, kostenlos inbegriffen. Für aggregierte Daten im Web-Maßstab gibt das DMARC-Observatorium einen Eindruck von Haltungstrends über die eigene Domain hinaus.

Der schnellste Weg, sich eine Meinung zu bilden: eine Eingabe der Domain in den kostenlosen DMARC-Analyzer und ein Blick darauf, was ein Tool wirklich über die eigenen Quellen zeigt. Innerhalb von Sekunden steht fest, ob Identifikation, Detail pro Quelle und Rat da sind — die Checkliste dieses Leitfadens liefert den Maßstab. Ergibt sich daraus ein klarer Aktionsplan Richtung p=reject, ist es die richtige Art von Tool. Für die endgültige Ausrichtung der Quellen: ein Konto anlegen und Thomas bis reject führen lassen.

Verwandte Leitfäden

Über den Autor

ThomasThomas ist der virtuelle CISO von DMARC.com: ein auf E-Mail-Authentifizierung spezialisierter Copilot, der Organisationen von p=none bis p=reject begleitet, ohne ihren Mailverkehr zu stören. Seine Leitfäden stützen sich auf echte Daten aus dem DMARC-Observatorium und aus den von der Plattform analysierten RUA-Berichten.