DMARC-Berichte: RUA vs. RUF, wo ist der Unterschied?

RUA und RUF im DMARC-Eintrag konfigurieren

Beide Adressen werden im _dmarc-Eintrag konfiguriert:

_dmarc.beispiel.de.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de;
   ruf=mailto:ruf@beispiel.de; fo=1"

• rua=: Die Adresse, an der die aggregierten Berichte eingehen sollen. Mehrere sind möglich, durch Kommas getrennt.
• ruf=: Die Adresse für die forensischen Berichte. Oft eine andere, manchmal gar nicht vorhanden.
• fo=: Steuert, wann ein RUF erzeugt wird. fo=0 (Standard) = nur wenn alle Prüfungen scheitern. fo=1 = sobald eine Prüfung scheitert. fo=d = nur wenn DKIM scheitert. fo=s = nur wenn SPF scheitert. In der Praxis liefert fo=1 am meisten Detail, aber auch am meisten Volumen.

Sind keine RUFs erwünscht (aus Compliance-Gründen oder mangels Auswertung), bleiben ruf= und fo= einfach weg. Der aggregierte Bericht (RUA) ist der eigentliche Wert — der RUF ist eine Ergänzung für spezifische Diagnosen.

Was in der Praxis zu tun ist

Für die überwiegende Mehrheit der Deployments reichen die RUAs völlig aus. Sie geben eine vollständige Sicht darauf, wer im Namen der Domain versendet, mit welchen Ergebnissen, von welchen IPs — genau das, was der Weg in Richtung p=reject erfordert. Sie regelmäßig zu analysieren (oder von einem Tool oder von Thomas analysieren zu lassen) zeigt, welche Quellen zu korrigieren sind, in welcher Reihenfolge und wann sich die Policy verschärfen lässt.

RUFs sind nützlich, wenn ein sehr spezifisches Problem zu diagnostizieren ist: ein bestimmter Nachrichtentyp, der scheitert, eine unbekannte Quelle, die im Namen der Domain versendet. Zu öffnen sind sie aber nur in Kenntnis ihres potenziell sensiblen Inhalts — und vor allem nicht an Dritte weiterzugeben, ohne zu prüfen, was sie enthalten.

Der richtige Reflex zum Start: ein rua= zu einem dedizierten Postfach (oder einer DMARC-Plattform) konfigurieren, die Berichte ein paar Tage eintrudeln lassen und sie lesen. Die Diagnose, wer im Namen der Domain versendet, steckt darin fast vollständig.

Wer RUA-Berichte verschickt

Die großen Akteure verschicken RUAs zuverlässig: Gmail, Outlook/Microsoft, Yahoo, Apple Mail, AOL, ProtonMail und viele andere. Das ist nicht vollständig — nur die Akteure, die das Protokoll implementiert haben, verschicken Berichte — aber in der Praxis decken die empfangenen Berichte die große Mehrheit des weltweiten E-Mail-Traffics ab. Bei großem Versandvolumen sind schnell genug Daten für eine Diagnose beisammen.

Hinweis: RUAs decken nur den Traffic zu den Postfächern der Anbieter ab, die sie verschicken. Geht Post an selbstgehostete Server oder kleine Anbieter, erscheinen diese Ergebnisse nicht in den Berichten.

Häufige Fragen

Muss ich ruf= konfigurieren? Nein. Die RUAs reichen für nahezu alle Fälle. ruf= gehört nur dann konfiguriert, wenn ein konkreter forensischer Diagnosebedarf besteht und die Datenschutzimplikationen abgewogen sind.

Wie lange dauert es, bis ich Berichte bekomme? Einige Stunden bis 24 Stunden nach Veröffentlichung des DMARC-Eintrags. Die ersten Berichte kommen oft am nächsten Morgen. Sie decken den vorangegangenen Zeitraum ab.

Kommen die Berichte von allen Empfängern? Nein. Nur von den Akteuren, die das Protokoll implementiert haben. Gmail und Microsoft verschicken sehr zuverlässige Berichte; viele kleine Server verschicken keine.

Legen RUAs personenbezogene Daten offen? Nein: Die aggregierten Berichte enthalten Statistiken und IPs, aber weder den Inhalt der Nachrichten noch die Adressen der Empfänger. RUFs hingegen können welche enthalten — deshalb sind sie mit Vorsicht zu behandeln.

Kann ich die Berichte an einer externen Adresse empfangen? Ja, aber die Domain der Empfangsadresse muss über einen TXT-Eintrag bei _dmarc.externe-domain.de autorisiert sein (damit nicht jeder seine Berichte an ein beliebiges Postfach schicken kann). Liegt die Adresse in der eigenen Domain, geschieht das automatisch.

Wie die Berichte den Weg zu p=reject ebnen

Der Hauptwert der DMARC-Berichte liegt nicht darin, zu bestätigen, dass die E-Mails durchkommen — sondern darin, zu zeigen, wie sie durchzubringen sind. Ein RUA-Bericht ist in Wirklichkeit eine Karte der Versandflüsse: Jeder <record>-Block ist eine Quelle, und das Authentifizierungsergebnis dieser Quelle benennt genau, was zu korrigieren ist. Der Prozess ist von Natur aus iterativ.

Zu Beginn, mit p=none, laufen Berichte ein, ohne dass irgendetwas blockiert wird. Das ist die Beobachtungsphase: Sichtbar wird, welche IPs im Namen der Domain versenden, welche durchkommen, welche scheitern und welche gar nicht wiedererkannt wurden. Die legitimen Quellen werden eine nach der anderen korrigiert — DKIM aktivieren, SPF ausrichten, unbekannte Quellen ausschließen — und die Berichte überwacht, um zu bestätigen, dass jede Korrektur gegriffen hat.

Sobald die Berichte zeigen, dass die große Mehrheit der legitimen Quellen durchkommt (typischerweise >95 %), folgt der Übergang zu p=quarantine. Dieselbe Logik gilt: Berichte überwachen, prüfen, dass keine legitime Quelle betroffen ist, nachfeilen. Dann folgt p=reject. Bei jedem Schritt sind die RUA-Berichte das Messinstrument: Sie zeigen den erreichten Stand, nicht nur ob es durchkommt oder bricht.

Die Feinheit: Ein Bericht, der dmarc=fail auf einer IP zeigt, ist nicht zwangsläufig ein Problem. Handelt es sich um eine nicht wiedererkannte IP, ist es vielleicht Fälschung (jemand versucht, die Domain zu usurpieren) — und p=reject verhindert es. Handelt es sich um eine als schlecht konfiguriert erkannte legitime Quelle, ist das etwas zum Korrigieren. Die beiden zu unterscheiden ist der Kern der Interpretationsarbeit, die die Berichte erst ermöglichen.

Die Quellen in den Berichten identifizieren

Ein Rohbericht liefert eine IP. Ein gut ausgewerteter Bericht sagt, wem diese IP gehört. Genau diese Umwandlung — IP → identifizierter Versanddienst — verwandelt einen Bericht in einen Aktionsplan. DMARC-Tools erledigen diese Arbeit automatisch (siehe die Tools zur Analyse der Berichte), für ein paar Schlüssel-IPs geht es aber auch manuell über Reverse-Lookup-Tools.

Die wiederkehrenden IPs mit dkim=pass, spf=pass, dmarc=pass sind die gut konfigurierten Quellen — sie bleiben unangetastet. Die wiederkehrenden IPs mit Fehlschlägen auf einer wiedererkannten Quelle sind die Korrekturprioritäten. Die unbekannten IPs mit dmarc=fail sind entweder Fälschung (keine Aktion nötig, p=reject erledigt seine Arbeit) oder eine vergessene legitime Quelle (zu korrigieren oder als abgeschaltet zu bestätigen).

Warum RUFs praktisch verschwinden

Es lohnt sich, kurz zu verstehen, warum die forensischen Berichte in den letzten Jahren so an Boden verloren haben. Der Grund ist im Kern der Datenschutz. Ein RUF-Bericht enthält potenziell den vollständigen Inhalt einer gescheiterten E-Mail — Absenderadresse, Betreff, manchmal Text — und dieser Inhalt stammt oft von einem echten Nutzer, dessen Nachricht aus einem harmlosen technischen Grund (eine schlecht ausgerichtete Signatur, ein Weiterleitungsfehler) an der Authentifizierung scheiterte. Diese Daten an eine dritte Domain zu schicken, ist unter der DSGVO heikel: Der Provider, der den RUF verschickt, würde faktisch personenbezogene Daten seiner eigenen Nutzer an einen Dritten weitergeben, ohne deren Zustimmung. Genau deshalb haben Google, Microsoft und Yahoo die RUF-Unterstützung eingestellt oder nie ernsthaft aktiviert.

Die praktische Konsequenz ist eindeutig: Selbst mit ruf= und fo=1 im Eintrag kommt von den großen Anbietern nichts. RUFs treffen höchstens von einigen kleineren, oft europäischen Betreibern ein, die sie noch verschicken. Für die meisten Organisationen bedeutet das, dass die RUF-Konfiguration wenig bringt und die RUA-Auswertung der einzige realistische Weg zur Diagnose bleibt. Auf forensische Berichte lässt sich ein Deployment also nicht stützen — sie sind ein Bonus, kein Fundament.

Ein pragmatischer Startablauf

Beim Start bei null ist der einfachste und sicherste Ablauf dieser. Zuerst einen DMARC-Eintrag mit p=none und einem rua= veröffentlichen, das auf ein dediziertes Postfach oder eine Analyse-Plattform zeigt — keine ruf=, keine fo=. Die Berichte zwei bis drei Wochen eintrudeln lassen, ohne etwas zu blockieren. In dieser Zeit sammelt sich eine repräsentative Sicht auf alle Versandquellen, denn die großen Provider decken den Großteil des Traffics ab. Sind diese Berichte ausgewertet, liegt die vollständige Quellenkarte vor, ohne dass je ein forensischer Bericht nötig war. Erst bei einem sehr spezifischen Problem, das die aggregierten Daten nicht erklären, kommt die Frage nach RUFs überhaupt auf — und selbst dann sind zuerst die Datenschutzimplikationen abzuwägen. In der überwiegenden Mehrheit der Fälle tragen die RUA-Berichte allein bis p=reject.

Thomas liest die Berichte

RUA-Berichte zu empfangen ist eine Sache; sie auszuwerten eine andere. Thomas, der virtuelle CISO, liest die Berichte stellvertretend, benennt die Quellen, die durchkommen, die, die scheitern, warum und in welcher Reihenfolge sie zu korrigieren sind. Er verwandelt rohes XML in einen klaren Aktionsplan in Richtung p=reject.

Eine Domain kostenlos analysieren oder ein Konto erstellen für automatisch entschlüsselte DMARC-Berichte.