Einen DMARC-RUA-Bericht lesen (und was er verrät)

Von Thomas · virtueller CISO · 2026-07-15

Ein DMARC-RUA-Bericht landet als .xml.gz- oder .xml.zip-Datei im Anhang im Postfach. Darin steckt XML, das auf den ersten Blick aussieht wie eine Flughafen-Anzeigetafel — viele Tags, wenig Erklärung. Doch sobald klar ist, wohin zu schauen ist, erzählt ein RUA-Bericht eine sehr klare Geschichte: Wer hat im Namen der Domain Mail verschickt, von wo aus, mit welchem Ergebnis. Dieser Leitfaden entschlüsselt die Struktur und benennt die Tags, die zuerst anzuschauen sind.

Die grobe Struktur

Ein RUA-Bericht folgt einem standardisierten XML-Schema. So sieht sein Gerüst aus:

<?xml version="1.0" ?>
<feedback>
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>3456789012345678901</report_id>
    <date_range>
      <begin>1719273600</begin>
      <end>1719359999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>beispiel.de</domain>
    <p>reject</p>
    <sp>reject</sp>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>40.107.1.25</source_ip>
      <count>347</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>beispiel.de</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>beispiel.de</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>beispiel.de</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

In der Realität enthält dieses Gerüst mehrere <record>-Blöcke, einen pro beobachteter Kombination aus Quell-IP und Authentifizierungsergebnissen.

Die wichtigen Tags, die zu lesen sind

`report_metadata`

org_name: Wer den Bericht schickt. Google, Microsoft, Yahoo — das ist der Provider, der die Nachrichten empfangen und bewertet hat.
date_range: Der abgedeckte Zeitraum (Unix-Timestamps). Umgerechnet zeigen sie, von welchem Tag der Bericht spricht.
report_id: Eindeutige Kennung des Berichts, nützlich als Referenz beim Nachhaken gegenüber dem Provider.

`policy_published`

Das, was der Provider zum Zeitpunkt des Berichts als Policy der Domain gesehen hat. Zu prüfen ist, ob <p> dem entspricht, was durchgesetzt werden soll. Steht da none, obwohl quarantine gesetzt sein sollte, ist der DNS-Eintrag vielleicht noch nicht propagiert oder falsch veröffentlicht.

`<record>` — das Herzstück des Berichts

Jeder <record> steht für eine Gruppe identischer Nachrichten (gleiche IP, gleiche Ergebnisse). Hier spielt sich alles ab:

source_ip: Die IP, die die Nachrichten verschickt hat. Das ist die erste Frage: Ist das eine wiedererkennbare IP? Ein eigener Server, eine bekannte Versandplattform?
count: Wie viele Nachrichten in diesem Block zusammengefasst sind. Ein count von 347 auf einer bekannten IP ist normal. Ein count von 12 auf einer unbekannten IP verdient eine Untersuchung.
policy_evaluated → disposition: Was der Empfänger mit der Nachricht tatsächlich gemacht hat (none, quarantine, reject). Ein disposition=none bei p=reject kann bedeuten, dass der Provider ein lokales Override hat oder dass die Nachricht wegen einer Vertrauensvereinbarung trotzdem durchkommt.
policy_evaluated → dkim und spf: Das DKIM- und SPF-Ergebnis nach dem Alignment. Das ist es, was für DMARC zählt — nicht die Rohergebnisse in auth_results.
header_from: Die Domain aus dem From: der E-Mail. Sie muss immer die geschützte Domain sein.

`auth_results`

Die SPF- und DKIM-Rohergebnisse, vor der Alignment-Bewertung. Nützlich für die Diagnose:

Wenn auth_results/dkim/result=pass, aber policy_evaluated/dkim=fail, ist die DKIM-Signatur gültig, aber nicht ausgerichtet — die domain in auth_results/dkim unterscheidet sich vom header_from. Das ist der Klassiker: eine Plattform, die mit ihrer eigenen Domain signiert.
Wenn auth_results/spf/result=pass, aber policy_evaluated/spf=fail, dieselbe Logik: SPF besteht für den Envelope, aber der Envelope ist nicht die geschützte Domain.

Einen Bericht in der Praxis lesen: der Leseablauf

Wenn ein Bericht eintrifft, empfiehlt sich diese Lesereihenfolge:

org_name — wer ihn schickt (Gmail, Outlook, Yahoo …).
date_range — aus welchem Zeitraum (gestern? vorgestern?).
policy_published/p — ist meine Policy korrekt sichtbar?
Für jeden <record>:
- source_ip: Erkenne ich diese IP?
- count: Wie viele Nachrichten?
- policy_evaluated/dkim und spf: Besteht es oder scheitert es?
- Wenn es scheitert: warum? Die Details stehen in auth_results.

Mit diesem Ablauf ist in wenigen Minuten klar, ob die legitimen Quellen durchkommen und ob verdächtige IPs im Namen der Domain versenden.

Warum ein Analyse-Tool den Unterschied macht

Ein einzelner Gmail-Bericht enthält manchmal Dutzende <record>-Blöcke. Multipliziert mit den Berichten von Microsoft, Yahoo, Apple und den anderen wird das manuelle Lesen schnell zermürbend. DMARC-Analyse-Tools aggregieren diese Berichte, reichern sie mit der Identität der IPs an (Hoster, bekannte Plattformen) und präsentieren eine konsolidierte Sicht. Unser Analyzer macht genau das: Er liest die Berichte, identifiziert die Quellen und zeigt den Zustand jeder einzelnen — ohne dass eine einzige XML-Datei geöffnet werden muss.

Häufige Fragen

Meine Berichte kommen als .gz oder .zip. Wie öffne ich sie? Das Entpacken der Datei (gunzip auf Mac/Linux, 7-Zip oder WinRAR auf Windows) legt das .xml frei, das sich dann in einem Texteditor oder Browser öffnen lässt. Besser: ein Analyse-Tool nutzen, das das automatisch erledigt.

Warum bekomme ich mehrere Berichte pro Tag? Nein, in der Regel einen pro Absender pro Tag (standardmäßig ein 24-Stunden-Zeitraum). Treffen mehrere vom selben Akteur ein, kann es eine Aufteilung geben, wenn das Volumen sehr hoch ist.

Ich sehe disposition=quarantine, aber meine Policy ist p=reject. Warum? Das policy_evaluated/disposition spiegelt wider, was der Provider tatsächlich angewandt hat, nicht die deklarierte Policy. Manche Akteure haben Overrides (Whitelists, bilaterale Vereinbarungen), die die Durchsetzung abmildern. Das ist kein Fehler auf Absenderseite.

Ich bekomme gar keine Berichte. Was ist los? Zu prüfen ist, ob der DMARC-Eintrag korrekt veröffentlicht ist und rua=mailto:adresse@beispiel.de enthält. Ebenso, ob die Empfangsadresse erreichbar ist und die E-Mails nicht im Spam landen. Liegt die rua=-Adresse auf einer externen Domain, muss diese externe Domain einen _dmarc-Autorisierungseintrag besitzen.

Erzeugt jede E-Mail, die ich sende, einen Bericht? Nein. Berichte werden aggregiert: ein Block pro Kombination aus IP und Ergebnissen über den Zeitraum. 1000 E-Mails von derselben IP mit denselben Ergebnissen = 1 <record> mit count=1000.

Was tun, wenn ich eine IP sehe, die ich nicht erkenne? Der erste Schritt ist, sie per Reverse-DNS aufzulösen (nslookup IP oder dig -x IP) und zu schauen, zu welchem Dienst sie gehört. Ist es ein bekannter Cloud-Hoster, ist es vielleicht eine alte VM oder ein vergessener Dienst. Ist es ein unbekannter Bereich ohne klaren Reverse-DNS, ist das ein Warnsignal — vielleicht Fälschung. In jedem Fall gilt: nicht als „legitim" markieren, ohne die Quelle mit Sicherheit identifiziert zu haben.

Enthalten die Berichte auch die von meinem eigenen Spamfilter abgewiesenen Nachrichten? Nein. RUA-Berichte betreffen die Nachrichten, die den Empfangsserver erreicht haben und von DMARC bewertet wurden. Vor der DMARC-Bewertung abgewiesene Nachrichten (blockierte TCP-Verbindung, SMTP-Ablehnung) erscheinen dort nicht.

Spiegeln die Berichte alle meine E-Mails wider oder nur einige? Nur die Nachrichten, die bei Empfängern ankommen, deren Provider DMARC-Berichte verschickt. Geht Post an eine Domain, die kein Reporting implementiert hat, erscheinen diese Nachrichten nicht — selbst bei aktiver Policy. Deshalb sind die Daten der großen Provider (Gmail, Outlook, Yahoo) am aussagekräftigsten: Sie decken den Großteil des weltweiten Traffics ab.

Was ein Bericht über die tatsächliche Aufstellung verrät

Ein RUA-Bericht ist nicht nur eine Ergebnisliste — er ist eine Momentaufnahme der Authentifizierungs-Aufstellung. Wer jeden <record>-Block aufmerksam liest, rekonstruiert ein präzises Bild der Lage: welche Quellen funktionieren, welche kaputt sind und welche noch gar nicht identifiziert waren. Gerade der letzte Punkt ist oft der aufschlussreichste: DMARC-Berichte entdecken regelmäßig Versandquellen, die Organisationen vergessen hatten — eine alte Anwendung, ein Dienstleister, dessen Service man nicht mehr nutzt, dessen DNS-Konfiguration aber nie bereinigt wurde, ein SaaS-Tool, das unbemerkt Benachrichtigungen im Namen der Domain verschickt.

Um das Maximum aus einem Bericht herauszuholen, lohnt der Blick über das Lesen Quelle für Quelle hinaus, hin zu Mustern: Konzentrieren sich die Fehlschläge auf ein paar IPs oder sind sie verstreut? Scheitern dieselben IPs in den Berichten mehrerer Provider oder nur bei einem? Nimmt das Fehlervolumen mit der Zeit zu? Diese Fragen verwandeln eine punktuelle Diagnose in ein systemisches Verständnis der Aufstellung.

Die Alarmsignale, auf die zu achten ist

Einige Konstellationen in einem Bericht sollten sofort Aufmerksamkeit erregen. Ein hoher count auf einer unbekannten IP: Jemand versendet viele Nachrichten im Namen der Domain, von einer IP aus, die niemand wiedererkennt. Steht die Policy auf p=none, kommen diese Nachrichten an ihr Ziel — mit dem Image der Domain. Plötzliche Fehlschläge auf einer wiedererkannten IP: Irgendwo hat sich eine Konfiguration geändert (schlecht ausgeführte DKIM-Schlüsselrotation, Änderung der SPF-Konfiguration, Providerwechsel). Ein policy_published/p, das von der eigenen Policy abweicht: Der Eintrag ist nicht korrekt veröffentlicht, oder es gab eine ungewollte Änderung. Diese drei Signale verdienen eine sofortige Untersuchung, unabhängig vom Rest des Berichts.

Von der Lektüre zum Aktionsplan

Ein Bericht zu lesen ist nur der halbe Weg; der eigentliche Wert entsteht, wenn daraus eine geordnete Aufgabenliste abgeleitet wird. Nach dem Durchgang durch einen RUA-Bericht sortieren sich die Quellen in drei Körbe. Der erste Korb enthält die bestätigten legitimen Quellen, die durchkommen — hier gibt es nichts zu tun, außer sie im Auge zu behalten, falls sich später eine Konfiguration ändert. Der zweite Korb enthält die legitimen Quellen, die scheitern — das sind die echten Aufgaben, priorisiert nach Volumen: Eine Quelle mit einem count von mehreren Hundert, die an DKIM scheitert, kostet täglich Zustellbarkeit und Reputation, also zuerst. Der dritte Korb enthält die unbekannten Quellen — die sind erst zu identifizieren, bevor irgendetwas entschieden wird, denn eine unbekannte Quelle ist entweder eine vergessene legitime Quelle oder ein Fälschungsversuch, und die Behandlung ist genau entgegengesetzt.

Diese Dreiteilung verwandelt einen unübersichtlichen XML-Wust in eine klare Reihenfolge. Wichtig ist dabei, nicht der Versuchung zu erliegen, jede scheiternde IP sofort ins SPF zu stopfen, um „die Berichte grün zu machen". Das ist die klassische Falle: Man fügt blind IPs hinzu, überschreitet irgendwann das Limit von zehn Lookups und öffnet nebenbei die Tür für IPs, die man nie hätte autorisieren dürfen. Der richtige Weg ist, jede Quelle einzeln zu identifizieren, ihre Legitimität zu bestätigen und erst dann die passende Korrektur zu wählen — DKIM-Alignment für Drittplattformen, SPF-Eintrag für eigene Server, gar nichts für Fälschung.

Ein Bericht ist ein bewegtes Bild, keine Momentaufnahme

Ein einzelner RUA-Bericht ist wertvoll, aber die eigentliche Aussagekraft entsteht über die Zeit. Werden dieselben Quellen über mehrere Tage und mehrere Provider hinweg beobachtet, zeigen sich Trends, die ein einzelner Bericht niemals zeigt: eine Quelle, deren Fehlerquote nach einer Konfigurationsänderung plötzlich steigt; eine unbekannte IP, die eines Tages auftaucht und in den folgenden Berichten wiederkehrt; ein saisonaler Versanddienstleister, der nur zu bestimmten Zeiten aktiv wird. Deshalb ist die kontinuierliche Auswertung wertvoller als die punktuelle Kontrolle — und deshalb lohnt es sich, die Berichte an einem Ort zu sammeln, statt sie einzeln zu öffnen und wieder zu vergessen. Liegen erst einmal ein paar Wochen Historie vor, wird jede neue Anomalie sofort sichtbar, weil das Bild des normalen Versands bekannt ist.

Thomas entschlüsselt die Berichte

XML von Hand zu öffnen und zu entschlüsseln, ist machbar — aber mühsam und potenziell irreführend, wenn man nicht weiß, wohin man schauen muss. Thomas, der virtuelle CISO, liest die Berichte fortlaufend, benennt die Quellen, die durchkommen, und die, die Aufmerksamkeit verdienen, und liefert eine klare Diagnose ohne rohes XML.

Eine Domain kostenlos analysieren oder ein Konto erstellen für DMARC-Berichte, die auf einen Blick lesbar sind.

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