DMARC-Forensikberichte (RUF) und Datenschutz: Was zu wissen ist

Von Thomas · virtueller CISO · 2026-07-18

Forensikberichte im DMARC-Umfeld — die RUF — sind der granularste Berichtstyp: Sie werden bei jedem Authentifizierungsfehler ausgelöst und können Informationen über die fehlgeschlagene Nachricht enthalten, teils bis hin zu den vollständigen Headern. Diese Detailtiefe ist nützlich, um konkrete Probleme zu diagnostizieren, wirft aber ernste Fragen zum Datenschutz und zur DSGVO-Konformität auf. Dieser Leitfaden erklärt, was RUF enthalten, warum die meisten großen Provider aufgehört haben, sie zu versenden, und wie sich das Thema angehen lässt, falls sie doch genutzt werden.

Was ein RUF-Bericht enthält

Anders als die aggregierten Berichte (RUA), die nur Statistiken und IPs enthalten, wird ein RUF-Bericht durch eine einzelne Nachricht ausgelöst, die die DMARC-Authentifizierung nicht bestanden hat. Sein genauer Inhalt hängt von der Implementierung des versendenden Providers ab, kann aber Folgendes umfassen:

Die vollständigen Header der Nachricht: From:, To:, Subject:, Message-ID:, die Routing-Header, die DKIM-Header usw.
Die Quell-IP und die Routing-Informationen.
Das Authentifizierungsergebnis (welcher Check fehlgeschlagen ist und warum).
In manchen Fällen, je nach Implementierung: einen Auszug aus dem Nachrichtentext.

Konkret heißt das: Versendet ein legitimer Nutzer eine E-Mail von der Domain über eine nicht konfigurierte Route (ein Client, der von einem Drittserver aus antwortet, ein Mitarbeiter, der eine schlecht konfigurierte Mobile-App nutzt), kann diese Nachricht einen RUF auslösen, der seine E-Mail-Adresse, den Betreff seiner Nachricht und die vollständigen Header enthält. Das sind personenbezogene Daten im Sinne der DSGVO.

Warum die meisten großen Provider RUF eingestellt haben

Die Spannung zwischen dem Nutzen von RUF und ihren datenschutzrechtlichen Implikationen hat die großen Akteure dazu gebracht, ihren Versand einzuschränken oder ganz einzustellen. Google hat den Versand von RUF 2023 eingestellt. Microsoft versendet sie nur unter sehr eingeschränkten Bedingungen. Yahoo hat seine Nutzung schrittweise reduziert.

Die genannten Gründe sind vielfältig: das Risiko eines versehentlichen Abflusses privater Informationen, Unsicherheit über die DSGVO-/CCPA-Konformität und ein Rückbau des operativen Supports. Das praktische Ergebnis: Ein ruf= im DMARC-Eintrag bringt RUF von einigen kleineren Akteuren, aber nicht von den großen Postfächern (Gmail, Outlook). Der diagnostische Wert ist daher in den meisten Kontexten begrenzt.

DSGVO-Implikationen

Fällt die Entscheidung, RUF zu empfangen und auszuwerten, sind das die zu bedenkenden Compliance-Punkte:

Rechtsgrundlage. E-Mail-Header enthalten personenbezogene Daten (E-Mail-Adressen, Nachrichten-Metadaten). Die Verarbeitung dieser Daten braucht eine Rechtsgrundlage im Sinne der DSGVO — typischerweise das berechtigte Interesse (Sicherheit des eigenen Informationssystems), das im DSGVO-Verzeichnis zu dokumentieren ist.

Datenminimierung. RUF sind ausschließlich für die Sicherheitsdiagnose zu nutzen, nicht für andere Zwecke. Ihre Aufbewahrung ist auf das Notwendige zu beschränken (wenige Tage bis wenige Wochen reichen für eine Diagnose).

Übermittlung an Dritte. Werden RUF an eine externe DMARC-Plattform übermittelt, wird diese Plattform zum Auftragsverarbeiter im Sinne der DSGVO — sicherzustellen ist, dass ein AV-Vertrag (Auftragsverarbeitungsvertrag) besteht und die Plattform die eigenen Sicherheitsanforderungen erfüllt.

DSGVO-Verzeichnis. Werden RUF verarbeitet, gehört diese Verarbeitung ins DSGVO-Verzeichnis (Art. 30): Zweck (E-Mail-Sicherheit), Datenkategorie (Header, E-Mail-Adressen), Aufbewahrungsdauer, Rechtsgrundlage.

Verschlüsselung und Isolierung. RUF dürfen nicht in einem geteilten Postfach landen oder für Personen zugänglich sein, die sie nicht einsehen müssen. Sie gehören in ein dediziertes Postfach mit eingeschränktem Zugriff.

Die Frage nach dem tatsächlichen Nutzen

Angesichts der aktuellen Einschränkungen (wenige Provider, die RUF versenden) und der DSGVO-Auflagen stellt sich die Frage: Sind RUF den Aufwand wert? Für die große Mehrheit der Deployments lautet die Antwort nein. Die aggregierten Berichte (RUA) liefern alles Nötige, um die Quellen zu identifizieren und zu korrigieren: IPs, Authentifizierungsergebnisse, Volumen. RUF liefern ein Detail zu einer einzelnen Nachricht, das sich oft ohnehin nicht auswerten lässt (der betreffende Provider versendet vielleicht gar keine).

Die Fälle, in denen RUF einen echten Nutzen behalten: wenn ein bestimmter Typ fehlschlagender Nachrichten zu diagnostizieren ist und bestätigt wurde, dass der betreffende Provider RUF versendet; oder in einem Kontext, in dem die Mail-Infrastruktur Ende-zu-Ende kontrolliert wird und sich RUF an sich selbst senden lassen.

Wie man ruf= konfiguriert (oder nicht)

Fällt die Entscheidung gegen RUF — die Empfehlung für die meisten Fälle — bleiben ruf= und fo= einfach aus dem Eintrag weg. Der DMARC-Eintrag funktioniert einwandfrei mit nur rua=:

_dmarc.beispiel.de.  IN TXT
  "v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de"

Fällt die Entscheidung für RUF, kommt hinzu:

ruf=mailto:ruf@beispiel.de; fo=1

fo=1 erzeugt einen RUF, sobald ein Check fehlschlägt — das ist der informativste, aber auch der volumenstärkste Wert. fo=0 (Standard) erzeugt nur dann einen RUF, wenn alle Checks fehlschlagen — weniger Volumen, weniger Information.

Häufige Fragen

Versendet Google noch RUF? Nein, Google hat den Versand von Forensikberichten eingestellt. Die meisten RUF, die noch ankommen, stammen von weniger bekannten Akteuren.

Sind RUF gefährlich für den Datenschutz? Potenziell, je nach ihrem Inhalt. Sie können E-Mail-Adressen, Nachrichtenbetreffe und Versandwege offenlegen. Sie sind mit derselben Sorgfalt zu behandeln wie alle anderen sensiblen Daten.

Soll ich fo= in meinen Eintrag setzen? Nur bei konfiguriertem ruf=. Ohne ruf= hat das Tag fo= keinerlei Wirkung. Und ohne gesetztes ruf= gibt es nichts zu konfigurieren.

Kann ein DMARC-Tool von Drittanbietern meine RUF empfangen? Ja, mit einem konfigurierten ruf=mailto:adresse@drittanbieter-tool.com. Zu prüfen ist, dass das Tool einen AV-Vertrag (Auftragsverarbeitungsvertrag) unterzeichnet hat und dass seine Verarbeitungsbedingungen den eigenen DSGVO-Anforderungen entsprechen.

Wie erkenne ich, ob ich RUF erhalte? Ein Blick ins ruf=-Postfach genügt: RUF kommen mit einem anderen Betreff als RUA an, oft als MIME-Textdateien (kein XML wie die RUA, sondern message/feedback-report).

Unterliegen RUF einer spezifischen DSGVO-Aufbewahrungsfrist? Nein — es gibt keine gesetzlich vorgeschriebene Dauer für RUF als solche. In der Praxis legt die Datenminimierung (DSGVO-Prinzip) nahe, sie nur für die Dauer der Diagnose aufzubewahren, also einige Tage bis einige Wochen. Danach werden sie gelöscht oder anonymisiert. Das ist umso wichtiger bei einer Speicherung in einem geteilten E-Mail-Postfach.

Kann ich RUF deaktivieren, wenn ich sie bereits konfiguriert habe? Ja. ruf= und fo= aus dem DMARC-Eintrag entfernen — die Provider, die den Eintrag regelmäßig lesen, hören auf, RUF zu versenden. Die DNS-Propagierung greift, aber innerhalb von 24–48 Std. kommen keine neuen mehr an.

Geben RUF Zugriff auf die Nachrichten der Empfänger oder der Absender? Nur der Absender (die Nachrichten, die DMARC nicht bestanden haben, von der eigenen Domain aus oder unter dem Vorwand, von ihr zu stammen). Ein RUF enthält niemals den Inhalt einer eingehenden Nachricht, die an einen der eigenen Nutzer gerichtet ist — er betrifft die Nachrichten, die das eigene From: auf nicht konforme Weise genutzt haben, legitim oder nicht. Das ist eine wichtige Unterscheidung, um das tatsächliche Datenschutzrisiko zu bewerten: Das Risiko betrifft die Absender der eigenen Domain (die eigenen Nutzer, die über schlecht konfigurierte Wege versenden), nicht die externen Empfänger.

Die konkrete Lage 2025–2026

Die Marktrealität hat die RUF-Frage weitgehend entschieden. Seit Google 2023 den Versand eingestellt hat, ist die RUF-Abdeckung eingebrochen: Die großen Provider, die den Großteil des weltweiten E-Mail-Verkehrs abbilden, versenden sie nicht mehr. Was ein konfiguriertes ruf= heute noch einbringt, stammt hauptsächlich von kleinen Anbietern oder selbst gehosteten Servern, oft eine Minderheit des Gesamtverkehrs.

Diese betriebliche Realität macht RUF für die große Mehrheit der Deployments kaum auswertbar: Zu Nachrichten, die bei Gmail fehlschlagen (die zahlreichsten Empfänger), kommt kein RUF an, was den diagnostischen Wert begrenzt. Versendet eine Organisation hingegen hauptsächlich an interne Server (Unternehmens-Mail an andere Unternehmensserver) oder wird in einer kontrollierten Umgebung getestet, können RUF noch ihren Nutzen haben.

Ein praktischer Ablauf, falls RUF doch genutzt werden

Angenommen, die Entscheidung fällt trotz allem für RUF, weil der Kontext es rechtfertigt (kontrollierte Infrastruktur, präziser Diagnosebedarf). Dann lohnt es sich, den Ablauf sauber aufzusetzen, statt einfach ruf= an den bestehenden Eintrag anzuhängen. Zunächst ist ein dediziertes Postfach anzulegen, das ausschließlich RUF empfängt — niemals das allgemeine dmarc@-Postfach, in dem auch die RUA landen. So bleiben die sensiblen Daten getrennt und der Zugriff lässt sich eng begrenzen. Der Zugriff auf dieses Postfach geht nur an die Personen, die eine Diagnose tatsächlich durchführen, und wer Zugriff hat, wird dokumentiert.

Anschließend ist eine automatische Löschregel zu definieren: Ein RUF, der älter als die festgelegte Diagnosefrist ist (etwa sieben bis vierzehn Tage), wird ohne Rückfrage gelöscht. Diese Automatik ist wichtiger, als sie klingt — die häufigste DSGVO-Schwäche bei RUF ist nicht der Empfang selbst, sondern das unbegrenzte Ansammeln in einem vergessenen Postfach. Ein RUF, den niemand mehr ansieht, aber der zwei Jahre lang gespeichert bleibt, ist reines Risiko ohne Nutzen. Ergänzt wird das durch eine kurze Notiz im DSGVO-Verzeichnis, die genau diese Frist festhält, damit die Praxis und die Dokumentation übereinstimmen.

Schließlich ist regelmäßig zu prüfen, ob die eingehenden RUF überhaupt noch von relevanten Quellen kommen. Zeigt sich nach einigen Wochen, dass nur noch eine Handvoll kleiner Server RUF schickt und keiner davon das reale Problem betrifft, ist das ein starkes Signal, ruf= wieder zu entfernen. Die Kosten (Datenschutzrisiko, Wartung, Aufmerksamkeit) übersteigen dann klar den Nutzen.

RUF in DMARCbis (RFC 9990)

DMARCbis — die neue DMARC-Version, definiert durch die RFC 9989/9990/9991 — behandelt die Forensikberichte in der RFC 9990, getrennt von der RFC 9989, die das Protokoll selbst definiert. Die RFC 9990 erkennt die Datenschutzprobleme rund um RUF ausdrücklich an und stärkt ihre Nutzung nicht — sie stellt im Gegenteil klar, dass Implementierungen sich entscheiden KÖNNEN, sie nicht zu emittieren. Das ist eine offizielle Anerkennung des aktuellen Marktzustands. Bei einer Migration auf DMARCbis (siehe auf diesen neuen Standard migrieren) kann die RUF-Strategie unverändert bleiben oder ganz darauf verzichten.

Thomas die Berichte verwalten lassen

Ob RUA, RUF oder beide eingehen — Thomas, der virtuelle CISO, kümmert sich um das Lesen, die Diagnose und den Aktionsplan. Kein XML zu öffnen, keine E-Mails zu sortieren, keine Statistiken zu berechnen — Thomas nennt, was zählt und was zu tun ist.

Eine Domain kostenlos analysieren oder ein Konto erstellen für ein vollständiges DMARC-Management ohne Reibung.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos