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

Wenn du einen DMARC-Eintrag veröffentlichst, kannst du dir Berichte über die Authentifizierung deiner E-Mails zusenden lassen. Doch es gibt zwei sehr unterschiedliche Berichtstypen: RUA (aggregierte Berichte) und RUF (forensische Berichte). Die Verwechslung der beiden ist verbreitet, und die falsche Wahl kann dir entweder zu wenig Information zur Diagnose liefern oder zu viel — mit Datenschutzrisiken. Dieser Leitfaden erklärt den Unterschied, was jeder enthält und wie du sie konfigurierst.

RUA: aggregierte Berichte, die Flugstatistik

Die RUA-Berichte (Reporting URI for Aggregate) werden von den Providern und großen E-Mail-Anbietern (Gmail, Yahoo, Outlook …) an die E-Mail-Adresse geschickt, die du angibst. Sie fassen für jeden Absender die über einen Zeitraum (oft 24 Stunden) beobachteten Authentifizierungsergebnisse zusammen: Wie viele Nachrichten haben SPF, DKIM, DMARC bestanden, von welcher IP aus, mit welchem Ergebnis.

Es handelt sich um komprimierte XML-Dateien, die täglich von jedem Empfänger verschickt werden, der sich dafür entscheidet. Ein typischer RUA-Bericht sagt etwa: „347 Nachrichten von der IP 40.107.1.25, mit spf=pass, dkim=pass, dmarc=pass — und 12 Nachrichten von 192.0.2.1 mit spf=fail, dkim=fail, dmarc=fail."

Sie enthalten keinerlei Nachrichteninhalt: keinen Betreff, keinen Text, keinen Empfänger. Es sind ausschließlich statistische Metadaten. Deshalb sind RUAs zugleich nützlich (Gesamtsicht) und DSGVO-konform (keine personenbezogenen Daten der Empfänger).

RUF: forensische Berichte, das Detail eines Fehlschlags

Die RUF-Berichte (Reporting URI for Forensic) sind von ganz anderer Natur. Ebenfalls an eine von dir gewählte Adresse geschickt, werden sie durch ein Einzelereignis ausgelöst: eine Nachricht, die die Authentifizierung nicht bestanden hat. Jeder RUF-Bericht beschreibt diesen Fehlschlag im Detail und kann je nach Implementierung des Empfängers vollständige Header der Nachricht enthalten, manchmal sogar einen Auszug aus dem Text.

Das ist viel granularer — und viel sensibler. Ein RUF-Bericht kann die E-Mail-Adresse des Absenders, den Betreff, die Ursprungs-IP und weitere Metadaten der gescheiterten E-Mail enthalten. Das ist nützlich, um ein konkretes Problem zu diagnostizieren (warum ist genau diese Nachricht gescheitert?), wirft aber ernste Fragen zu Datenschutz und DSGVO-Konformität auf — besonders wenn die gescheiterte E-Mail von einem echten Nutzer stammte (siehe forensische Berichte und Datenschutz).

Eine weitere Realität: Die meisten großen Anbieter (Google, Microsoft, Yahoo) verschicken keine RUFs mehr. Die Unterstützung forensischer Berichte ist weit weniger universell als die von RUAs. In der Praxis erhältst du RUAs von fast allen, RUFs nur von wenigen Akteuren.

RUA und RUF im DMARC-Eintrag konfigurieren

Beide Adressen werden in deinem _dmarc-Eintrag konfiguriert:

_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ton-domaine.fr;
   ruf=mailto:ruf@ton-domaine.fr; fo=1"

• rua=: Die Adresse, an der du die aggregierten Berichte empfangen willst. Du kannst mehrere angeben, 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.

Wenn du keine RUFs willst (aus Compliance-Gründen oder weil du sie nicht auswertest), lass einfach ruf= und fo= weg. Der aggregierte Bericht (RUA) ist der eigentliche Wert — der RUF ist eine Ergänzung für spezifische Diagnosen.

Was du in der Praxis tun solltest

Für die überwiegende Mehrheit der Deployments reichen die RUAs völlig aus. Sie geben dir eine vollständige Sicht darauf, wer in deinem Namen versendet, mit welchen Ergebnissen, von welchen IPs — genau das, was du brauchst, um in Richtung p=reject voranzukommen. Sie regelmäßig zu analysieren (oder von einem Tool oder von Thomas analysieren zu lassen) sagt dir, welche Quellen du korrigieren musst, in welcher Reihenfolge und wann du bereit bist, deine Policy zu verschärfen.

RUFs sind nützlich, wenn du ein sehr spezifisches Problem diagnostizieren musst: ein bestimmter Nachrichtentyp, der scheitert, eine unbekannte Quelle, die in deinem Namen versendet. Aber öffne sie nur in Kenntnis ihres potenziell sensiblen Inhalts und gib sie vor allem nicht an Dritte weiter, ohne zu prüfen, was sie enthalten.

Der richtige Reflex zum Start: Konfiguriere ein rua= zu einem dedizierten Postfach (oder einer DMARC-Plattform), lass die Berichte ein paar Tage eintrudeln und lies sie. Die Diagnose, wer in deinem Namen 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. Wenn du E-Mails in großem Volumen versendest, hast du schnell genug Daten für eine Diagnose.

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

Häufige Fragen

Muss ich ruf= konfigurieren? Nein. Die RUAs reichen für nahezu alle Fälle. Konfiguriere ruf= nur, wenn du einen konkreten forensischen Diagnosebedarf hast und die Datenschutzimplikationen abgewogen hast.

Wie lange dauert es, bis ich Berichte bekomme? Einige Stunden bis 24 Stunden nach Veröffentlichung deines 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.domaine-externe.fr autorisiert sein (damit nicht jeder seine Berichte an ein beliebiges Postfach schicken kann). Liegt die Adresse in deiner eigenen Domain, geschieht das automatisch.

Wie die Berichte dir helfen, zu p=reject voranzukommen

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

Zu Beginn, mit p=none, erhältst du Berichte, ohne dass irgendetwas blockiert wird. Das ist die Beobachtungsphase: Du entdeckst, welche IPs in deinem Namen versenden, welche durchkommen, welche scheitern und welche du gar nicht wiedererkannt hast. Du korrigierst die legitimen Quellen eine nach der anderen — indem du DKIM aktivierst, SPF ausrichtest, unbekannte Quellen ausschließt — und überwachst die Berichte, um zu bestätigen, dass jede Korrektur gegriffen hat.

Sobald deine Berichte zeigen, dass die große Mehrheit deiner legitimen Quellen durchkommt (typischerweise >95 %), gehst du zu p=quarantine über. Dieselbe Logik gilt: Überwache die Berichte, prüfe, dass keine legitime Quelle betroffen ist, feile nach. Dann steigst du auf p=reject. Bei jedem Schritt sind die RUA-Berichte dein Messinstrument: Sie sagen dir, wo du stehst, 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 IP, die du nicht wiedererkennst, ist es vielleicht Fälschung (jemand versucht, deine Domain zu usurpieren) — und dein p=reject verhindert es. Handelt es sich um eine IP, die du als schlecht konfigurierte legitime Quelle erkennst, ist das etwas zum Korrigieren. Die beiden zu unterscheiden ist der Kern der Interpretationsarbeit, die die Berichte erst ermöglichen.

Die Quellen in deinen Berichten identifizieren

Ein Rohbericht gibt dir eine IP. Ein gut ausgewerteter Bericht sagt dir, 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), aber du kannst es für ein paar Schlüssel-IPs auch manuell über Reverse-Lookup-Tools machen.

Die wiederkehrenden IPs mit dkim=pass, spf=pass, dmarc=pass sind deine gut konfigurierten Quellen — fass sie nicht an. Die wiederkehrenden IPs mit Fehlschlägen auf einer Quelle, die du wiedererkennst, sind deine Korrekturprioritäten. Die unbekannten IPs mit dmarc=fail sind entweder Fälschung (keine Aktion deinerseits, lass p=reject seine Arbeit tun) 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 wenn du ruf= und fo=1 in deinem Eintrag konfigurierst, bekommst du von den großen Anbietern nichts. Du erhältst RUFs höchstens von einigen kleineren, oft europäischen Betreibern, 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. Verlass dich also nicht auf forensische Berichte, um dein Deployment voranzubringen — sie sind ein Bonus, kein Fundament.

Ein pragmatischer Startablauf

Wenn du bei null anfängst, ist der einfachste und sicherste Ablauf dieser. Veröffentliche zuerst einen DMARC-Eintrag mit p=none und einem rua=, das auf ein dediziertes Postfach oder eine Analyse-Plattform zeigt — keine ruf=, keine fo=. Lass die Berichte zwei bis drei Wochen eintrudeln, ohne etwas zu blockieren. In dieser Zeit sammelst du eine repräsentative Sicht auf alle deine Versandquellen, denn die großen Provider decken den Großteil deines Traffics ab. Wertest du diese Berichte aus, hast du deine vollständige Quellenkarte, ohne je einen forensischen Bericht gebraucht zu haben. Erst wenn du auf ein sehr spezifisches Problem stößt, das die aggregierten Daten nicht erklären, kommt die Frage nach RUFs überhaupt auf — und selbst dann wägst du zuerst die Datenschutzimplikationen ab. In der überwiegenden Mehrheit der Fälle wirst du feststellen, dass die RUA-Berichte allein dich bis p=reject tragen.

Lass Thomas deine Berichte für dich lesen

RUA-Berichte zu empfangen ist eine Sache; sie auszuwerten eine andere. Thomas, dein virtueller CISO, liest deine Berichte an deiner Stelle, sagt dir, welche Quellen durchkommen, welche scheitern, warum und in welcher Reihenfolge du sie korrigierst. Er verwandelt rohes XML in einen klaren Aktionsplan in Richtung p=reject.

Analysiere deine Domain kostenlos → oder erstelle ein Konto für automatisch entschlüsselte DMARC-Berichte.