Zusammenfassung

  • RFC 9991 definiert detaillierte DMARC-Fehlerberichte über eine einzelne fehlgeschlagene Nachricht oder eine Gruppe ähnlicher Fehler. Sie können zeitnah eintreffen und erheblich sensibleres Material als ein Aggregat enthalten.
  • Mit ruf und fo äußert der Domaininhaber einen Wunsch. Der Mail-Empfänger entscheidet weiterhin nach eigener Richtlinie, Fehlerlage, Datenschutz und Sicherheitsfähigkeit, welche Berichte er überhaupt versendet.
  • Daniel Kade schlägt einen zweckgebundenen Offenlegungsbeleg vor. Er hält Auswahl, Schwärzung, Gruppierung, Begrenzung, Transport, Zugriff und Löschung fest, ohne Nachrichtentext, Adressen, Zugangsdaten oder Schadinhalt zu speichern.

Die Diagnoseprobe, die selbst zum Vorfall wird

Ein Authentifizierungsteam beobachtet plötzlich fehlschlagende DKIM-Ausrichtung. Die aggregierte Zeile zeigt Quelle, Ergebnis und Zahl, aber nicht, ob ein falscher Selektor, eine Veränderung durch einen Mittler, ein unbefugter Absender oder eine vorübergehende Prüfungsstörung ursächlich war. Ein originaler Header-Ausschnitt könnte die Frage in Minuten beantworten.

Derselbe Ausschnitt kann jedoch einen Empfänger, einen internen Host, einen Weiterleitungspfad, eine Listenmitgliedschaft oder eine dem Absender unbekannte Beziehung offenlegen. Mit dem Nachrichtentext reisen womöglich Personalentscheidungen, Termine, Produktpläne, Zugangsdaten, Tracking-Links und gefährliche Anhänge. Der höchste Diagnosewert und der höchste Offenlegungsschaden können in denselben Bytes liegen.

Die bequeme Verwaltungserzählung lautet: Die Domain hat angefragt, also ist der Empfänger zur Lieferung verpflichtet. RFC 9991 zieht diesen Schluss nicht. Der Standard koordiniert Interesse und Form, überträgt aber kein Eigentum an Korrespondenz, die der Anfragende vielleicht weder verschickt hat noch kannte.

Eine veröffentlichte Bitte ist keine abgeschlossene Erlaubnis

RFC 9991 erschien im Mai 2026 als Standards-Track-Spezifikation. Zusammen mit der neuen DMARC-Kernspezifikation und dem Dokument über aggregierte Berichte ersetzt er die einschlägigen Teile von RFC 7489 und aktualisiert frühere Regeln für Authentifizierungsfehlerberichte.

Der Domaininhaber veröffentlicht im DMARC Policy Record ruf-Ziele und fo-Optionen. Sie nennen gewünschte Empfänger und interessierende Fehlerbedingungen. Sie bilden keinen Befehlskanal. Die empfangende Organisation bestimmt anhand des beobachteten Fehlers, der gewünschten Option und ihrer eigenen Richtlinie, welche Berichtsarten sie versendet — falls überhaupt eine.

Mindestens drei Entscheidungen bleiben getrennt. Der Inhaber entscheidet über Anfrage und Ziel. Der Empfänger entscheidet über Offenlegung und Umfang. Der Nutzer entscheidet über Personen mit Zugriff, Auswertung, Aufbewahrung und Weitergabe. Ein erfolgreiches Prüfergebnis auf einer Stufe kann die nächste nicht bevollmächtigen.

Ein Fehlerbericht kann eine Nachricht beschreiben oder ähnliche Fälle gruppieren, nahezu sofort eintreffen und wesentlich mehr Einzelheiten als ein Aggregat tragen. Geschwindigkeit verkürzt sowohl die Reparaturzeit als auch die Zeit für Datenschutzprüfung, Zielkontrolle und Eindämmung. Gute Automatisierung bewahrt diese Entscheidungsgrenzen.

Mehr Einzelheiten bedeuten eine andere Beweisklasse

Das Abuse Reporting Format trennt lesbaren Erklärungstext, maschinenlesbare Feedback-Felder und Material der Ursprungsnachricht in verschiedene MIME-Teile. RFC 9991 ergänzt DMARC-spezifische Bedeutung, darunter Identity-Alignment, einschlägige DKIM-Angaben, SPF-DNS-Material und einen Authentifizierungsfehlertyp.

Identity-Alignment hat bewusst geringe Aussagebreite. Das Feld nennt Verfahren, denen die Authentifizierung einer ausgerichteten Identität misslang, oder none, wenn die versuchten Verfahren erfolgreich waren. Es erklärt weder die Ursache eines Signaturfehlers noch beweist es, dass der scheinbare Autor die Nachricht versandte, dass ihr Inhalt bösartig ist, eine spätere Behandlung richtig war oder die Offenlegung zulässig ist.

Originale Header oder Nachrichtentexte können Fragen beantworten, die abgeleitete Felder offenlassen. Sie bringen aber auch Tatsachen außerhalb des Diagnosezwecks ein. Nach dem Kopieren in einen Bericht erhalten diese Daten einen neuen Verwahrer, eine neue Zugriffsgruppe und eine neue Aufbewahrungsfrist. „Forensisch“ bezeichnet einen Zweck, keine unbegrenzte Datenkategorie.

Externe Autorisierung belegt Bereitschaft, keinen Datenanspruch

Ein Policy Record darf Berichte außerhalb der Organizational Domain adressieren. RFC 9991 verwendet dafür das Verfahren der externen Zielautorisierung aus dem Aggregatbericht: Das Ziel veröffentlicht DNS-Material, das seine Bereitschaft zum Empfang für die anfragende Domain zeigt. Damit kann ein Domaininhaber nicht einseitig Berichtslast auf einen unbeteiligten Dritten richten.

Diese Prüfung ist notwendig und begrenzt. Sie belegt weder die Richtigkeit jedes Berichts noch die Erforderlichkeit jedes Felds, eine rechtliche oder vertragliche Grundlage beim Nutzer oder eine kontrollierte Weiterleitung. Der Standard weist darauf hin, dass auch ein scheinbar internes Ziel nach außen weiterleiten kann. Die veröffentlichte Adresse garantiert den endgültigen Speicherort nicht.

Governance muss daher Zieleignung und Verhältnismäßigkeit der konkreten Offenlegung getrennt belegen. Die Bereitschaft, bestimmte Berichte anzunehmen, berechtigt nicht zum gesamten Inhalt, den ein Generator gerade besitzt. Werden beide Prüfungen verschmolzen, wird technische Erreichbarkeit fälschlich zu Autorität.

Nützliche Minimierung braucht Zweck und Ablaufdatum

RFC 9991 empfiehlt, Zweck und Dauer eng zu fassen, Berichts-URIs streng zu kontrollieren, Text und Header zu schwärzen und sicheren Transport einzusetzen. Er hält auch fest, dass viele große Anbieter Fehlerberichte wegen realer Datenschutzkosten einschränken oder deaktivieren.

Schwärzung ist nicht bloß Löschung. RFC 6590 beschreibt eine stabile, kollisionsresistente Umwandlung, mit der ein Nutzer erkennen kann, ob zwei verborgene Zeichenfolgen ursprünglich gleich waren. Das ermöglicht diagnostische Korrelation, erhält aber zugleich Verknüpfbarkeit. Werden Verfahren und Geheimnis lange und zweckübergreifend genutzt, wächst ein Pseudonym zu einem dauerhaften Beziehungsindex.

Eine belastbare Umsetzung hält Version und Geltungsbereich der Umwandlung fest, trennt oder rotiert Schlüssel nach Zweck und verhindert, dass Roh- und Schwärzungswerte in derselben breiten Protokollumgebung landen. Wo Korrelation nicht nötig ist, sollte kein stabiles Token aus Gewohnheit entstehen. Eine Fehlerklasse, eine einmalige Fallnummer oder kein Bericht kann genügen.

Minimierung ist gegen die konkrete Diagnosefrage zu testen. Zu wenig Entfernung lässt private Korrespondenz unnötig die Organisationsgrenze überschreiten. Zu viel macht den Bericht unbrauchbar, ohne das Risiko von Annahme, Verarbeitung und Speicherung zu beseitigen. Die richtige Lösung ist eine dokumentierte, befristete Wahl, keine universelle Feldliste.

Ratenbegrenzung macht Schweigen mehrdeutig

Fehlerberichte können als Denial-of-Service-Kanal missbraucht werden. Ein Angreifer verschickt große Mengen vorgeblich im Namen des Opferdomains und veranlasst teilnehmende Empfänger, Berichte an das Opfer oder dessen Dienstleister zu senden. RFC 9991 verlangt deshalb ausgehende Ratenbegrenzung und erlaubt, ähnliche Fälle zusammenzufassen oder Übermaß zu verwerfen. Sichtbar werden sollen unterschiedliche Fehlerbedingungen, nicht jede einzelne fehlgeschlagene Nachricht.

Der Nutzer darf den Berichtsstrom folglich nicht als vollständiges Ereignisbuch lesen. Stille kann heißen: kein qualifizierender Fehler, keine Teilnahme, lokale Datenschutzentscheidung, Gruppierung, Limit-Verwerfung, Transportproblem oder abgelaufenes Diagnosefenster. Ein Sprung kann neue Bedingungen, geänderte Berichtspolitik oder eine erzeugte Flut anzeigen.

Vor Schlüssen aus Volumen benötigt der Nutzer den erklärten Kontext für Gruppierung, Stichprobe und Limits. Der Generator wiederum kann verworfene Zahlen nach begrenztem Grund und Zeitfenster lokal festhalten, ohne ein sensibles Archiv je Nachricht zu bauen. Die Erklärung unterdrückter Berichte erfordert nicht die Speicherung ihres Inhalts.

Der Bericht bleibt nicht vertrauenswürdiger Inhalt

Weil Fehlerberichte Material aus gescheiterten Nachrichten wiedergeben, können sie Spam, Phishing, Malware, täuschende Links und Anhänge enthalten. Der Standard empfiehlt Isolation, Sandbox, Segmentierung und Zugriff ausschließlich für geschultes, autorisiertes Personal. Eine Einspeisung in normale Postfächer, Ticketvorschauen oder allgemeine Suche kann den untersuchten Angriff erst verbreiten.

DMARC-Ausrichtung des Berichtsstroms hilft, die Transportidentität an die erwartete Domain zu binden. Sie macht eingebetteten Inhalt nicht sicher, bestätigt nicht jede Behauptung in maschinenlesbaren Teilen und gewährt nicht jedem Analysten Zugriff auf die Originalnachricht. Authentifizierung, Inhaltssicherheit, Datenberechtigung und betrieblicher Zugriff bleiben getrennte Kontrollen.

Die wertvollste Automatisierung ist teilweise ablehnend: aktive Inhalte entfernen, unbekannte MIME-Strukturen verweigern, Anhänge isolieren, Entpack- und Parseraufwand deckeln und allgemeine Indexierung verhindern. Ein erfolgreicher Parser beendet nicht die Entscheidung; er eröffnet kontrollierte Verwahrung.

Ein zweckgebundener Fehleroffenlegungsbeleg

Ich schlage für jede Offenlegungspolitik und jede Ausnahmefreigabe einen kompakten Beleg vor. Das ist ein Governance-Vorschlag, keine zusätzliche IETF-Anforderung.

Der Beleg beginnt mit DMARC-Policy-Domain, Zeitpunkt und Ergebnis der DNS-Abfrage, angefragten ruf-Zielen, fo-Bedingung, Ergebnis der externen Autorisierung, Version der Empfängerrichtlinie sowie Zweck und Ablaufdatum. Er nennt Fehlerklasse und Einzel- oder Gruppenfall.

Danach führt er ausgewählte Datenkategorien auf, nicht deren Werte: abgeleitete Authentifizierungsfelder, begrenzte Trace-Header, geschwärztes Adress-Token oder eng begrenzter Ausschnitt. Er hält Schwärzungsverfahren und -version, Korrelationsbereich, Gruppierungsregel, Limit-Ergebnis, sicheren Transport und Generatorfehler fest. Auf Nutzerseite bindet er Rolle, Zugriffsgrenze, Isolation, Aufbewahrungsende und Lösch- oder Ersetzungsereignis an eine verantwortliche Entscheidung.

Der Beleg darf kein Schattenpostfach werden. Nachrichtentexte, lokale Adressteile, Empfängeradressen, Zugangsdaten, aktive Schad-URLs und Anhänge bleiben draußen. Inhaltsfingerabdrücke sind nur zulässig, wenn Zweck und Risiko sie rechtfertigen, jeweils mit engem Umfang und Ablauf.

Wenn später jemand fragt, warum diese Bytes die Grenze überschritten, lautet die Antwort nicht mehr „weil DNS darum bat“. Sie besteht aus einer überprüfbaren Kette lokaler, begrenzter Entscheidungen.

Quellen

  1. Lu Heng — Datensouveränität: technische und praktische Realität
  2. Lu Heng — Warum BTW Media existiert
  3. Lu Heng — The Policy Mirror
  4. IANA — Messaging Abuse Reporting Format Parameters
  5. Informationsseite zu RFC 9991
  6. RFC 5322 — Internet Message Format
  7. RFC 5965 — Erweiterbares Format für Mail-Feedbackberichte
  8. RFC 6590 — Schwärzung sensibler Daten in Missbrauchsberichten
  9. RFC 6591 — Berichte über Authentifizierungsfehler mit ARF
  10. RFC 6650 — Erstellung und Nutzung von Mail-Feedbackberichten
  11. RFC 7489 — DMARC
  12. RFC 9989 — DMARC
  13. RFC 9990 — DMARC-Aggregatberichte
  14. RFC 9991 — DMARC-Fehlerberichte