Wie man DMARC-Aggregatberichte (RUA) liest

Wenn man zum ersten Mal einen DMARC-Aggregatbericht öffnet, sieht es wie Rauschen aus: eine Wand aus XML voller IP-Adressen und Pass/Fail-Flags. Und doch sind diese Berichte das Nützlichste, was DMARC dir bietet. Sie sind die Karte, die eine Domain von der Überwachung zur Durchsetzung führt — das einzig zuverlässige Mittel, um alle zu entdecken, die in deinem Namen senden, bevor du die Richtlinie verschärfst. Dieser Leitfaden erklärt, was darin steckt, wie man es liest, und wie man handelt.

Was die Aggregatberichte sind

Wenn du einen DMARC-Eintrag mit einer rua=-Adresse veröffentlichst (siehe was ist DMARC für die Grundlagen), senden dir die empfangenden Provider — Google, Microsoft, Yahoo und hunderte andere — eine tägliche Zusammenfassung. Jeder Bericht deckt ein Fenster von 24 Stunden ab und beantwortet eine Frage: Von all der Post, die sich auf deine Domain berufen hat, woher kam sie, und hat sie sich authentifiziert?

Es sind aggregierte Berichte (RUA) — nach Sendequelle gruppierte Zählungen, keine Kopien einzelner E-Mails. (Ein anderer, selteneren Typ, forensisch oder Fehlerbericht genannt, RUF, kann geschwärzte Stichproben enthalten, aber es sind die Aggregatberichte, die man im Alltag konsultiert.) Sie treffen im XML ein, in der Regel mit gzip oder zip komprimiert, an eine E-Mail angehängt.

Anatomie des XML

Jeder Bericht hat dieselbe Form. Drei Teile zählen:

1. Metadaten des Berichts — wer ihn gesendet hat und das Zeitfenster:

<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>

2. Veröffentlichte Richtlinie — der DMARC-Eintrag, den der Empfänger an jenem Tag für dich gesehen hat. Nützlich, um zu bestätigen, dass sich dein Eintrag wie geplant verbreitet hat:

<policy_published>
  <domain>ton-domaine.fr</domain>
  <p>none</p><adkim>r</adkim><aspf>r</aspf><pct>100</pct>
</policy_published>

3. Records — das Herzstück des Berichts. Ein Block pro Sendequelle, mit einer Volumenzählung und den Authentifizierungsergebnissen:

<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>ton-domaine.fr</header_from></identifiers>
</record>

Lies diesen Block wie einen Satz: „Von der IP 203.0.113.10 haben sich 42 Nachrichten auf ton-domaine.fr berufen; DKIM ausgerichtet und bestanden, SPF nicht." Da DMARC nur einen einzigen ausgerichteten Durchgang braucht, haben diese 42 Nachrichten DMARC dank DKIM bestanden.

Die Felder, die über alles entscheiden

Konzentriere dich für jede Quelle auf 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 deinem From: ausrichtete.
• disposition — was der Empfänger tatsächlich getan hat (none, quarantine, reject), gemäß deiner 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. Kombiniere zahlreiche Berichte über einige Wochen, um das vollständige Bild derer zu sehen, die für dich senden.
2. Jede legitime Quelle identifizieren. Diese volumenstarke IP, die DKIM besteht, ist wahrscheinlich deine Mail-Plattform. Die, die an beiden scheitert, kann dein CRM, deine Fakturierung, oder ein Tool sein, das ein Team ohne Rücksprache mit der IT installiert hat. Benenne jede.
3. Die Ausrichtung der legitimen korrigieren. Füge das fehlende include: zu SPF hinzu, richte eine DKIM-Signatur mit ausgerichtetem d= ein, bis jede echte Quelle ein pass anzeigt.
4. Die Ausfälle abnehmen sehen. Wenn die einzigen verbleibenden fail-Quellen unbekannt sind — Fälscher — bist du bereit zu verschärfen.
5. Die Richtlinie hochfahren. Wechsle zu quarantine, dann reject, und prüfe dabei, 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, dein virtueller CISO, konzipiert: Er ingestiert deine Aggregatberichte, verwandelt die rohen IPs und PTRs in wiedererkennbare Dienstnamen („dein Mailchimp", „ein nicht konfiguriertes SendGrid-Subkonto"), bewertet deine Bereitschaft über ein gleitendes Fenster, und sagt dir genau, welche Quellen du vor jedem Schritt zu p=reject korrigieren musst.

Was die Aggregatberichte dir 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 in deinem Namen 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: Du schaust immer auf gestern, nicht auf den gegenwärtigen Moment. Erwarte keine Echtzeit-Rückmeldung, wenn du einen Eintrag änderst; lass einen oder zwei Tage.
• Pro Quelle, nicht pro Nachricht. Eine Zeile aggregiert zahlreiche Nachrichten derselben IP mit demselben Ergebnis. Du kannst eine einzelne E-Mail mit den reinen Aggregatdaten nicht nachverfolgen.
• Nur die teilnehmenden Empfänger. Die meisten großen Provider senden Berichte, aber nicht alle. Deine Berichte repräsentieren die große Mehrheit deiner Post, nicht buchstäblich die Gesamtheit.
• Rohe IPs, keine Namen. Der Bericht sagt 198.51.100.7, nicht „dein Zendesk". Die Adressen den Diensten zuzuordnen liegt bei dir — 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. Lies sie als Trends über Wochen, nicht als sofortige Telemetrie, und kombiniere sie 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 deinem From: ausrichtet. Lies diese Felder 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 deine Post weitersendet) statt eines Angriffs. Schau auf Volumen und Regelmäßigkeit, bevor du auf Fälschung schließt: 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, du wendest noch nichts an. Lies ein disposition: none nicht als „alles in Ordnung": Es sind dkim/spf, die dir sagen, 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 Aggregatberichten gewidmet, die du hier liest. Der Geist ändert sich nicht — dieselben Blöcke Quelle / Volumen / Ergebnisse — aber zwei Details werden nach und nach in deinen Berichten auftauchen:

• Der Block <policy_published> wird <pct> nicht mehr zeigen (Tag entfernt) und kann <np> enthalten, die Richtlinie für nicht existierende Subdomains. Wenn du noch pct siehst, 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 deine Art, einen Bericht zu lesen, nicht. Beachte nur, dass deine 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, stell dir die erste Woche vor, nachdem du einen DMARC-Eintrag im p=none mit einer rua=-Adresse veröffentlicht hast. Die ersten Berichte treffen am nächsten Tag ein, und das anfängliche Bild ist fast immer chaotisch: ein Dutzend IPs, von denen du die Hälfte nicht wiedererkennst, 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 gruppierst du die IPs nach Volumen. An der Spitze finden sich meist zwei oder drei dominante Quellen, die den Großteil deines legitimen Verkehrs ausmachen: deine Mail-Plattform, dein Marketing-Tool, dein Transaktionsanbieter. Diese bestehen in der Regel DKIM oder SPF und sind deine Priorität, um sie sauber auszurichten. Weiter unten kommt ein langer Schweif kleiner Quellen mit ein oder zwei Nachrichten je: Ein Teil davon ist Weiterleitung (legitim, aber nicht deine 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

Du brauchst zwei Dinge, um zu starten: einen DMARC-Eintrag mit einer rua=-Adresse, und einen Ort, wohin die Berichte zu senden sind. Am schnellsten ist ein kostenloses DMARC-Sammelpostfach, das das XML automatisch ingestiert und parst — eine DNS-Zeile, und deine täglichen Berichte werden zu einem lesbaren Dashboard statt zu einem Ordner voller Anhänge.

Beginne damit, deine aktuelle Konfiguration mit unserem kostenlosen DMARC-Analyzer zu prüfen — er zeigt, ob du nur eine rua=-Adresse hast und wie deine Quellen sich heute ausrichten. Dann erstelle ein Konto, um deine Berichte fortlaufend zu sammeln und zu lesen, mit Thomas, der jede Quelle übersetzt und den Weg zur Durchsetzung anzeigt.

Neu bei den Grundlagen? Beginne mit was ist DMARC und wie SPF, DKIM und DMARC zusammenarbeiten.