Wie man DMARC-Aggregatberichte (RUA) liest

<report_metadata>
  <org_name>google.com</org_name>
  <report_id>14217...</report_id>
  <date_range><begin>1718...</begin><end>1718...</end></date_range>
</report_metadata>

<policy_published>
  <domain>beispiel.de</domain>
  <p>none</p><adkim>r</adkim><aspf>r</aspf><pct>100</pct>
</policy_published>

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <identifiers><header_from>beispiel.de</header_from></identifiers>
</record>

Die Felder, die über alles entscheiden

Pro Quelle zählen drei Dinge:

• source_ip und count — wer gesendet hat, und wie viel. Die volumenstarken Quellen sind die wichtigsten, um sie korrekt einzustellen.
• Die Ergebnisse dkim und spf in policy_evaluated — sie spiegeln die Ausrichtung wider, nicht nur das Bestehen des isolierten Mechanismus. Das ist die Zahl, die zählt: Eine Quelle kann rohes SPF bestehen und hier trotzdem spf: fail anzeigen, weil die Domain sich nicht mit dem From: ausrichtete.
• disposition — was der Empfänger tatsächlich getan hat (none, quarantine, reject), gemäß der aktuellen Richtlinie.

Eine Quelle, bei der dkim oder spf pass anzeigt, ist authentifiziert und sicher durchzusetzen. Eine Quelle, bei der beide fail sind, ist die problematische Menge — entweder ein noch nicht ausgerichteter legitimer Absender, oder ein Fälscher.

Berichte in Aktionen verwandeln

Der Ablauf ist immer derselbe, und darum geht es:

1. Über mehrere Berichte aggregieren. Ein einzelner Tag eines einzigen Providers ist nur ein Fragment. Erst die Kombination zahlreicher Berichte über einige Wochen ergibt das vollständige Bild derer, die für die Domain senden.
2. Jede legitime Quelle identifizieren. Diese volumenstarke IP, die DKIM besteht, ist wahrscheinlich die Mail-Plattform. Die, die an beiden scheitert, kann das CRM sein, die Fakturierung, oder ein Tool, das ein Team ohne Rücksprache mit der IT installiert hat. Jede gehört benannt.
3. Die Ausrichtung der legitimen korrigieren. Das fehlende include: zu SPF hinzufügen, eine DKIM-Signatur mit ausgerichtetem d= einrichten, bis jede echte Quelle ein pass anzeigt.
4. Die Ausfälle abnehmen sehen. Sind die einzigen verbleibenden fail-Quellen unbekannt — Fälscher —, ist der Moment zum Verschärfen gekommen.
5. Die Richtlinie hochfahren. Erst auf quarantine wechseln, dann reject, und dabei prüfen, dass die Berichte sauber bleiben. Die vollständige Sequenz steht in p=reject erreichen.

Warum man aufgibt — und wie man es vermeidet

Rohes XML von Hand zu lesen skaliert nicht. Ein mittelgroßes Unternehmen kann dutzende Berichte pro Tag von zahlreichen Providern erhalten, jeder listet zahlreiche IPs. Einen Strom von IP-Adressen mit „ah, das ist unser Zendesk" abzugleichen ist mühsam und fehleranfällig — genau deshalb sammeln so viele Domains eine Zeit lang Berichte, um dann still im p=none aufzuhören. Die Berichte waren nie das Problem; ihnen Sinn zu geben, schon.

Die Lösung ist, eine Software die Aggregation und Übersetzung machen zu lassen. Genau dafür ist Thomas, der virtuelle CISO, konzipiert: Er ingestiert die Aggregatberichte, verwandelt die rohen IPs und PTRs in wiedererkennbare Dienstnamen („das Mailchimp des Hauses", „ein nicht konfiguriertes SendGrid-Subkonto"), bewertet die Bereitschaft über ein gleitendes Fenster, und benennt genau die Quellen, die vor jedem Schritt zu p=reject zu korrigieren sind.

Was die Aggregatberichte nicht sagen

Die Aggregatberichte sind mächtig, aber ihre Grenzen zu kennen vermeidet, falsche Schlüsse aus ihnen zu ziehen:

• Kein Nachrichteninhalt. Die Aggregatberichte enthalten Zählungen und Authentifizierungsergebnisse, nie die Betreffs, Rümpfe oder Empfängeradressen. Sie sagen, dass eine Quelle im Namen der Domain gesendet hat und wie sie sich authentifiziert hat — nicht, was die Post sagte. (Ein separater und selteneren Berichtstyp — forensisch oder Fehlerbericht, RUF — kann geschwärzte Stichproben enthalten, aber viele Provider senden sie aus Datenschutzgründen gar nicht.)
• Eine Verzögerung von etwa einem Tag. Die Berichte decken ein Fenster von 24 Stunden ab und treffen danach ein: Der Blick geht immer auf gestern, nicht auf den gegenwärtigen Moment. Nach einer Änderung am Eintrag ist keine Echtzeit-Rückmeldung zu erwarten; ein bis zwei Tage Geduld gehören dazu. Dieser tägliche Rhythmus ist im Standard verankert — warum die Berichte einmal pro Tag eintreffen erklärt die Hintergründe.
• Pro Quelle, nicht pro Nachricht. Eine Zeile aggregiert zahlreiche Nachrichten derselben IP mit demselben Ergebnis. Eine einzelne E-Mail lässt sich mit den reinen Aggregatdaten nicht nachverfolgen.
• Nur die teilnehmenden Empfänger. Die meisten großen Provider senden Berichte, aber nicht alle. Die Berichte repräsentieren die große Mehrheit der Post, nicht buchstäblich die Gesamtheit.
• Rohe IPs, keine Namen. Der Bericht sagt 198.51.100.7, nicht „das Zendesk des Hauses". Die Adressen den Diensten zuzuordnen bleibt Handarbeit — und das ist der zeitraubendste Teil der Arbeit.

Nichts davon mindert ihren Wert; es bedeutet nur, dass die Aggregatberichte eine Karte sind, keine Live-Kamera. Zu lesen sind sie als Trends über Wochen, nicht als sofortige Telemetrie, und zu kombinieren mit Werkzeugen, die die IPs in wiedererkennbare Absender verwandeln.

Drei häufige Lesefallen

Ein paar Reflexe vermeiden, falsche Schlüsse aus einem Bericht zu ziehen:

• Bestehen des Mechanismus und Ausrichtung verwechseln. Die Felder dkim/spf in policy_evaluated spiegeln die Ausrichtung wider. Eine Quelle kann sehr wohl ein rohes SPF bestehen und hier trotzdem spf: fail anzeigen, weil ihr Envelope sich nicht auf dem From: ausrichtet. Diese Felder lesen sich immer als „ausgerichtet?", nicht „hat der Mechanismus technisch bestanden?".
• Vor unbekannten IPs in Panik geraten. Eine Spitze kleiner verstreuter Quellen ist oft Weiterleitung (ein Empfänger, der die Post weitersendet) statt eines Angriffs. Volumen und Regelmäßigkeit kommen zuerst, erst dann der Schluss auf Fälschung: Ein Fälscher sucht das Volumen, eine Weiterleitung hinterlässt einen langen Schweif von Ein-Nachricht-Konten.
• Vergessen, was disposition sagt. Im p=none bleibt die disposition none, auch wenn dkim und spf scheitern — das ist normal, es wird ja noch nichts angewendet. Ein disposition: none heißt nicht „alles in Ordnung": Es sind dkim/spf, die verraten, ob eine Quelle gesund ist.

DMARCbis und die Berichte (RFC 9990)

DMARCbis (Mai 2026) hat die Spezifikation auf drei RFCs verteilt: 9989 für das Protokoll, und vor allem 9990, nun den hier behandelten Aggregatberichten gewidmet. Der Geist ändert sich nicht — dieselben Blöcke Quelle / Volumen / Ergebnisse — aber zwei Details werden nach und nach in den Berichten auftauchen:

• Der Block <policy_published> wird <pct> nicht mehr zeigen (Tag entfernt) und kann <np> enthalten, die Richtlinie für nicht existierende Subdomains. Taucht noch pct auf, ist das schlicht ein noch nicht aktualisierter Empfänger.
• Die Bestimmung der Organisationsdomain stützt sich nun auf den DNS Tree Walk statt auf die Public Suffix List, was die Zuordnung vorhersehbarer macht.

Konkret bewegt sich die Art, einen Bericht zu lesen, nicht. Bemerkenswert ist nur, dass die Berichte während des Übergangs je nach Provider altes und neues Format mischen können.

Ein reales Lesebeispiel: die erste Woche im p=none

Um das Ganze konkret zu machen, sei die erste Woche nach der Veröffentlichung eines DMARC-Eintrags im p=none mit einer rua=-Adresse betrachtet. Die ersten Berichte treffen am nächsten Tag ein, und das anfängliche Bild ist fast immer chaotisch: ein Dutzend IPs, davon die Hälfte unbekannt, ein Mix aus pass und fail, und keine offensichtliche Struktur. Der Reflex, in Panik zu geraten, ist normal — aber falsch. Die richtige Haltung ist, geduldig zu aggregieren.

Nach einer Woche werden die IPs nach Volumen gruppiert. An der Spitze finden sich meist zwei oder drei dominante Quellen, die den Großteil des legitimen Verkehrs ausmachen: die Mail-Plattform, das Marketing-Tool, der Transaktionsanbieter. Diese bestehen in der Regel DKIM oder SPF und haben Priorität, um sauber ausgerichtet zu werden. Weiter unten kommt ein langer Schweif kleiner Quellen mit ein oder zwei Nachrichten je: Ein Teil davon ist Weiterleitung (legitim, aber fremde Verantwortung), ein anderer sind unbekannte Tools, die ein Team ohne Rücksprache installiert hat, und gelegentlich echte Fälschungsversuche. Diese Sortierung — dominante Quellen zuerst, Schweif danach — ist die praktische Übersetzung des gesamten Ablaufs oben, und sie ist es, die eine Wand aus XML in einen umsetzbaren Plan verwandelt.

Die Berichte eintreffen lassen

Zwei Dinge braucht der Start: einen DMARC-Eintrag mit einer rua=-Adresse, und einen Ort, wohin die Berichte zu senden sind. Die genaue Syntax dieses Tags — samt dem Zusatzschritt, wenn die Berichte an eine andere Domain gehen — steht in die rua-Adresse richtig konfigurieren. Am schnellsten ist ein kostenloses DMARC-Sammelpostfach, das das XML automatisch ingestiert und parst — eine DNS-Zeile, und die täglichen Berichte werden zu einem lesbaren Dashboard statt zu einem Ordner voller Anhänge.

Der erste Schritt ist eine Prüfung der aktuellen Konfiguration mit unserem kostenlosen DMARC-Analyzer — er zeigt, ob wirklich nur eine rua=-Adresse gesetzt ist und wie sich die Quellen heute ausrichten. Danach ein Konto erstellen, um die Berichte fortlaufend zu sammeln und zu lesen, mit Thomas, der jede Quelle übersetzt und den Weg zur Durchsetzung anzeigt.

Neu bei den Grundlagen? Der Einstieg führt über was ist DMARC und wie SPF, DKIM und DMARC zusammenarbeiten.