Ich erhalte keine DMARC-Berichte: die Ursachen und die Abhilfe

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

3. Der Eintrag ist auf dem falschen Hostnamen

Ein DMARC-Eintrag muss auf _dmarc.beispiel.de veröffentlicht werden, nicht auf der Wurzel beispiel.de. Das ist eine häufige Verwechslung: Man fügt den Wert v=DMARC1; … in einen TXT-Eintrag an der Wurzel ein, und die Empfänger finden ihn nie, weil sie gezielt auf dem Unternamen _dmarc suchen. Der Host des TXT-Eintrags gehört also kontrolliert. Liegt er an der Wurzel, ist er erneut auf _dmarc zu veröffentlichen.

4. Der Eintrag hat einen Syntaxfehler

Ein ungültiger Eintrag kann komplett ignoriert werden. Die Fehler, die das Lesen zerstören: v=DMARC1 falsch geschrieben oder nicht an erster Stelle, zwei verschiedene DMARC-Einträge auf _dmarc (es darf nur einen geben), fehlende Semikolons oder störende Anführungszeichen, die innerhalb des Werts hinzugefügt wurden. Nur einer dieser Mängel und der Empfänger geht davon aus, dass es keine verwertbare DMARC-Policy gibt — also keinen Bericht.

5. Das externe Ziel ist nicht autorisiert

Hier ist die subtilste Falle und eine sehr verbreitete stille Ursache. Zeigt das rua auf eine Adresse einer anderen Domain als der eigenen (zum Beispiel ein Analysedienst), muss diese empfangende Domain einen Autorisierungseintrag veröffentlichen, andernfalls verweigern die Empfänger den Versand der Berichte.

Konkret, damit beispiel.de seine Berichte an dmarc@dienstleister.de sendet, muss die Domain dienstleister.de veröffentlichen:

beispiel.de._report._dmarc.dienstleister.de  IN TXT  "v=DMARC1"

Fehlt dieser Eintrag, kommt über diese externe Adresse nichts an, selbst mit perfekter rua-Syntax. Der vollständige Mechanismus wird in die rua-Adresse konfigurieren ausführlich behandelt. Die einfachste Abhilfe zum Testen: rua vorübergehend auf eine Adresse der eigenen Domain zeigen lassen, die keine Autorisierung erfordert. Kommen die Berichte dann an, ist die Ursache isoliert.

6. Die Domain empfängt zu wenig Post

Ein aggregierter Bericht wird nur von einem Empfänger gesendet, der Post empfangen hat, die vorgibt, von der Domain zu kommen. Versendet die Domain sehr wenig — oder fälscht noch niemand ihren Namen — gibt es schlicht nicht viel zu berichten. Kleine Domains mit geringem Volumen erhalten naturgemäß weniger Berichte, und manchmal nur von einigen großen Anbietern. Das ist kein Fehler: Es ist das Abbild des tatsächlichen Verkehrs. Eine von der Domain aus an eine Gmail- oder Outlook-Adresse gesendete Test-E-Mail lässt am nächsten Tag einen Bericht dieses Anbieters auftauchen. Das ist übrigens der beste isolierte Test: Er erzeugt garantiert beobachtbaren Verkehr bei einem Anbieter, der seinerseits zuverlässig Berichte sendet — kommt nach diesem Test nichts an, liegt das Problem in der Konfiguration, nicht im Volumen.

7. Die Berichte kommen an… aber im Spam

Häufige Ironie: Die Berichte kommen zwar an, aber das Mailprogramm stuft sie als Spam ein. Die von automatischen Servern gesendeten komprimierten XML-Dateien ähneln für einen Anti-Spam-Filter verdächtiger Post. Bevor auf Schweigen zu schließen ist, gehört der Spam-Ordner der rua-Adresse geprüft. Finden sie sich dort, leitet eine passende Regel sie künftig in einen dedizierten Ordner — und die gesamte verloren geglaubte Historie ist auf einen Schlag zurück.

8. Nicht alle Empfänger senden Berichte

Schließlich ist zu wissen, dass der Versand aggregierter Berichte nicht universell ist. Die große Mehrheit der großen Anbieter (Gmail, Yahoo, Outlook, La Poste und viele andere) senden welche, aber manche kleinen Mailserver senden überhaupt keine. Ein Bericht von jedem Empfänger der Post trifft also niemals ein — nur von denen, die teilnehmen. Das ist normal, und die Abdeckung der großen Akteure reicht bei Weitem aus, um ein zuverlässiges Bild des Verkehrs zu haben.

Diese Teilabdeckung hat eine praktische Konsequenz, die man verinnerlichen sollte: Die DMARC-Berichte sind eine repräsentative Stichprobe, kein erschöpfendes Register. Wenn eine legitime Quelle ausschließlich an kleine, nicht berichtende Server versendet, könnte sie in den Berichten unsichtbar bleiben — nicht, weil ein Problem vorliegt, sondern weil niemand über sie berichtet. In der Praxis ist das selten ein echtes Hindernis, denn fast jede reale Versandquelle erreicht früher oder später einen der großen Anbieter, die zuverlässig berichten. Aber es erklärt, warum man die Berichte als starkes Signal lesen sollte und nicht als absolute, buchstabengetreue Zählung jeder einzelnen versendeten Nachricht.

Ein verwandter Punkt betrifft das Volumen: Die Anzahl der eingehenden Berichte wächst grob mit dem Volumen und der Reichweite der Post. Ein Domain, der massiv an Privatpersonen versendet, wird täglich Dutzende von Berichten aus dem gesamten Ökosystem sammeln; ein Domain, der nur einige interne E-Mails an eine Handvoll bekannter Empfänger schickt, wird nur eine dünne Berichtslage sehen. Beide sind normal — die Berichtsmenge spiegelt den Fußabdruck wider, nicht die Qualität der Konfiguration. Der Erfolg der Einrichtung misst sich daher an der Ausrichtung der sichtbaren Quellen, nicht an der schieren Zahl der eingehenden Berichte.

Warum man dieses Schweigen regeln muss, und zwar schnell

Man könnte glauben, dass eine Domain ohne Berichte „trotzdem funktioniert" — schließlich ist die Policy veröffentlicht. Das ist eine gefährliche Illusion. Ohne Berichte herrscht Blindflug: Weder ist erkennbar, ob eine legitime Quelle an der Ausrichtung scheitert, noch ob ein Angreifer bereits den Namen der Domain testet. Schlimmer: Ein sicheres Verschärfen ist unmöglich, denn die Entscheidung, auf quarantine und dann reject überzugehen, beruht vollständig auf dem, was die Berichte zeigen. Eine auf p=none ohne Reporting blockierte Domain vereint das Schlechteste aus beiden Welten: keinen Schutz und keine Sichtbarkeit, um welchen zu gewinnen.

Deshalb ist das Schweigen der Berichte kein kosmetisches Detail, das man behandelt, „wenn man Zeit hat": Es ist eine Blockade auf dem kritischen Pfad zur Durchsetzung. Die obige Diagnose verdient es, in den ersten Tagen nach der Veröffentlichung gemacht zu werden, nicht Monate später, wenn man sich fragt, warum das DMARC-Projekt nicht vorankommt.

Ein Sonderfall: die Berichte, die plötzlich aufhören

Das Szenario ist anders, wenn Berichte eintrafen und dann aufgehört haben. Da sind die „Anfänger"-Ursachen (falscher Host, fehlendes rua) ausgeschlossen, da es funktionierte. Zu suchen ist eher nach einer kürzlichen Änderung:

• Ein irrtümlich überschriebener DMARC-Eintrag bei einer DNS-Migration oder einem Werkzeugwechsel, der das rua-Tag gelöscht oder verformt hat.
• Eine rua-Adresse, die nicht mehr existiert — das Postfach wurde gelöscht, oder die Weiterleitung zum Analysedienst wurde unterbrochen.
• Eine abgelaufene oder zurückgezogene externe Autorisierung auf Dienstleisterseite, falls ein externes Ziel genutzt wurde.
• Ein aggressiver gewordener Anti-Spam-Filter, der begonnen hat, die zuvor sichtbaren Berichte abzufangen.

Ein Vergleich des aktuellen Eintrags mit dem, der funktionierte, führt zum Ziel: Die Ursache eines plötzlichen Stopps ist fast immer eine datierte Änderung, die sich wiederfinden lässt.

Die Diagnosemethode, zusammengefasst

Angesichts eines Schweigens der Berichte sind die Ursachen in dieser Reihenfolge durchzugehen:

1. 48 h abwarten — die Berichte sind täglich.
2. Vorhandensein und Syntax von rua prüfen (mailto:, nicht ruf).
3. Den Hostnamen kontrollieren — auf _dmarc, nicht an der Wurzel.
4. Die Gesamtsyntax validieren — ein einziger Eintrag, v=DMARC1 an der Spitze.
5. Mit einer Adresse der eigenen Domain testen, um die Falle der externen Autorisierung auszuschließen.
6. Eine Test-E-Mail senden an Gmail/Outlook, um zu berichtenden Verkehr zu erzeugen.
7. In den Spam-Ordner schauen.

Neun von zehn Mal steckt der Übeltäter in den ersten fünf Punkten — und meistens ist es entweder die Ungeduld oder die fehlende externe Autorisierung. Diese Reihenfolge ist nicht willkürlich: Sie stellt die häufigsten und am wenigsten aufwendig auszuschließenden Ursachen an die Spitze, damit keine Stunde auf einen seltenen Fall verloren geht, bevor das Offensichtliche ausgeschlossen ist.

Um schnell zwischen „meine Konfiguration ist kaputt" und „man muss einfach warten" zu entscheiden, führt der Weg über den kostenlosen DMARC-Analysator: Er meldet sofort, ob der Eintrag gültig ist, ob rua korrekt geformt und für die Empfänger lesbar ist, und somit, ob das Problem von der Konfiguration oder einfach von der Verzögerung kommt. Das ist der schnellste Weg zu wissen, auf welcher Seite man suchen muss.