Zusammenfassung

  • RFC 9990 legt fest, wie ein Mail Receiver Authentifizierungsergebnisse, DMARC-Ausrichtung, bewertete Disposition, lokale Ausnahmen, Quellen und Mengen für einen Zeitraum zusammenfasst.
  • Der Bericht ist kein Ereignisjournal pro Nachricht. Ein Zeitraum kann mehrere Richtlinien mischen, Teilüberlappungen lassen sich nicht sicher zerlegen, und die RFC warnt ausdrücklich vor gefälschten Berichtsdaten.
  • Daniel Kade schlägt einen datensparsamen Aggregat-Nutzungsbeleg vor: Er verbindet Generatoridentität, Zeitraum, Richtlinienepoche, Dateidigest, Dublettenentscheidung und Folgemaßnahme, ohne Inhalte oder persönliche Adressen zu speichern.

Eine saubere Summe kann auf einer unbekannten Abdeckung beruhen

DMARC-Aggregate zeigen dem Domaininhaber, was außerhalb der eigenen Systeme sichtbar wird. Sie machen unbekannte Versandquellen, fehlerhafte DKIM-Rotationen oder Ausrichtungsprobleme bei indirekten Wegen erkennbar. Ohne diese Rückmeldung müsste die Organisation ihre Wirkung aus der eigenen Konfiguration erraten.

Die Zahlen stammen jedoch nur von Empfängern, die Berichte erzeugt und erfolgreich zugestellt haben. Andere nehmen nicht teil, liefern später, halten Daten für einen erneuten Versuch zurück oder verwerfen sie. Ein fehlender Bericht bedeutet nicht, dass kein Verkehr stattfand.

Aggregation ist deshalb nicht minderwertig. Sie ist die notwendige Verdichtung für Datenschutz und Internetmaßstab. Falsch wird es erst, wenn die Benutzeroberfläche die Reporterpopulation entfernt und die verbleibende Summe als vollständigen Mailstrom bezeichnet.

Was der standardisierte Bericht aussagt

RFC 9990 erschien im Mai 2026 als IETF-Standards-Track-Dokument. Zusammen mit den neuen DMARC-Spezifikationen ersetzt sie den Berichtsteil von RFC 7489. Der Domain Owner veröffentlicht Ziele, der Mail Receiver bewertet Nachrichten, erstellt XML und versucht die Zustellung an zulässige Empfänger.

Metadaten nennen Organisation, Report-ID und UTC-Zeitraum. policy_published beschreibt die beobachtete Richtlinienkonfiguration. Eine Zeile verbindet Quell-IP, Anzahl, bewertete Disposition, Ausrichtung und Identifikatoren. DKIM- und SPF-Ergebnisse bleiben getrennt. Lokale Abweichungen können als lokale Richtlinie, Mailingliste, Testmodus, vertrauenswürdiger Weiterleiter oder anderer Grund erscheinen.

Gezählt werden empfangene Nachrichten, auch wenn ein anderes Filtersystem sie später blockiert. Die DMARC-Disposition ist damit kein Zustellnachweis und keine Aussage über den Posteingang. Sie ist ein Ergebnis innerhalb der Empfängersteuerung.

Verdichtung löscht Ereignisverbindungen

Eine Zeile kann tausende Nachrichten mit derselben Kombination darstellen. Sie liefert Muster, aber keine tausend stabilen Ereignis-IDs. Reihenfolge, nachgelagerte Filterentscheidung und endgültige Platzierung lassen sich nicht für jede Einheit rekonstruieren.

Das ist relevant, sobald Automatisierung aus einem Ausschlag eine harte Maßnahme ableitet. Die Ursache kann ein unautorisierter Sender sein. Ebenso möglich sind ein neuer Reporter, ein verspäteter Lauf, veränderte Gruppierung oder eine überlappende Periode. Der Ausschlag darf eine Untersuchung auslösen. Er darf nicht ohne weitere Verbindung als Kausalbeweis gelten.

Das Beweisobjekt lautet: Dieser Empfänger behauptet, seine Bewertungen so zusammengefasst zu haben. Der tatsächliche Mailstrom ist ein größeres Objekt.

Eine angezeigte Richtlinie kann ein gemischtes Intervall überdecken

Ändert sich die DMARC-Richtlinie innerhalb eines Berichtszeitraums, sehen Empfänger den DNS-Zustand zu unterschiedlichen Zeiten. RFC 9990 erlaubt getrennte Berichte pro Konfiguration. Sie erlaubt auch einen Bericht, der Entscheidungen nach alter und neuer Richtlinie mischt, obwohl nur ein policy_published enthalten ist.

Lückenlose Übergangsüberwachung bei jedem Empfänger wäre im Internetmaßstab teuer. Deshalb müssen Report Consumers und Domain Owners gemischte Berichte erwarten. Der operative Kompromiss begrenzt zugleich die Aussagekraft des Richtlinienfeldes.

Wechselt eine Domain mittags vom Beobachten zur Ablehnung, kann der Tagesbericht die Endkonfiguration zeigen und dennoch Vormittagsentscheidungen enthalten. Ohne Epochenbindung ist „gemischt“ oder „unbekannt“ genauer als eine rückwirkende Zuordnung aller Zeilen.

Authentifizierter Transport beglaubigt nicht jede Zeile

Die Mail mit dem Feedback muss einen ausgerichteten DMARC-Pass erzielen. Sicherer Transport wird empfohlen. Ein externes Ziel muss per DNS seine Bereitschaft bestätigen; andernfalls wird die URI verworfen.

Diese Kontrollen begrenzen Absenderfälschung und verhindern, dass Dritte unfreiwillig mit Berichten geflutet werden. Doch Domainausrichtung der Transportmail, Zustimmung des Ziels, Dateiintegrität und Wahrheit der Beobachtungen sind unterschiedliche Aussagen.

RFC 9990 weist darauf hin, dass Berichtsdaten gefälscht und massenhaft eingespeist werden können, um Richtlinien oder Architekturentscheidungen zu beeinflussen. Bekannte Empfänger bleiben wertvolle Quellen. Ihr Vertrauensgrund und die zulässige Folgerung sollten dennoch sichtbar sein.

Report-ID schafft Identität, nicht Mengenexklusivität

Eine Report-ID muss unter Berichten an dieselbe Domain eindeutig sein. Eine erneute Zustellung nutzt denselben Dateinamen. So kann der Verbraucher Wiederholungen erkennen und idempotent verarbeiten.

Unterschiedliche IDs schließen Überschneidungen nicht aus. Der RFC überlässt dem Verbraucher, doppelte Daten zurückzuweisen, zu verwerfen, zu prüfen oder anzunehmen. Bei teilweise überlappenden Intervallen gibt es keine klare Methode, den Effekt herauszulösen; der gesamte Datensatz kann angenommen oder verworfen werden müssen.

Die Entscheidung gehört in die Beweiskette. Wer alle eindeutigen IDs addiert, hat nicht nur programmiert, sondern eine Annahme über die Population getroffen.

Externe Zustimmung ist keine Analysezertifizierung

Spezialisierte Dienstleister können Berichte für Domaininhaber empfangen. Der DNS-Nachweis bestätigt ihre Bereitschaft und verhindert Missbrauch. Er kann entzogen werden, wirkt wegen Caches aber nicht sofort.

Die Bestätigung bewertet weder Parser noch Normalisierung, Zuordnung, Aufbewahrung oder Handlungsempfehlung. Der Domaininhaber muss weiterhin verstehen, welche Dateien eingingen, welche Zeilen verworfen wurden, wie Überschneidungen behandelt und welche Schwellen angewandt wurden.

Verarbeitung lässt sich auslagern. Verantwortung für die Bedeutung der Evidenz nicht.

Nachvollziehbarkeit ohne Wiederaufbau persönlicher Kommunikation

Aggregate enthalten keine Nachrichteninhalte oder individuellen Nutzeradressen. Verkehrsmetadaten können trotzdem sensibel sein, besonders bei Vermittlern und Public-Suffix-Berichten. Ein zusätzlicher Auditpfad darf die Datenminimierung nicht aufheben.

Dateidigest, Generator, Richtliniendomain, Zeitraum, Epoche, normalisierter Datensatz und Entscheidung reichen für die Herkunftskette. Nachrichtentexte, Empfänger und Postfachplatzierung bleiben draußen.

GZIP und XML sind außerdem nicht vertrauenswürdige Eingaben. Ressourcenerschöpfung beim Entpacken oder Parsen ist ein dokumentiertes Risiko. Syntaktische Lesbarkeit und beweisbezogene Annahme brauchen getrennte Zustände.

Der Aggregat-Nutzungsbeleg

Daniel Kade schlägt einen kleinen Beleg vor, sobald ein Aggregat eine konkrete Entscheidung trägt. Er ist keine Forderung von RFC 9990.

Der Beleg bindet Report-ID, Originaldateiname, Digest, Größe, Empfangszeit, Transportergebnis und Identitätsgrundlage des Generators. Dann folgen Richtliniendomain, UTC-Grenzen, Schemaversion und der Status vollständig, verspätet oder teilweise.

Für die Richtlinienepoche werden policy_published und die Einordnung eindeutig, gemischt oder unbekannt gespeichert. Verwandte Berichte und Zeitüberschneidungen werden verknüpft; Ersetzen, Zusammenführen, Zurückweisen, Annehmen oder Quarantäne erhalten Regel und Verantwortlichen.

Parser- und Normalisierungsversion, Digest der akzeptierten Zeilen, Zahl der Ablehnungen, ignorierte Erweiterungen und Anomalieprüfungen machen die Transformation reproduzierbar. Abschließend nennt der Beleg die Nutzung: untersuchen, Absender kontaktieren, Schlüssel rotieren, Richtlinie ändern, halten, zurückrollen oder ersetzen.

Damit wird nicht der Mailstrom rekonstruiert. Nachvollziehbar wird, warum ein Aggregat Entscheidungsmacht erhielt.

Evidenzgrenzen

Die Quellen belegen Felder, gemischte Richtlinien, Überschneidungsprobleme, externe Autorisierung, Datenschutzgrenzen und die Fälschungswarnung. Sie belegen keine Verbreitungsquote, kein Fehlverhalten eines genannten Empfängers und keine Qualität eines Produkts.

Dieser Artikel erklärt den Bericht nicht zur bloßen Meinung. Er ist strukturierte Evidenz eines operativen Beobachters. Vor einer folgenreichen Handlung müssen Beobachter, Zeitraum, Epoche, Dublettenbehandlung, Transformation und Entscheidungsautorität verbunden bleiben.

Quellen