ri= in DMARC: Häufigkeit der Berichte und was sie wirklich bewirkt

ri=86400   → tägliche Berichte (Standard, empfohlen)
ri=3600    → stündliche Berichte (falls der Provider es unterstützt)
ri=604800  → wöchentliche Berichte

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

Warum 86400 (24 Std.) der Wert ist, den man sich merkt

Für nahezu alle Kontexte ist ri=86400 der zu verwendende Wert — oder ri= fällt einfach weg, was aufs Gleiche hinausläuft (der Standardwert ist 86400). Und zwar aus folgenden Gründen:

• Es ist der Takt, den die Provider tatsächlich anwenden.
• Ein täglicher Bericht liefert eine handhabbare Informationsmenge: Die Trends des Tages werden sichtbar, eine neue Quelle oder ein anormaler Ausschlag fällt innerhalb von höchstens 24 Stunden auf.
• Ein häufigerer Bericht liefert keine zusätzlichen nützlichen Informationen — nur mehr Rauschen, falls manche Akteure ihn respektieren.
• Ein wöchentlicher Bericht (ri=604800) verzögert die Erkennung eines Problems zu stark.

Bei einer kritischen Domain, bei der ein Sicherheitsvorfall in den ersten 24 Stunden große Auswirkungen haben könnte, ist die Überwachung der Aktivität in Echtzeit über ein DMARC-Werkzeug der bessere Weg, statt zu versuchen, ri= zu ändern — das ist wirksamer.

Die Verzögerung zwischen Versand und Empfang der Berichte

Ein oft missverstandener Punkt: Der Bericht, der um 8 Uhr morgens eintrifft, deckt den Zeitraum des Vortags ab, nicht des laufenden Tages. Es gibt immer eine Verzögerung zwischen dem Moment, in dem die Nachrichten ausgewertet wurden, und dem Moment, in dem der Bericht ankommt. In der Praxis:

• Der Berichtszeitraum deckt in der Regel 00:00→23:59 UTC ab.
• Der Bericht wird in den ersten Stunden danach erzeugt und versendet (oft zwischen 3 und 9 Uhr UTC).
• Er trifft je nach E-Mail-Routing einige Minuten bis einige Stunden später ein.

Konkret: Was gestern passiert ist, sagt der Bericht vom nächsten Morgen. Für Vorfälle des laufenden Tages heißt es auf den Bericht vom Folgetag warten. Deshalb ist eine DMARC-Plattform mit kontinuierlicher Sicht nützlicher als eine manuelle Überwachung der Berichte.

Und wenn ich gar keinen Bericht erhalte?

Wenn nach einigen Tagen kein Bericht eintrifft, ist der Reihe nach zu prüfen:

1. Ist der DMARC-Eintrag veröffentlicht? (dig TXT _dmarc.beispiel.de muss den Eintrag zurückgeben).
2. Ist die rua=-Adresse korrekt? Ein Tippfehler, ein nicht existierendes Postfach oder eine falsche Domain reicht, um alles zu verlieren.
3. Falls rua= auf eine externe Domain zeigt (zum Beispiel eine DMARC-Plattform), muss diese Domain einen DNS-Autorisierungseintrag besitzen (_dmarc.externe-domain.de TXT "v=DMARC1").
4. Versendet die Domain überhaupt Mail? Eine Domain, die nichts versendet, erzeugt keinen Bericht — das ist normal.
5. Landen die Berichte nicht im Spam? Der Spam-Ordner der Empfängeradresse gibt Aufschluss.

ri= in DMARCbis (RFC 9989)

In der neuen Version von DMARC (DMARCbis) bleibt der Parameter ri= erhalten und behält dieselbe Bedeutung. Die wesentlichen Änderungen von DMARCbis betreffen andere Tags (pct entfernt, np und t hinzugefügt) — nicht ri=. Bei einer Migration auf DMARCbis (siehe zu diesem neuen Standard migrieren) bleibt der ri=-Wert ohne Änderung gültig.

Häufige Fragen

Muss ich ri= in meinen Eintrag aufnehmen? Nein, es ist optional. Der Standardwert ist 86400, was für die meisten Fälle der richtige Wert ist. Wer es explizit machen will, fügt ri=86400 hinzu; ansonsten bleibt es weg.

Kann ich stündliche Berichte anfordern? Technisch ja (ri=3600), aber nahezu alle Provider ignorieren das und senden trotzdem täglich. Auf eine Häufigkeit unter 24 Stunden ist kein Verlass.

Gilt ri= auch für RUF? Nein. ri= betrifft die aggregierten Berichte (RUA). Die forensischen Berichte (RUF) werden ereignisbasiert ausgelöst (eine Nachricht, die scheitert), nicht in Intervallen.

Was passiert, wenn ich von mehreren Providern zu unterschiedlichen Zeiten Berichte erhalte? Das ist normal — jeder Provider erzeugt und versendet seinen Bericht zu seinem eigenen Zeitpunkt. Der Gmail-Bericht kann um 6 Uhr eintreffen und der Microsoft-Bericht um 14 Uhr, beide für denselben Zeitraum. DMARC-Werkzeuge aggregieren sie automatisch.

Kann ein Bericht einen anderen Zeitraum als 24 Stunden abdecken? Ja, besonders beim Start: Wird der DMARC-Eintrag um 15 Uhr veröffentlicht, deckt der erste Bericht womöglich nur die verbleibenden 9 Stunden des Tages ab. Die folgenden Berichte kehren zu 24 Stunden zurück.

Wie decken die Berichte mehrere Zeitzonen ab? Die Berichte verwenden Unix-Timestamps (UTC) für die date_range. Der Provider entscheidet über den abgedeckten Zeitraum, in der Regel 00:00→23:59 UTC. Findet die Aktivität hauptsächlich in einer anderen Zeitzone statt (UTC+2, UTC-8…), können die Berichte einen Arbeitstag in zwei Berichtszeiträume zerschneiden. Ein Detail, das bei der Analyse eines Vorfalls an einem bestimmten Tag zählt.

Haben DMARC-Berichte eine Gültigkeitsdauer? Nein, sie verfallen nicht — aber ihr Wert nimmt mit der Zeit ab. Ein sechs Monate alter Bericht ist nur nützlich, um die Entwicklung einer Konfiguration zu vergleichen, nicht für die Diagnose der aktuellen Lage. Die laufende Diagnose stützt sich auf die letzten 30 Tage, die lange Historie bleibt den Trends vorbehalten.

Was wirklich zu überwachen ist (und wie oft)

Die eigentliche Frage lautet nicht „wie oft erhalte ich Berichte?", sondern „wie oft lese ich sie?". Und hier hängt die richtige Antwort von der DMARC-Rollout-Phase ab.

In der Beobachtungsphase (Policy p=none): Die Berichte werden wöchentlich gelesen. Es besteht kein Unterbrechungsrisiko, die Änderungen sind langsam (Quellen zu identifizieren und zu korrigieren braucht Zeit), und eine wöchentliche Durchsicht reicht, um die Fortschritte zu verfolgen. In der Übergangsphase (p=quarantine): In den ersten Wochen gehören die Berichte täglich gelesen, oder es werden Alarme eingerichtet. Hier lässt sich unbeabsichtigt ein legitimer Fluss blockieren — das muss schnell auffallen. Sobald die Quarantäne seit einigen Wochen stabil ist, genügt wieder ein wöchentlicher Rhythmus. In der stabilen Phase (p=reject): Eine monatliche Durchsicht reicht oft aus, ergänzt durch automatische Alarme für Anomalien (unbekannte neue IP, plötzlicher Anstieg von Fehlern). Das Monitoring wird zur Wartung, nicht zur Untersuchung.

ri= ändert nichts an dieser Logik — die Berichte kommen in allen Fällen täglich. Es ist der Takt des Lesens und Auswertens, der zählt, nicht der des Empfangs.

Berichte und Sicherheitsaudit

Für Organisationen, die Audits unterliegen (ISO 27001, NIS2, Bankensektor…), stellen DMARC-Berichte einen Nachweis der Überwachung dar. Eine Historie der Berichte aufzubewahren — sei sie auch nur teilweise — erlaubt es, bei einem Audit zu zeigen, dass die DMARC-Policy überwacht wird und dass Anomalien erkannt und behandelt werden. Das ist die gleiche Logik wie bei Firewall-Logs: Ihr Wert liegt nicht im täglichen Lesen, sondern in der Fähigkeit zu beweisen, dass überwacht und dass auch reagiert wird. Eine DMARC-Plattform, die die Historie der Berichte aufbewahrt und die Alarme protokolliert, erfüllt diese Rolle, ohne dass Hunderte von XML-Dateien zu archivieren wären. Ist diese Audit-Dimension auferlegt, gehört geprüft, dass das gewählte Werkzeug eine lange Historie (mindestens 90 Tage) und Exporte für den Bedarf der Konformität bietet.

Der häufigste Irrtum: ri= mit der Reaktionszeit verwechseln

Viele Administratoren stellen ri=3600, weil sie glauben, damit schneller auf einen Vorfall reagieren zu können. Das ist ein Trugschluss, und er verdient eine klare Widerlegung. Die Reaktionszeit auf einen Vorfall hängt von zwei Dingen ab, und ri= ist keines davon. Erstens, wie schnell der Provider seinen Bericht nach dem Ende des beobachteten Zeitraums erzeugt und versendet — das entscheidet nicht die Absenderseite, sondern Gmail, Microsoft oder Yahoo, und diese arbeiten in ihrem eigenen Takt. Zweitens, wie schnell der eingegangene Bericht gelesen und ausgewertet wird — das entscheidet die Absenderseite, aber nicht über ein DNS-Tag. Selbst im theoretischen Idealfall, in dem ein Provider ri=3600 respektierte, käme ein Bericht an, der eine Stunde Aktivität abdeckt, aber erst mehrere Stunden später eintrifft, weil die Erzeugung und der Versand Zeit brauchen. Die Latenz zwischen Ereignis und Kenntnisnahme verkürzt sich also nicht wirklich.

Wer eine echte Frühwarnung will, findet den richtigen Hebel nicht in ri=, sondern in einer kontinuierlichen Auswertung der eingehenden Berichte plus einer Alarmierung auf definierte Auslöser: eine unbekannte neue Versand-IP, ein plötzlicher Einbruch der Alignment-Rate, eine Quelle, die aufhört durchzukommen. Genau das ist der Unterschied zwischen einem passiven Archiv von XML-Dateien und einer Plattform, die die Daten laufend beobachtet. Das Tag ri= gehört zur ersten Welt — der DNS-Konfiguration — während die Reaktionsfähigkeit zur zweiten gehört — der Auswertung. Die beiden zu verwechseln führt dazu, an der falschen Schraube zu drehen und sich in falscher Sicherheit zu wiegen, weil man einen niedrigen Intervallwert gesetzt hat, den ohnehin niemand respektiert.

Thomas überwacht die Häufigkeit

Der eigentliche Wert liegt nicht in der Häufigkeit der Berichte, sondern in dem, was daraus gemacht wird. Thomas, der virtuelle CISO, überwacht die Berichte stellvertretend, alarmiert, wenn etwas Ungewöhnliches auftaucht — eine neue IP, ein Anstieg von Fehlern, eine Quelle, die nicht mehr durchkommt — und sagt, was zu tun ist, nicht nur, was zu betrachten ist.

Die Domain kostenlos analysieren oder ein Konto erstellen für eine unterbrechungsfreie DMARC-Überwachung.