DMARC-Monitoring: Berichte richtig lesen und sicher zu p=reject kommen
Mehr als die Hälfte aller Domains mit DMARC-Eintrag sammelt überhaupt keine Berichte. So funktioniert DMARC-Monitoring, so lesen Sie einen Aggregatbericht, was RFC 9990 im Jahr 2026 geändert hat und wie Sie p=reject erreichen, ohne Ihre eigene E-Mail zu blockieren.
Führen Sie dieselbe Prüfung jetzt durch — kostenlos
Geben Sie Ihre Domain ein und erhalten Sie ein 9-Punkte-Audit — DNS, SPF/DKIM/DMARC, SSL, Sicherheitsheader, Dark-Web-Exposition — in 60 Sekunden.
Keine Registrierung · <60s · DSGVO/EU-Verarbeitung
DMARC-Monitoring bedeutet, die Aggregatberichte einzusammeln und zu lesen, die E-Mail-Empfänger täglich an Ihre Domain zurücksenden. So sehen Sie genau, wer in Ihrem Namen E-Mails verschickt, bevor Sie Ihre Richtlinie auf quarantine oder reject umstellen. Aktiviert wird es durch ein rua=mailto:-Tag in Ihrem DMARC-Eintrag. Innerhalb von 24 bis 48 Stunden beginnen Anbieter wie Google, Microsoft 365 und Yahoo, Ihnen komprimierte XML-Dateien zu schicken, die jede Nachricht zusammenfassen, die Ihre Domain beansprucht hat. Diese Dateien sind der einzige Nachweis, den Sie bekommen, und ohne sie ist der Wechsel zur Durchsetzung reines Raten.
Was DMARC-Monitoring tatsächlich ist
DMARC (Domain-based Message Authentication, Reporting and Conformance) erledigt zwei Aufgaben. Die Richtlinienhälfte sagt Empfängern, was mit E-Mails geschehen soll, die die Authentifizierung nicht bestehen. Die Berichtshälfte sagt Ihnen, was die Empfänger sehen. Monitoring ist diese zweite Hälfte, und genau sie überspringen die meisten Domaininhaber.
Der Mechanismus ist unkompliziert. Wenn ein empfangender Anbieter E-Mails bewertet, die Ihre From-Domain angeben, zählt er die Ergebnisse. Am Ende jedes UTC-Tages packt er diese Zählungen in eine XML-Datei und mailt sie an die Adresse in Ihrem rua=-Tag. RFC 9990 Abschnitt 3.1.1.4 legt fest, dass der Berichtszeitraum genau einen UTC-Tag ab 00:00 UTC umfasst. Deshalb trifft Ihr erster Bericht 24 bis 48 Stunden nach der Veröffentlichung des Tags ein und nicht sofort.
Die Berichte sind gzip-komprimiert und klein. Gemessene Dateigrößen pro Anbieter lagen zwischen 3,6 kB und 4,8 kB (Google 3.962 Byte, Yahoo 4.626, Fastmail 4.839) im Datensatz von Ashiq et al., veröffentlicht auf der USENIX Security 2023. Speicherplatz ist nie das Problem. Das Volumen schon: eine stark frequentierte Domain kann Hunderte Dateien pro Tag erhalten, weshalb sie kaum jemand von Hand liest.
Mehr als die Hälfte aller DMARC-Domains fliegt blind
DMARC-Richtlinienverteilung über die 1.670.975 Domains, die einen Eintrag veröffentlichen. Quelle: DMARCguard, State of Email Authentication 2026, Scan von 5.499.028 Tranco-Domains, 27. Februar 2026.
Derselbe Scan fand, dass nur 894.057 dieser 1.670.975 Domains (53,5 %) ein rua=-Tag veröffentlichen. Die übrigen 776.918 haben eine Richtlinie und keinerlei Telemetrie.
Die Folge zeigt sich in der Verteilung oben. 57,9 % der DMARC-Domains, 967.474 Stück, stehen weiterhin auf p=none. Der reine Überwachungsmodus ist als Zwischenstation gedacht, nicht als Ziel, und der Grund, warum so viele ihn nie verlassen, ist einfach: ohne Berichte gibt es keine Grundlage für die Entscheidung.
Das Risiko ist nicht theoretisch. Das Internet Crime Complaint Center des FBI verzeichnete in seinem Jahresbericht 2024 Schäden von 2,77 Milliarden US-Dollar durch Business Email Compromise bei 21.442 Anzeigen. Auf der anderen Seite der Waagschale: nachdem Google und Yahoo im Februar 2024 Authentifizierungsanforderungen für Massenversender durchgesetzt hatten, meldete Gmail 265 Milliarden weniger nicht authentifizierte Nachrichten in jenem Jahr (Neil Kumaran, Group Product Manager, Gmail Security and Trust, Oktober 2024).
So schalten Sie das Reporting ein
Fügen Sie dem TXT-Eintrag unter _dmarc.ihredomain.de ein rua=-Tag hinzu:
v=DMARC1; p=none; rua=mailto:dmarc-berichte@ihredomain.de; fo=1
Prüfen Sie mit einer DNS-Abfrage, was derzeit veröffentlicht ist:
dig +short TXT _dmarc.ihredomain.de
Drei Regeln, die Sie vor der DNS-Änderung kennen sollten:
- Nur ein Eintrag. RFC 9989 verlangt genau einen DMARC-TXT-Eintrag pro Domain. Veröffentlichen Sie zwei, wenden Empfänger überhaupt keine Richtlinie an, was DMARC stillschweigend abschaltet.
- Kein
rua=bedeutet keine Berichte. Empfänger dürfen ohne das Tag keine aggregierte Rückmeldung erzeugen. Einen anderen Weg gibt es nicht. - Die Abdeckung ist bewusst unvollständig. Microsofts eigene Dokumentation, aktualisiert am 14. Mai 2026, hält fest, dass nicht alle Empfänger Berichte senden und die Abdeckung typischerweise 70 bis 90 Prozent des Gesamtvolumens beträgt. Apple iCloud und Proton sind überhaupt nicht als Berichtsversender dokumentiert.
Berichte an eine andere Domain senden
Liegt Ihre rua=-Adresse auf einer anderen organisatorischen Domain als die Richtlinie, muss diese empfangende Domain das autorisieren. RFC 9990 Abschnitt 4 verlangt einen TXT-Eintrag unter <ihre-domain>._report._dmarc.<berichtsdomain> mit dem Inhalt v=DMARC1;. Fehlt er, stellen Empfänger den Versand stillschweigend ein. Das ist mit Abstand der häufigste Grund dafür, dass ein korrekt geschriebenes rua=-Tag überhaupt keine Berichte liefert.
Aggregatberichte gegenüber Fehlerberichten
| Aggregatberichte (RUA) | Fehlerberichte (RUF) | |
|---|---|---|
| Spezifikation | RFC 9990 | RFC 9991 |
| Frequenz | Einmal pro UTC-Tag und Anbieter | Nahezu in Echtzeit, pro Nachricht |
| Inhalt | Zählungen pro Quell-IP mit SPF- und DKIM-Ausrichtung sowie angewandter Disposition | Details einer einzelnen fehlgeschlagenen Nachricht, möglicherweise mit Kopfzeilen und Text |
| Datenschutz | Aggregierte Zählungen, kein Nachrichteninhalt | RFC 9991 weist darauf hin, dass personenbezogene Daten enthalten sein können |
| Anbieterunterstützung | Breit: Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho | Selten. Microsoft 365 sendet sie selbst mit gültigem ruf= nicht |
| Am besten geeignet für | Die Senderinventur aufbauen und entscheiden, wann Sie durchsetzen | Einen konkreten, reproduzierbaren Fehler diagnostizieren |
Beginnen Sie mit RUA. Fast alles, was Sie für einen sicheren Weg zu p=reject brauchen, steckt in den Aggregatdaten, und sie tragen keinen der Datenschutzlasten der Fehlerberichte.
Einen Bericht lesen: die vier Ergebnisse, die zählen
Jeder <record>-Block im XML verknüpft eine Quell-IP mit einer Nachrichtenzahl, den rohen SPF- und DKIM-Ergebnissen und einem policy_evaluated-Urteil. Entscheidend ist die Ausrichtung, nicht die reine Authentifizierung. SPF oder DKIM muss bestehen und zu Ihrer From-Domain passen, damit DMARC besteht.
| SPF ausgerichtet | DKIM ausgerichtet | Was es bedeutet | Was zu tun ist |
|---|---|---|---|
| Bestanden | Bestanden | Gesund. Ihre eigene Infrastruktur, korrekt konfiguriert | Nichts. Das ist der Zielzustand für jeden legitimen Versender |
| Bestanden | Fehlgeschlagen | Der Versender ist autorisiert, signiert aber nicht oder mit eigener Domain | DKIM beim Dienst aktivieren und die d=-Domain auf Ihre ausrichten |
| Fehlgeschlagen | Bestanden | Fast immer Weiterleitung oder eine Mailingliste. DMARC besteht trotzdem | Unbedenklich. Nehmen Sie den Weiterleiter nicht in Ihren SPF-Eintrag auf |
| Fehlgeschlagen | Fehlgeschlagen | Entweder ein vergessener legitimer Versender oder Spoofing | IP identifizieren. Autorisieren oder bei der Durchsetzung blockieren lassen |
Die dritte Zeile wird am häufigsten missverstanden. Weiterleitung bricht SPF konstruktionsbedingt, weil sich der Envelope-Sender beim Weiterleitungsschritt ändert. Genau deshalb ist DKIM als Rückfallebene wichtig, und deshalb sind die 43,0 % der DMARC-Domains, die sich allein auf SPF-Ausrichtung verlassen (DMARCguard, Februar 2026), fragiler als sie aussehen.
Was sich 2026 geändert hat: RFC 9989, 9990 und 9991
Im Mai 2026 veröffentlichte die IETF RFC 9989, RFC 9990 und RFC 9991. Zusammen lösen sie RFC 7489 ab und führen DMARC erstmals seit 2015 als Proposed Standard auf den Standards Track, mit dem Reporting in eigenen Dokumenten.
| Element | RFC 7489 (2015) | RFC 9989 / 9990 (2026) | Was Sie tun sollten |
|---|---|---|---|
Tag pct | Unterstützt, für Teilausrollung | Entfernt | Verlassen Sie sich nicht mehr darauf. Nutzen Sie den neuen Testmodus t=y |
Tags rf und ri | Definiert | Entfernt | Bei der nächsten DNS-Änderung löschen |
| Ermittlung der organisatorischen Domain | Public Suffix List | DNS-Tree-Walk | Nichts. Das ist eine Änderung auf Empfängerseite |
| XML-Namensraum im Bericht | http://dmarc.org/dmarc-xml/0.1 | urn:ietf:params:xml:ns:dmarc-2.0 | Ihr Parser muss beide akzeptieren |
DKIM-Feld selector | Optional | Pflicht | Generatoren oder Parser korrigieren, die das Feld weglassen |
Werte für disposition | none, quarantine, reject | Ergänzt pass | Den neuen Wert verarbeiten, statt die Datei abzulehnen |
| Unbekannte Elemente | Nicht definiert | Ignorieren und fortfahren (RFC 9990 Abschnitt 5) | Lehnen Sie nie einen Bericht ab, den Sie nicht vollständig verstehen |
Ihr bestehender Eintrag funktioniert weiter. Die Tags v=, p=, sp=, rua=, ruf=, adkim=, aspf= und fo= behalten ihre Bedeutung. In der Praxis liefern alle großen Anbieter weiterhin XML in der alten Form, rechnen Sie also mit einer jahrelangen Mischphase und parsen Sie tolerant statt streng.
Ein sicherer Rollout in vier Stufen bis p=reject
- Woche 1 bis 2. Veröffentlichen Sie
p=nonemitrua=. Ändern Sie sonst nichts. Sammeln Sie Berichte und erstellen Sie eine Liste jeder IP und jedes Dienstes, der in Ihrem Namen sendet. - Woche 3 bis 6. Beheben Sie die Ausrichtung. Ergänzen Sie fehlende Versender im SPF, aktivieren Sie DKIM überall und prüfen Sie, dass jeder Drittdienst mit Ihrer Domain signiert statt mit seiner eigenen.
- Woche 7 bis 8. Wechseln Sie auf
p=quarantine, gern zuerst auf einer Subdomain übersp=. Beobachten Sie die Berichte eine volle Woche auf übersehene legitime Versender. - Ab Woche 9. Wechseln Sie auf
p=rejectund behalten Sierua=dauerhaft. Monitoring ist kein Gerüst, das man nach dem Bau abbaut.
Stufe eins zu überstürzen ist der klassische Fehler. Ein quartalsweiser Rechnungslauf oder eine jährliche Kampagne taucht in zwei Wochen Daten nicht auf und prallt genau an dem Tag ab, an dem Sie durchsetzen.
Häufige Fragen
Wie oft werden DMARC-Berichte gesendet?
Einmal pro UTC-Tag und berichtendem Anbieter, für ein Fenster ab 00:00 UTC (RFC 9990 Abschnitt 3.1.1.4). Ihr erster Bericht trifft in der Regel 24 bis 48 Stunden nach Veröffentlichung von rua= ein.
Warum erhalte ich keine Berichte?
Meist liegt die rua=-Adresse auf einer anderen Domain und der erforderliche Autorisierungseintrag unter <ihre-domain>._report._dmarc.<berichtsdomain> fehlt. Weitere Ursachen: ein Syntaxfehler im DMARC-Eintrag, zwei gleichzeitig veröffentlichte DMARC-Einträge, oder schlicht keine E-Mail, die Ihre Domain im Zeitraum beansprucht hat.
Ist der DMARC-Bericht in meinem Postfach echt?
Mit hoher Wahrscheinlichkeit ja. Echte Berichte nutzen das Betreffmuster Report Domain: <domain> Submitter: <absender> Report-ID: <id> und hängen komprimiertes XML mit einem durch Ausrufezeichen getrennten Dateinamen an. Echte Berichte enthalten keine Links zum Anklicken, keine Zahlungsaufforderungen und keine Abfragen von Zugangsdaten.
Brauche ich Monitoring auch nach p=reject noch? Ja. Neue Dienste kommen hinzu, DNS wird bearbeitet, DKIM-Schlüssel werden rotiert. Über die Berichte erfahren Sie von einem Defekt, bevor Ihre Kunden es tun.
Kann ich die Berichte einfach löschen?
Sie können rua= entfernen, um sie zu stoppen, tauschen damit aber ein volles Postfach gegen null Sicht darauf, wer Ihre Domain fälscht. rua= auf einen Analysedienst zu richten ist die bessere Antwort.
Prüfen Sie Ihre Konfiguration in 60 Sekunden
Bevor Sie das DNS anfassen, hilft es zu wissen, wo Sie genau stehen. Der kostenlose Scan von FortifyNet liest Ihre DMARC-, SPF- und DKIM-Einträge und zeigt, ob das Reporting tatsächlich konfiguriert ist, ob Ihre Richtlinie durchsetzt und was fehlt. Er dauert etwa eine Minute und braucht keine Registrierung. Kostenlosen Scan bei FortifyNet starten.
Verwandte Leitfäden: DMARC Schritt für Schritt einrichten · Was ist DKIM? · SPF-Eintrag prüfen · DNS-Sicherheitskonfiguration
