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.deine-domain.de.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@deine-domain.de; ri=86400"

Warum 86400 (24 Std.) der Wert ist, den du dir merken solltest

Für nahezu alle Kontexte ist ri=86400 der zu verwendende Wert — oder du lässt ri= 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: Du siehst die Trends des Tages, du erkennst eine neue Quelle oder einen anormalen Ausschlag innerhalb von höchstens 24 Stunden.
• 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.

Wenn du eine kritische Domain betreibst, bei der ein Sicherheitsvorfall in den ersten 24 Stunden große Auswirkungen haben könnte, überwache die Aktivität lieber in Echtzeit über dein DMARC-Werkzeug, statt zu versuchen, ri= zu ändern — das ist wirksamer.

Die Verzögerung zwischen Versand und Empfang der Berichte

Ein oft missverstandener Punkt: Der Bericht, den du um 8 Uhr morgens erhältst, 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 bei dir eintrifft. 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).
• Du erhältst ihn je nach E-Mail-Routing einige Minuten bis einige Stunden später.

Konkret: Wenn du wissen willst, was gestern passiert ist, wird dir der Bericht vom nächsten Morgen es sagen. Für Vorfälle des laufenden Tages musst du 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, prüfe der Reihe nach:

1. Ist der DMARC-Eintrag veröffentlicht? (dig TXT _dmarc.deine-domain.de muss deinen 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? Prüfe den Spam-Ordner der Empfängeradresse.

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=. Wenn du auf DMARCbis migrierst (siehe zu diesem neuen Standard migrieren), bleibt dein 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. Wenn du es explizit machen willst, füge ri=86400 hinzu; ansonsten lass es weg.

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

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. Du kannst den Gmail-Bericht um 6 Uhr und den Microsoft-Bericht um 14 Uhr erhalten, beide für denselben Zeitraum. DMARC-Werkzeuge aggregieren sie automatisch.

Kann ein Bericht einen anderen Zeitraum als 24 Stunden abdecken? Ja, besonders beim Start: Wenn du deinen DMARC-Eintrag um 15 Uhr veröffentlichst, 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. Wenn deine Aktivität hauptsächlich in einer anderen Zeitzone stattfindet (UTC+2, UTC-8…), können die Berichte einen Arbeitstag in zwei Berichtszeiträume zerschneiden. Ein Detail, das zählt, wenn du einen Vorfall an einem bestimmten Tag analysierst.

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. Konzentriere dich für deine laufende Diagnose auf die letzten 30 Tage und bewahre die lange Historie für Trends auf.

Was du wirklich überwachen solltest (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 deiner DMARC-Rollout-Phase ab.

In der Beobachtungsphase (Policy p=none): Lies deine Berichte wöchentlich. Du gehst kein Unterbrechungsrisiko ein, 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): Lies die Berichte in den ersten Wochen täglich oder richte Alarme ein. Hier kannst du unbeabsichtigt einen legitimen Fluss blockieren — das willst du schnell erkennen. Sobald die Quarantäne seit einigen Wochen stabil ist, kehre zu einem wöchentlichen Rhythmus zurück. 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 dir, 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 du überwachst und dass du reagierst. Eine DMARC-Plattform, die die Historie der Berichte aufbewahrt und die Alarme protokolliert, erfüllt diese Rolle, ohne dass du Hunderte von XML-Dateien archivieren musst. Wenn dir diese Audit-Dimension auferlegt ist, prüfe, dass das von dir 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 entscheidest nicht du, sondern Gmail, Microsoft oder Yahoo, und diese arbeiten in ihrem eigenen Takt. Zweitens, wie schnell du selbst den eingegangenen Bericht liest und auswertest — das entscheidest du, aber nicht über ein DNS-Tag. Selbst im theoretischen Idealfall, in dem ein Provider ri=3600 respektierte, bekämst du einen Bericht, 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.

Wenn du eine echte Frühwarnung willst, ist der richtige Hebel nicht ri=, sondern eine kontinuierliche Auswertung deiner eingehenden Berichte plus eine 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 für dich 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.

Lass Thomas die Häufigkeit für dich überwachen

Der eigentliche Wert liegt nicht in der Häufigkeit der Berichte, sondern in dem, was du daraus machst. Thomas, dein virtueller CISO, überwacht die Berichte an deiner Stelle, alarmiert dich, wenn etwas Ungewöhnliches auftaucht — eine neue IP, ein Anstieg von Fehlern, eine Quelle, die nicht mehr durchkommt — und sagt dir, was zu tun ist, nicht nur, was zu betrachten ist.

Analysiere deine Domain kostenlos oder erstelle ein Konto für eine unterbrechungsfreie DMARC-Überwachung.