Kostenloses Tool

Kostenloser DMARC-Report-Analyzer für aggregierte XML-Berichte, direkt im Browser.

Name: DMARC-Report-Analyzer
Author: DMARCTrust

Legen Sie einen aggregierten Bericht ab, und dieser DMARC-Analyzer macht aus dem rohen XML eine lesbare Zusammenfassung: Quell-IPs, SPF- und DKIM-Ergebnisse, Alignment und die Aktion, die jeder Empfänger gewählt hat. Er nutzt denselben Open-Source-Analyzer, mit dem wir echte Berichte für unsere eigenen Kunden auswerten. Ihr Bericht verlässt Ihren Browser nicht.

DMARC-Bericht hier ablegen

oder klicken, um eine Datei auszuwählen

Bericht auswerten

Unterstützt .xml-, .xml.gz- und .zip-Dateien

Bereit zur Auswertung

Auswertung

Nachrichten gesamt

DMARC-Erfolgsquote

SPF

Bestanden Nicht bestanden

DKIM

Bestanden Nicht bestanden

Disposition der Nachrichten

None (zugestellt)

Quarantine

Reject

Berichtsdetails

Bericht von
Berichtszeitraum
Gemeldete Domain

Ihre DMARC-Richtlinie

Richtlinie (p)
Subdomain-Richtlinie (sp)
Richtlinie für nicht existierende Subdomains (np)
Prozentsatz (pct)
Testmodus (t)
Erkennungsmethode
DKIM-Alignment
SPF-Alignment

Wichtigste Absenderquellen

Quell-IP	Nachrichten	Bestanden	Nicht bestanden	Auth-Methoden

Was ist ein aggregierter DMARC-Bericht?

Ein aggregierter DMARC-Bericht, auch rua-Bericht genannt, ist eine XML-Datei, die Ihnen ein E-Mail-Anbieter wie Gmail, Microsoft oder Yahoo etwa einmal pro Tag für jede Ihrer Domains zusendet. Er fasst die Nachrichten zusammen, die an diesem Tag vorgaben, von Ihrer Domain zu stammen: welche IP-Adressen sie versendet haben, ob SPF und DKIM bestanden und ausgerichtet waren und was der Empfänger mit E-Mails getan hat, die nicht bestanden haben. Das Format entstand in Anhang C von RFC 7489. RFC 9989 (DMARCbis) löst RFC 7489 nun als zentralen Standard ab, und RFC 9990 legt das Schema des aggregierten Berichts fest: pct ist aus dem Eintrag verschwunden, und die Elemente np, testing und discovery_method kamen hinzu.

Es gibt zwei Arten von DMARC-Berichten, und dieser Analyzer liest eine davon. Aggregierte Berichte (rua) sind die oben beschriebenen täglichen statistischen XML-Zusammenfassungen. Sie tragen Zählwerte, nicht den Nachrichteninhalt. Fehlerberichte (ruf), früher forensische Berichte genannt und nun in RFC 9991 spezifiziert, sind ein separates Format pro Nachricht, das in dem Moment gesendet wird, in dem eine Nachricht durchfällt. Dieses Tool wertet aggregierte Berichte aus, was nahezu jeder Empfänger sendet und was Sie brauchen, um zu sehen, wie Ihre Domain genutzt wird.

DMARCbis, veröffentlicht im Mai 2026, hat diesen Stapel über RFC 9989, 9990 und 9991 überarbeitet. Unser DMARCbis-Überblick erklärt, was sich geändert hat.

So lesen Sie einen DMARC-Bericht, Feld für Feld

Jeder aggregierte Bericht ist ein <feedback>-Element mit drei Teilen: wer den Bericht gesendet hat, die von Ihnen veröffentlichte Richtlinie und ein Eintrag pro Gruppe von Nachrichten mit demselben Ergebnis. Hier steht, was jedes Feld bedeutet, in der Reihenfolge, in der der Analyzer oben sie liest.

<report_metadata>, wer diesen Bericht wann gesendet hat

org_name: Der Empfänger, der den Bericht erstellt hat, zum Beispiel google.com.
email: Das meldende Postfach bei diesem Empfänger.
report_id: Eine eindeutige ID für diesen Bericht. Nutzen Sie sie zum Deduplizieren, falls Sie Berichte selbst speichern.
date_range / begin, end: Das 24-Stunden-Fenster, das der Bericht abdeckt, in Unix-Epoch-Sekunden. Der Analyzer wandelt diese für Sie in lesbare Daten um.

<policy_published>, die DMARC-Richtlinie, die an diesem Tag aktiv war

domain: Die Domain, für die die Richtlinie gilt.
p: Ihre Hauptrichtlinie: none, quarantine oder reject. Das ist die Einschätzung, die Sie für E-Mails veröffentlicht haben, die die DMARC-Prüfung nicht bestehen.
sp: Die Richtlinie für Subdomains, falls Sie eine festgelegt haben.
np: Die Richtlinie für nicht existierende Subdomains. RFC 9989 (DMARCbis) hat das np-Tag zum Eintrag hinzugefügt, und RFC 9990 trägt seinen Wert als Berichtselement. Der Analyzer zeigt es nur, wenn es vorhanden ist.
pct: Der Prozentsatz der durchgefallenen E-Mails, auf den die Richtlinie angewendet wird. RFC 9989 hat pct zugunsten des t-Flags (Testmodus) aus dem DMARC-Eintrag entfernt, daher zeigt der Analyzer pct nur, wenn ein älterer Bericht es noch trägt, und erfindet nie einen Standardwert.
adkim / aspf: DKIM- und SPF-Alignment-Modus: r ist relaxed (die organisatorischen Domains müssen übereinstimmen), s ist strict (die vollständigen Domains müssen übereinstimmen).
testing: Das Berichtselement, das den Wert des t-Flags (Testmodus) aus RFC 9989 trägt. Bei yes wertet der Empfänger DMARC aus, setzt es aber nicht durch, sodass Sie beobachten können, bevor Sie die Richtlinie aktivieren. Während des Tests fließen die Berichte weiter.
discovery_method: Ein Berichtsfeld aus RFC 9990, das angibt, wie der Empfänger Ihre Richtlinie gefunden hat: psl (Public Suffix List) oder treewalk (der neue DNS Tree Walk).

<record>, eine Zeile pro Gruppe von Nachrichten mit demselben Ergebnis

Jeder Eintrag hat vier Kindblöcke. Die ersten beiden tragen das Ergebnis; die letzten beiden tragen die Belege.

row / source_ip, count: Die IP-Adresse, die die E-Mails versendet hat, und wie viele Nachrichten sie in dieser Gruppe versendet hat. count ist die Zahl, mit der Sie alles andere multiplizieren.
policy_evaluated / disposition: Was der Empfänger tatsächlich getan hat: none bedeutet zugestellt, quarantine bedeutet als Spam markiert, reject bedeutet abgewiesen.
policy_evaluated / dkim, spf: Das DMARC-Ergebnis, das der Empfänger für jeden Mechanismus bereits berechnet hat, pass oder fail, nach dem Alignment. Dieses Ergebnis entscheidet, ob DMARC bestanden wurde.
identifiers / header_from: Die Domain im sichtbaren From-Header, die Adresse, die DMARC schützt.
auth_results / dkim, spf: Die rohe SPF- und DKIM-Prüfung (Domain, Selektor, Ergebnis) vor dem Alignment. Hier untersuchen Sie, warum ein Ergebnis so ausgefallen ist. Unter RFC 9990 ist der DKIM-Selektor erforderlich, sobald eine DKIM-Signatur gemeldet wird.

Die Bedeutung jedes Tags in der von Ihnen veröffentlichten Richtlinie (die Werte p, sp, adkim, aspf oben) finden Sie in unserem Leitfaden zu DMARC-Tags, oder erstellen Sie einen Eintrag mit dem DMARC-Eintragsgenerator.

Praxisbeispiel: ein echter Bericht, dekodiert

Hier ist ein gesunder Bericht Zeile für Zeile gelesen. Es ist ein synthetisches Beispiel (die IPs und die Report-ID sind nicht echt), aber es hat genau die Form, die Google sendet. Legen Sie es in den Analyzer oben, und Sie erhalten die Zusammenfassung darunter.

Ein gekürzter Beispielbericht (einer von zwei Einträgen gezeigt):

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>14987236590123456789</report_id>
    <date_range><begin>1717200000</begin><end>1717286400</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>reject</p><sp>reject</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.41</source_ip>
      <count>128</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
  </record>
</feedback>

In Klartext gelesen

google.com hat diesen Bericht für example.com gesendet, er deckt einen Tag ab.
Die veröffentlichte Richtlinie ist p=reject mit relaxed-Alignment (adkim=r, aspf=r).
Eintrag eins: 198.51.100.41 hat 128 Nachrichten gesendet. DKIM und SPF haben beide bestanden und waren ausgerichtet, also hat DMARC bestanden.
Eintrag zwei (oben nicht gezeigt): 198.51.100.12 hat 47 Nachrichten gesendet, ebenfalls alle bestanden.
Gesamt: 128 + 47 = 175 Nachrichten, eine DMARC-Erfolgsquote von 100 %.

Beachten Sie, dass jede Disposition none ist, obwohl die Richtlinie p=reject lautet. Das ist korrekt, kein Widerspruch. p=reject ist die Einschätzung, die ein Empfänger auf E-Mails anwendet, die DMARC nicht bestehen. Hier hat jede Nachricht bestanden, also hatte der Empfänger keinen Grund einzugreifen und hat sie normal zugestellt.

Ein Spoofing-Versuch (das Fälschen der Absenderadresse) sieht anders aus. Sie würden eine unbekannte source_ip mit dkim=fail und spf=fail in policy_evaluated sehen, und weil die Richtlinie reject lautet, würde ihre Disposition typischerweise reject anzeigen. Diese Zeile ist E-Mail, die jemand im Namen Ihrer Domain versendet hat und die der Empfänger abgewiesen hat. Das sind die Zeilen, die es zu beobachten lohnt.

policy_evaluated vs. auth_results, der Teil, den die meisten Tools falsch machen

Ein Bericht trägt das SPF- und DKIM-Ergebnis zweimal, und die beiden sind nicht dasselbe. In auth_results steht die rohe Prüfung: hat SPF die sendende IP autorisiert, hat sich die DKIM-Signatur verifiziert. In policy_evaluated steht das DMARC-Ergebnis: der Empfänger hat dieses rohe Ergebnis genommen und zusätzlich geprüft, ob die authentifizierte Domain mit der Domain im sichtbaren From-Header übereinstimmt (Alignment). DMARC besteht, wenn SPF oder DKIM besteht und mit dieser From-Domain ausgerichtet ist.

Deshalb kann ein rohes SPF pass anzeigen, während DMARC trotzdem fehlschlägt. Eine Nachricht, die über einen Weiterleiter oder einen nicht konfigurierten Massenversand-Anbieter läuft, kann einfaches SPF auf der eigenen Domain des Anbieters bestehen, aber DMARC nicht bestehen, weil diese Domain nicht mit Ihrer übereinstimmt. Das ausgerichtete Ergebnis in policy_evaluated entscheidet die Behandlung, also ist es die Zahl, die dieser Analyzer zählt.

Wir sind genau, was das Tool tut: Es meldet das ausgerichtete Ergebnis, das der Empfänger bereits in policy_evaluated berechnet hat. Es führt das Alignment nicht erneut auf Ihren rohen Ergebnissen aus. Das entspricht RFC 7489 Abschnitt 7.2 (übernommen in RFC 9989), wo der Empfänger das Identifier-Alignment auswertet, nicht der Berichtsleser.

Warum einen DMARC-Report-Analyzer verwenden?

E-Mail-Quellen verifizieren

Sehen Sie, welche IP-Adressen im Namen Ihrer Domain E-Mails versenden und ob sie dazu berechtigt sind.

SPF und DKIM im Blick behalten

Verfolgen Sie die Erfolgsquoten, damit Ihre echten E-Mails authentifiziert bleiben, während Sie auf p=reject zugehen.

Spoofing erkennen

Finden Sie unbekannte Absender, die versuchen, im Namen Ihrer Domain zu versenden, und bestätigen Sie, dass Ihre Richtlinie ihre Aufgabe erfüllt.

100 % in Ihrem Browser, nichts wird hochgeladen

Ihr Bericht verlässt Ihren Rechner nicht. Der Analyzer liest die Datei mit dem im Browser integrierten DOMParser und entpackt .gz- und .zip-Archive im Arbeitsspeicher mit fflate. Kein Upload, kein Server-Roundtrip, keine Protokollierung. Der Analyzer macht keinerlei Netzwerkaufrufe, was Sie selbst überprüfen können: Er ist Open Source unter der MIT-Lizenz. Das ist der Unterschied zwischen diesem Tool und Analyzern, die Sie zuerst bitten, einen Bericht auf ihre Server hochzuladen.

DMARC-Monitoring lieber automatisch?

Einen Bericht von Hand zu lesen, ist in Ordnung. Täglich treffen neue Berichte von jedem Empfänger ein, und das skaliert nicht. DMARCTrust sammelt, wertet aus und verfolgt sie automatisch für Sie, mit genau diesem Analyzer serverseitig.

Kostenloses Monitoring starten DMARC-Eintrag erstellen SPF-Eintrag erstellen

Open Source und selbst hostbar

Die Engine hinter diesem Analyzer ist Open Source unter der MIT-Lizenz und derselbe Analyzer, der echte Berichte für unsere Kunden liest. Sie läuft vollständig in Ihrem Browser, Ihre Berichte verlassen also nie Ihren Rechner. Sehen Sie sich den Code an, betreiben Sie ihn auf Ihrer eigenen Infrastruktur oder reichen Sie einen Pull Request ein.

Auf GitHub ansehen

Häufig gestellte Fragen

Sind meine DMARC-Berichtsdaten sicher?

Ja. Der Analyzer läuft vollständig in Ihrem Browser. Ihr Bericht wird lokal mit dem integrierten DOMParser gelesen und niemals hochgeladen, protokolliert oder an einen Server übertragen.

Welche Dateiformate kann ich auswerten?

Unkomprimiertes .xml, gzip-komprimierte .xml.gz oder .gz und .zip-Archive. In einem .zip wird die erste XML-Datei verwendet. Das Limit liegt bei 10 MB, weit mehr als jeder reale aggregierte Bericht.

Was enthält ein aggregierter DMARC-Bericht?

Eine tägliche Zusammenfassung der E-Mails, die im Namen Ihrer Domain versendet wurden: den meldenden Empfänger und den Zeitraum, die von Ihnen veröffentlichte Richtlinie und einen Eintrag pro Gruppe von Nachrichten mit demselben Ergebnis, jeweils mit Quell-IP, Nachrichtenanzahl, SPF- und DKIM-Ergebnis und der vom Empfänger angewendeten Disposition.

Wie öffne ich einen .gz- oder .zip-DMARC-Bericht?

Legen Sie die Datei direkt so auf den Analyzer, wie sie in Ihrem Postfach angekommen ist. Er entpackt .gz und .zip automatisch in Ihrem Browser, Sie müssen die Datei also nicht vorab entpacken.

Warum ist die Disposition none, obwohl meine Richtlinie reject ist?

Weil p=reject die Einschätzung ist, die ein Empfänger nur auf E-Mails anwendet, die die DMARC-Prüfung nicht bestehen. Eine Nachricht, die SPF oder DKIM bestanden hat und ausgerichtet ist, besteht DMARC, also stellt der Empfänger sie zu und vermerkt die Disposition als none. reject sehen Sie nur in Zeilen, die tatsächlich durchgefallen sind.

Was ist der Unterschied zwischen aggregierten Berichten und Fehlerberichten?

Aggregierte Berichte (rua) sind tägliche statistische XML-Zusammenfassungen mit Zählwerten, nicht mit Nachrichteninhalten. Fehlerberichte (ruf), früher forensische Berichte genannt und nun in RFC 9991 spezifiziert, sind ein separates Format pro Nachricht. Dieser Analyzer liest aggregierte Berichte, was nahezu jeder Empfänger sendet.

Warum besteht SPF in auth_results, DMARC schlägt aber trotzdem fehl?

auth_results enthält die rohe SPF-Prüfung, die auf der eigenen Domain eines E-Mail-Anbieters bestehen kann. DMARC verlangt zusätzlich Alignment mit der Domain in Ihrem From-Header. Wenn die bestehende Domain nicht mit Ihrer übereinstimmt, schlägt DMARC fehl. Das ausgerichtete Ergebnis in policy_evaluated ist das, was zählt.

Wie oft senden Empfänger DMARC-Berichte?

Typischerweise einmal pro Tag und Domain je Empfänger, zum Beispiel ein täglicher Bericht von Google und einer von Microsoft. DMARCbis (RFC 9989 §8) empfiehlt nun ein tägliches Intervall und hat das ältere ri-Tag gestrichen, auch wenn ein Empfänger häufiger oder seltener berichten kann. Da täglich Berichte von jedem Empfänger eintreffen, skaliert das Lesen von Hand schnell nicht mehr, und genau das löst automatisiertes Monitoring.

Schützen Sie Ihre E-Mail-Reputation

DMARC-Monitoring muss nicht kompliziert sein. Wir kümmern uns um die technischen Details, Sie konzentrieren sich auf Ihr Geschäft.

Monitoring starten Preise ansehen