DMARC-Reports lesen: Was rua- und ruf-Daten über Missbrauch verraten

Ein DMARC-Eintrag ohne ausgewertete Reports ist wie eine Kamera ohne jemanden, der die Aufnahmen anschaut: Die Daten laufen auf, aber niemand merkt, wenn draußen etwas passiert. Für eine Domain, unter der Sie adressierten B2B-Outreach betreiben, sind diese Berichte die einzige verlässliche Quelle dafür, ob fremde Server versuchen, in Ihrem Namen zu versenden. Dieser Artikel erklärt den Unterschied zwischen rua- und ruf-Reports und zeigt, wie Sie die XML-Daten tatsächlich lesen, statt sie nur ungeöffnet im Postfach zu sammeln.

Warum Reports für eine Kaltakquise-Domain besonders wichtig sind

Wer adressierten B2B-Outreach betreibt, verschickt naturgemäß E-Mails, die auf den ersten Blick wie gezielte, personalisierte Ansprache aussehen — genau das Muster, das auch Spoofing-Versuche imitieren, wenn jemand Ihre Domain für Phishing oder Betrugsmails missbraucht. Eine Domain mit gutem Ruf und aktivem Outreach ist für Missbrauch attraktiver als eine unbekannte, inaktive Domain, weil Empfänger ihr eher vertrauen und weniger misstrauisch reagieren, wenn eine unerwartete Mail eintrifft.

DMARC-Reports sind der einzige systematische Weg, das zu bemerken, bevor ein Empfänger sich beschwert oder Ihre Domain wegen fremder Missbrauchsversuche insgesamt an Vertrauen verliert. Ohne ausgewertete rua-Daten erfahren Sie von einem Spoofing-Vorfall im schlechtesten Fall erst über eine verärgerte Rückmeldung eines angeschriebenen Unternehmens, das die gefälschte Mail für echt hielt — zu einem Zeitpunkt, an dem der Schaden für Ihren Domain-Ruf bereits entstanden ist.

Gerade weil Kaltakquise-Domains regelmäßig neue, bisher unbekannte Empfänger anschreiben, ist die Grenze zwischen legitimer Ansprache und Spoofing-Verdacht für Außenstehende ohnehin schmal. Eine sauber überwachte Domain, bei der Sie im Ernstfall schnell nachweisen können, welche Server tatsächlich autorisiert senden, ist auch im Streitfall mit einem verärgerten Empfänger die bessere Ausgangslage.

Hinzu kommt ein praktischer Nebeneffekt: Wer seine rua-Reports regelmäßig liest, bemerkt nicht nur fremden Missbrauch, sondern auch eigene, unabsichtliche Konfigurationsfehler deutlich früher — etwa wenn ein neues Postfach für eine Bauer Maschinenbau AG als Testkunde aufgesetzt wurde und dessen Versand mangels korrekter DKIM-Signatur konsequent durchfällt, ohne dass das ohne Reports jemandem auffallen würde.

rua vs. ruf: zwei Report-Typen, ein Missverständnis

Das rua-Tag (Reporting URI for Aggregate reports) legt fest, wohin tägliche, zusammengefasste Berichte über alle Zustellversuche im Namen Ihrer Domain gehen — unabhängig davon, ob sie DMARC bestanden haben oder nicht. Ein rua-Report fasst einen ganzen Tag in einer XML-Datei zusammen: welche IP-Adressen wie viele Mails geschickt haben und mit welchem Ergebnis.

Das ruf-Tag (Reporting URI for Forensic reports) sollte theoretisch pro einzelner fehlgeschlagener Mail einen detaillierten, teils sogar den Mail-Inhalt betreffenden Bericht auslösen. In der Praxis versenden die meisten großen Mail-Provider seit Jahren keine oder kaum noch ruf-Reports, weil ein forensischer Bericht personenbezogene Daten aus der eigentlichen Mail enthalten kann und Provider das aus Datenschutzgründen vermeiden. Setzen Sie ruf trotzdem, wenn ein Empfänger es unterstützt, schadet es nicht — verlassen Sie sich aber nicht darauf, dass es Ihre Hauptquelle wird.

Für die laufende Überwachung Ihrer Domain sind praktisch ausschließlich rua-Reports relevant. Wer Zeit in den Aufbau einer Auswertung investiert, sollte diese Zeit deshalb vollständig in die rua-Seite stecken — ein Auswertungsprozess, der auf ruf-Daten wartet, bleibt in der Praxis meist leer, weil die Berichte schlicht nicht ankommen.

Der Aufbau eines rua-XML-Reports

Ein rua-Report kommt als komprimierte XML-Datei per Mail an die im rua-Tag hinterlegte Adresse. Die Struktur folgt immer demselben Schema, auch wenn der Absender-Provider wechselt:

Entscheidend ist: policy_evaluated kann pass zeigen, selbst wenn SPF oder DKIM einzeln fail melden — solange der jeweils andere Mechanismus besteht und mit der From-Domain aligned ist, reicht das für ein DMARC-pass. Erst wenn beide fehlschlagen oder keiner aligned ist, meldet policy_evaluated ein fail. Dieses Detail verwirrt beim ersten Lesen eines Reports fast immer, weil man intuitiv erwartet, dass beide Mechanismen bestehen müssten.

Für die tägliche Praxis reicht es, sich auf drei Felder zu konzentrieren: source_ip, um zu wissen, wer gesendet hat, policy_evaluated, um zu wissen, ob DMARC bestanden wurde, und header_from, um zu wissen, unter welcher sichtbaren Absenderdomain die Mail lief. Die restlichen Felder liefern Kontext, sind für eine erste Einschätzung aber selten entscheidend.

• report_metadata — wer den Bericht erstellt hat (der empfangende Mail-Provider) und für welchen Zeitraum.
• policy_published — die zum Zeitpunkt des Berichts für Ihre Domain gültige DMARC-Policy, also p, sp, pct und die Alignment-Modi.
• record — ein Block pro eindeutiger Kombination aus sendender IP und Ergebnis, das eigentliche Herzstück des Reports.
• row > source_ip — die IP-Adresse, die die Mail tatsächlich verschickt hat.
• row > count — wie viele Mails von dieser IP mit exakt diesem Ergebnis im Berichtszeitraum verschickt wurden.
• row > policy_evaluated — ob DMARC insgesamt bestanden wurde, pass oder fail, und welche Policy angewendet wurde.
• identifiers > header_from — die im sichtbaren From-Feld verwendete Domain, der eigentliche Vergleichspunkt für Alignment.
• auth_results > spf und auth_results > dkim — die Einzelergebnisse der beiden Prüfmechanismen, jeweils mit der geprüften Domain.

Warum Sie einen Report-Viewer brauchen

Ein einzelner rua-Report ist noch überschaubar. Bei mehreren aktiven Sending-Domains und täglich eintreffenden Berichten von jedem großen Mail-Provider, mit dem Sie Kontakt hatten, summiert sich das schnell auf Dutzende komprimierte XML-Dateien pro Woche — von Hand geöffnet und gelesen ist das nicht praktikabel, selbst wenn Sie die Struktur aus dem vorherigen Abschnitt im Kopf haben.

Ein Report-Viewer oder Aggregator-Tool sammelt eingehende rua-Mails automatisch, entpackt die XML-Dateien und stellt die Daten als durchsuchbare Tabelle oder Dashboard dar: alle source_ips über Zeit, Pass- und Fail-Raten je Absender, auffällige neue IPs. Für die tägliche Praxis ist ein solcher Viewer keine Kür, sondern die Voraussetzung dafür, dass die Reports überhaupt einen Nutzen bringen, statt nur den Posteingang der rua-Adresse zu füllen.

Wählen Sie ein Viewer-Tool danach aus, ob es einen klaren Verlauf über Zeit zeigt und neue, bisher unbekannte source_ips hervorhebt — genau diese beiden Funktionen sind es, die den eigentlichen Unterschied zwischen rohem Datenmüll und einer nutzbaren Überwachung ausmachen.

Missbrauch erkennen: worauf Sie in den Daten achten

Die eigentliche Auswertung läuft auf eine einfache Frage hinaus: Kennen Sie jede source_ip, die für Ihre Domain sendet, und kann jede davon erklären, warum sie DMARC besteht oder eben nicht?

Führen Sie sich regelmäßig eine einfache Referenzliste aller legitim autorisierten Absender vor Augen — Outreach-Tool, CRM, Transaktions-Mailer. Jede source_ip außerhalb dieser Liste verdient einen zweiten Blick, unabhängig davon, ob sie besteht oder fehlschlägt. Eine solche Liste muss nicht kompliziert sein, ein einfaches internes Dokument mit den bekannten IP-Bereichen und Diensten reicht meist völlig aus.

• Unbekannte source_ip mit policy_evaluated=fail: das klassische Signal für Spoofing — jemand hat Ihre Domain als Absender missbraucht, ohne über Ihre autorisierte Infrastruktur zu senden.
• Unbekannte source_ip mit policy_evaluated=pass: seltener, aber möglich, wenn Ihr SPF-Eintrag zu weit gefasst ist, etwa durch einen alten, nicht mehr genutzten Include eines früheren Dienstleisters.
• Bekannte, legitime source_ip mit auffällig steigender fail-Rate: meist kein Missbrauch, sondern ein technisches Problem bei genau diesem Versandkanal, etwa ein neu eingerichtetes Postfach ohne korrektes DKIM.
• Auffällig hohes count für eine einzelne unbekannte IP in kurzer Zeit: kann auf eine gezielte Spoofing- oder Phishing-Welle im Namen Ihrer Domain hindeuten, nicht nur auf einen Einzelfall.

Was tun, wenn Sie Missbrauch finden

Bestätigt sich der Verdacht auf Spoofing — eine unbekannte IP, die konsequent im Namen Ihrer Domain fehlschlägt, oft über mehrere Tage mit ähnlichem Muster — ist der erste, wirksamste Schritt fast immer eine schnellere Policy-Verschärfung: von p=quarantine zu einem höheren pct-Wert oder direkt zu p=reject, sofern Ihre legitimen Absender bereits sauber laufen. Reject verhindert die Zustellung der gefälschten Mails beim Empfänger, unabhängig davon, wer der Absender ist.

Parallel lohnt sich die Prüfung, ob die missbrauchten Mails gemeldet werden können — größere Mail-Provider bieten Missbrauchsmeldungen für Phishing im Namen fremder Domains an. Wird Ihre Domain gezielt und wiederholt für Betrugsmails an Dritte missbraucht, ist das auch wettbewerbsrechtlich relevant, etwa im Kontext des UWG bei unerlaubter Werbung unter falschem Absender — dokumentieren Sie die betroffenen Reports in diesem Fall lückenlos, bevor Sie rechtliche Schritte prüfen.

Behalten Sie nach einer erkannten Missbrauchswelle die Aggregatberichte für einige Wochen engmaschiger im Blick als sonst üblich. Spoofing-Versuche kommen selten einmalig vor — wer Ihre Domain einmal als Absenderziel gewählt hat, versucht es häufig in Wellen erneut, gerade wenn die erste Welle noch keine sichtbare Reaktion Ihrerseits ausgelöst hat.

Häufige Fragen