Ein DMARC-Eintrag mit rua= hat eine Nebenwirkung, auf die kaum jemand vorbereitet ist: ab dem nächsten Tag kommen täglich Nachrichten mit angehängten ZIP- oder GZ-Dateien, von Google, Microsoft, Yahoo, von Mailservern, deren Namen man noch nie gehört hat. Darin steckt XML. Die meisten Leute schauen zweimal hinein und richten dann eine Regel ein, die den ganzen Stapel in einen Ordner räumt.
Das ist schade, denn diese Dateien beantworten eine Frage, die sonst niemand beantworten kann: wer verschickt eigentlich Post unter meinem Namen?
Was in einem Bericht steht — und was nicht
Ein aggregierter Bericht ist eine Strichliste, keine Sammlung von Nachrichten. Er enthält keine Betreffzeilen, keine Empfänger, keine Inhalte. Er sagt für einen Tag und einen Empfänger: von diesen IP-Adressen kamen so viele Nachrichten mit deiner Domain im From:, und so sind sie ausgegangen.
Der Aufbau ist immer derselbe. Wer ihn einmal kennt, liest die Datei auch ohne Werkzeug.
policy_evaluated und auth_results: das eine ist das Ergebnis, das andere die Begründung.Ein Datensatz im Original
So sieht ein einzelner record aus, entpackt und eingerückt:
<record>
<row>
<source_ip>198.51.100.24</source_ip>
<count>417</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>firma.de</header_from>
</identifiers>
<auth_results>
<spf><domain>firma.de</domain><result>pass</result></spf>
</auth_results>
</record>Gelesen heißt das: von 198.51.100.24 kamen an diesem Tag 417 Nachrichten mit firma.de im sichtbaren Absender. SPF hat bestanden und war ausgerichtet, DKIM war es nicht — hier gab es gar keine Signatur. Weil ein ausgerichteter Weg genügt, ist DMARC bestanden. disposition: none sagt, dass der Empfänger nichts unternommen hat.
Die Falle: zwei Ergebnisse, die gleich heißen
In dem Block stehen die Wörter spf und dkim zweimal, an zwei verschiedenen Stellen, mit zwei verschiedenen Bedeutungen:
- In
auth_resultssteht das rohe Ergebnis: hat die Prüfung als solche bestanden? - In
policy_evaluatedsteht das Ergebnis nach der Ausrichtung: zählt dieses Bestehen auch für DMARC?
Ein pass oben und ein fail unten ist der häufigste Befund überhaupt und beschreibt keinen Widerspruch, sondern eine Quelle, die zwar berechtigt sendet, aber unter fremder Domain. Warum das so ist, steht im Artikel über die Ausrichtung.
Was ein erster Bericht typischerweise zutage fördert
Wer DMARC neu einschaltet, findet in den ersten zwei Wochen fast immer mehr sendende Quellen als erwartet. Die Kandidaten wiederholen sich über Organisationen hinweg:
| Quelle | Typischer Befund |
|---|---|
| Eigener Mailserver | SPF und DKIM ausgerichtet — der unauffällige Teil |
| Newsletter-Dienst | SPF nicht ausgerichtet, DKIM auf der Dienstleisterdomain |
| Ticket- oder CRM-System | schickt unter der Firmendomain, ganz ohne DKIM |
| Rechnungs- oder Shopsoftware | eigener Versandweg, oft seit Jahren vergessen |
| Überwachung, Backup, Drucker | kleine Zahlen, feste IP, meist aus dem eigenen Netz |
| Weiterleitungen | fremde IP, SPF gebrochen, DKIM heil |
| Fremde Absender | wechselnde IPs, beides gescheitert, kleine Stückzahlen |
Die letzte Zeile ist die, wegen der man DMARC einführt — und in aller Regel die kleinste. Der Aufwand steckt in den Zeilen darüber: jede legitime Quelle muss gefunden und eingerichtet werden, bevor die Richtlinie verschärft werden kann.
Die Reihenfolge, die funktioniert
p=nonemitrua=setzen. Das ändert an der Zustellung nichts und schaltet nur die Berichte ein.- Zwei bis vier Wochen sammeln. Kürzer nicht: der monatliche Rechnungslauf und der Newsletter, den es nur alle drei Wochen gibt, tauchen sonst nicht auf.
- Die Quellen auflisten und zuordnen. Jede IP, die mehr als eine Handvoll Nachrichten geschickt hat, muss einen Namen bekommen.
- Ausrichtung herstellen, in der Regel über DKIM beim jeweiligen Dienstleister.
- Erst dann verschärfen — schrittweise über
pct=, das den Anteil der behandelten Nachrichten festlegt.
Schritt drei ist der, an dem Projekte hängenbleiben, und dafür gibt es einen unangenehmen Grund: manche Quellen findet man nur, indem man in der Firma herumfragt, wer vor sechs Jahren einen Dienst eingerichtet hat.
Die forensischen Berichte
Neben rua= gibt es ruf=: Meldungen zu einzelnen gescheiterten Nachrichten, mit Kopfzeilen und teilweise Inhalt. In der Praxis kommen davon fast keine an. Die Berichte enthielten personenbezogene Daten Dritter, und die meisten großen Anbieter haben den Versand deshalb eingestellt. Man kann ruf= setzen; erwarten sollte man nichts.
Braucht man ein Werkzeug dafür?
Für ein paar Domains und ein überschaubares Aufkommen genügt es, die Anhänge zu entpacken und die Datensätze zu überfliegen — die interessanten Zeilen sind die mit unbekannter source_ip und zwei Fehlschlägen im policy_evaluated. Bei zweistelligen Domainzahlen oder hohem Volumen wird das unübersichtlich, und eine Auswertung, die die Berichte zusammenführt und IPs auflöst, spart Stunden.
Der Punkt ist ein anderer: die Berichte sind nicht kompliziert. Sie sind nur so verpackt, dass sie kompliziert aussehen.