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

Ein DMARC-RUA-Bericht landet als .xml.gz- oder .xml.zip-Datei im Anhang in deinem Postfach. Darin steckt XML, das auf den ersten Blick aussieht wie eine Flughafen-Anzeigetafel — viele Tags, wenig Erklärung. Doch sobald du weißt, wohin du schauen musst, erzählt ein RUA-Bericht eine sehr klare Geschichte: Wer hat in deinem Namen Mail verschickt, von wo aus, mit welchem Ergebnis. Dieser Leitfaden entschlüsselt die Struktur und sagt dir, welche Tags du zuerst anschauen solltest.

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>ton-domaine.fr</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>ton-domaine.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ton-domaine.fr</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>ton-domaine.fr</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 du lesen musst

report_metadata

• org_name: Wer den Bericht schickt. Google, Microsoft, Yahoo — das ist der Provider, der deine Nachrichten empfangen und bewertet hat.
• date_range: Der abgedeckte Zeitraum (Unix-Timestamps). Rechne sie um, damit du weißt, von welchem Tag der Bericht spricht.
• report_id: Eindeutige Kennung des Berichts, nützlich als Referenz, wenn du beim Provider nachhaken willst.

policy_published

Das, was der Provider zum Zeitpunkt des Berichts als deine Policy gesehen hat. Prüfe, ob <p> dem entspricht, was du durchsetzen willst. Steht da none, obwohl du dachtest, du hättest quarantine gesetzt, ist dein 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 deine erste Frage: Ist das eine IP, die du wiedererkennst? Dein Server, deine 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 deine 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 deine Domain.

Einen Bericht in der Praxis lesen: der Leseablauf

Wenn ein Bericht eintrifft, lies ihn in dieser Reihenfolge:

1. org_name — wer ihn schickt (Gmail, Outlook, Yahoo …).
2. date_range — aus welchem Zeitraum (gestern? vorgestern?).
3. policy_published/p — ist meine Policy korrekt sichtbar?
4. 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? Schau in auth_results für die Details.

Mit diesem Ablauf weißt du in wenigen Minuten, ob deine legitimen Quellen durchkommen und ob verdächtige IPs in deinem Namen 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 dir eine konsolidierte Sicht. Unser Analyzer macht genau das: Er liest deine Berichte, identifiziert deine Quellen und zeigt dir den Zustand jeder einzelnen — ohne dass du eine einzige XML-Datei öffnen musst.

Häufige Fragen

Meine Berichte kommen als .gz oder .zip. Wie öffne ich sie? Entpacke die Datei (gunzip auf Mac/Linux, 7-Zip oder WinRAR auf Windows), um an das .xml zu kommen, und öffne es dann in einem Texteditor oder Browser. Besser: nutze ein Analyse-Tool, 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). Wenn du mehrere vom selben Akteur bekommst, 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 deine deklarierte Policy. Manche Akteure haben Overrides (Whitelists, bilaterale Vereinbarungen), die die Durchsetzung abmildern. Das ist kein Fehler deinerseits.

Ich bekomme gar keine Berichte. Was ist los? Prüfe, ob dein DMARC-Eintrag korrekt veröffentlicht ist und rua=mailto:adresse@ton-domaine.fr enthält. Prüfe auch, 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? Fang damit an, sie per Reverse-DNS aufzulösen (nslookup IP oder dig -x IP) und schau, 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: Markiere sie nicht als „legitim", ohne ihre 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. Wenn du an eine Domain sendest, die kein Reporting implementiert hat, erscheinen diese Nachrichten nicht — selbst wenn deine Policy aktiv ist. 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 dir über deine tatsächliche Aufstellung verrät

Ein RUA-Bericht ist nicht nur eine Ergebnisliste — er ist eine Momentaufnahme deiner Authentifizierungs-Aufstellung. Wenn du jeden <record>-Block aufmerksam liest, kannst du ein präzises Bild deiner Lage rekonstruieren: welche Quellen funktionieren, welche kaputt sind und welche du noch gar nicht identifiziert hattest. 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 ohne dein Wissen Benachrichtigungen in deinem Namen verschickt.

Um das Maximum aus einem Bericht herauszuholen, geh über das Lesen Quelle für Quelle hinaus und suche nach 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 deiner Aufstellung.

Die Alarmsignale, auf die du achten solltest

Einige Konstellationen in einem Bericht sollten sofort deine Aufmerksamkeit erregen. Ein hoher count auf einer unbekannten IP: Jemand versendet viele Nachrichten und gibt vor, du zu sein, von einer IP aus, die du nicht wiedererkennst. Ist deine Policy p=none, kommen diese Nachrichten an ihr Ziel — mit dem Image deiner Domain. Plötzliche Fehlschläge auf einer IP, die du wiedererkennst: Irgendwo hat sich eine Konfiguration geändert (schlecht ausgeführte DKIM-Schlüsselrotation, Änderung der SPF-Konfiguration, Providerwechsel). Ein policy_published/p, das von deiner Policy abweicht: Dein 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 du daraus eine geordnete Aufgabenliste ableitest. Nachdem du einen RUA-Bericht durchgegangen bist, sortiere deine 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 deine echten Aufgaben, priorisiert nach Volumen: Eine Quelle mit einem count von mehreren Hundert, die an DKIM scheitert, kostet dich täglich Zustellbarkeit und Reputation, also zuerst. Der dritte Korb enthält die unbekannten Quellen — die musst du erst identifizieren, bevor du irgendetwas entscheidest, 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 in dein 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. Beobachtest du dieselben Quellen über mehrere Tage und mehrere Provider hinweg, siehst du 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. Wenn du erst einmal ein paar Wochen Historie hast, wird jede neue Anomalie sofort sichtbar, weil du weißt, wie dein normaler Versand aussieht.

Lass Thomas deine Berichte entschlüsseln

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, dein virtueller CISO, liest deine Berichte fortlaufend, sagt dir, welche Quellen durchkommen und welche Aufmerksamkeit verdienen, und liefert dir eine klare Diagnose ohne rohes XML.

Analysiere deine Domain kostenlos → oder erstelle ein Konto für DMARC-Berichte, die auf einen Blick lesbar sind.