Wie man einen DMARC aggregierten XML-Bericht untersucht
Lesen Sie Quellenzählungen und abgestimmte Ergebnisse, vergleichen Sie sie mit einem Absenderinventar und vermeiden Sie es, DMARC-Ausfälle mit einem bestätigten Angriff zu verwechseln.
Definieren Sie die Frage und das Berichtsfenster
Beginnen Sie mit einer spezifischen Frage: Fehlt ein bekannter Newsletter-Absender oder ist eine unbekannte Quelle in den ausgewählten Berichten erschienen? Notieren Sie sich die Meldeorganisation, die Richtliniendomäne und den Datumsbereich, bevor Sie Dateien kombinieren. Ein aggregierter Bericht fasst die Beobachtungen eines Empfängers zusammen; es ist nicht ein vollständiges Hauptbuch jeder Nachricht, die Ihre Organisation gesendet hat. Fehlende Empfänger und Berichtslücken sind wichtig. Bewahren Sie den Originalbericht neben Ihren Notizen auf, damit ein späterer Rezensent die gleichen Beweise einsehen kann. Eine hohe Zählung ohne ein definiertes Berichtsfenster ist schwer mit einer Änderung Ihrer Sendeaktivität zu vergleichen.
Öffnen Sie XML, das der Leser tatsächlich unterstützt
Der DMARC-Berichtsleser akzeptiert ein vollständiges XML-Dokument oder ausgewählte UTF-8-XML-Dateien. Komprimierte Archive zuerst extrahieren: ZIP- und GZIP-Inhalte werden nicht direkt analysiert. Die aktuelle Schnittstelle unterstützt bis zu zwanzig Dateien, fünf Megabyte insgesamt und zwanzigtausend Datensätze. Die Dateieingabe ersetzt eingefügtes XML. Überprüfen Sie, welche Dateien ausgewählt werden, bevor Sie die Analyse ausführen. Die Verarbeitung bleibt in Ihrem Browser, aber das stellt nicht die Authentizität des Berichts fest. Verwenden Sie Berichte, die Sie über Ihren normalen Berichtsworkflow erhalten haben, und behalten Sie deren Herkunft bei, anstatt eine willkürlich heruntergeladene XML-Datei als verbindlich zu behandeln.
Unterscheidung der Ausrichtung von einem rohen Authentifizierungspass
DMARC verknüpft erfolgreiche SPF- oder DKIM-Authentifizierung mit der sichtbaren From-Domäne durch Ausrichtung. Ein Rohpass für eine andere Domäne kann mit einem Ausrichtungsfehler koexistieren. Der Leser zählt policy_evaluated-Ergebnisse, anstatt rohe auth_results Werte zu ersetzen. Diese Wahl ist wichtig, wenn Weiterleitungen oder Dienste untersucht werden, die mit einer anderen Domain signieren. Vergleichen Sie die relevanten Identifikatoren, bevor Sie einen offensichtlichen Widerspruch interpretieren. RFC 9989 beschreibt das Authentifizierungs- und Alignmentmodell; RFC 9990 definiert die aggregierte Berichterstattung. Weder ein Rohpass noch eine veröffentlichte Richtlinie allein reichen aus, um das Ergebnis jeder Nachricht zu erklären.
Arbeiten Sie sich durch den fiktiven Demonstrationsbericht
Das eingebaute Beispiel enthält drei Datensätze: 120 Nachrichten mit ausgerichteten SPF- und DKIM-Übergängen, 30 mit ausgerichteten DKIM, die übergehen und ausgerichtete SPF ausfallen, und 10 mit beiden ausfallen. Das Hinzufügen der gelieferten Zählungen gibt 160 Nachrichten. Die ersten beiden Gruppen tragen 150 DMARC-Pässe bei, weil jeder ausgerichtete Mechanismus ausreicht; zehn scheitern. Der Fehleranteil für diese Befestigung ist 10 geteilt durch 160 oder 6.25%. Dies sind Berechnungen aus absichtlich fiktionalem XML, keine Beobachtungen über eine reale Domain oder einen Anbieter. Verwenden Sie das Beispiel, um zu erfahren, welche Felder die Gesamtsummen bestimmen, bevor Sie Ihre eigenen Berichte importieren.
| Ausgerichtete DKIM | Ausgerichteter SPF | Nachrichten | DMARC-Zusammenfassung |
|---|---|---|---|
| Pass | Pass | 120 | Pass |
| Pass | Fehlschlag | 30 | Pass |
| Fehlschlag | Fehlschlag | 10 | Fehlschlag |
| Insgesamt | Entweder fluchtender Mechanismus geht | 160 | 150 Pass; 93.75% |
Fiktionaler Bericht. Empfängerdisposition und Ausrichtungsergebnis sind getrennte Felder.
Verwenden Sie dieses Beispiel Öffnet DMARC Report Reader mit diesen Eingaben.
Disposition getrennt von der Authentifizierung halten
Ein Bericht liefert auch die Disposition des Empfängers. Der Leser akzeptiert Pass von RFC 9990, Legacy None, Quarantäne und Reject; es ist ein struktureller Leser und keine vollständige XML-Schemavalidierung. Gehen Sie nicht davon aus, dass die Quarantäne alle DMARC-Ausfälle entsprechen muss. Politische Entscheidungen und Empfängerhandhabung können dazu führen, dass sich diese Summen unterscheiden. Im fiktiven Beispiel haben die zehn fehlgeschlagenen Nachrichten eine Quarantäne-Disposition; diese Beziehung gehört zur mitgelieferten Einrichtung und ist keine universelle Regel. Lesen Sie die Datensatzinformationen, bevor Sie einen unerklärlichen Unterschied eskalieren. Die Alignment-Felder steuern Authentifizierungssummen unabhängig von der Aktion, die der Empfänger meldet.
Vergleichen Sie eine Quelle mit Ihrem sendenden Inventar
Vergleichen Sie für eine unbekannte Quelle die Quelladresse, die sichtbare Domain und den Beobachtungszeitraum mit Ihren bekannten Diensten und den jüngsten Änderungen. Eine neue Rechnungsplattform oder eine migrierte Newsletter-Integration kann den Datenverkehr erklären, der im alten Inventar fehlte. Weiterleitung oder unbefugte Nutzung sind weitere Möglichkeiten. Der Leser weist einem Anbieter keine IP-Adresse zu oder klassifiziert eine Quelle als bösartig. Halten Sie diese Urteile getrennt, bis Sie Beweise haben. Notieren Sie einen praktischen nächsten Schritt, z. B. das Überprüfen der konfigurierten Signaturdomäne des Anbieters, anstatt automatisch jede Zeile zu entfernen oder zu blockieren, die nicht ausgerichtet ist.
Vermeiden Sie es, dieselben Beobachtungen zweimal zu zählen
Bewahren Sie Berichtsidentitäten und Berichtszeiträume in Ihrem Arbeitsprotokoll auf. Der Leser lehnt doppelte Identitäten innerhalb einer Einreichung ab, aber unterschiedliche Berichts-IDs mit überlappenden Perioden können immer noch überlappenden Datenverkehr beschreiben. Die Kombination dieser Dateien kann einen offensichtlichen Trend aufblasen. Vergleichen Sie die gleiche Empfängerabdeckung und -intervalle, wenn Sie die Verbesserung nach einer Konfigurationsänderung messen. Denken Sie auch daran, dass die angezeigte Tabelle begrenzt werden kann, während der Download mehr Zeilen behält. Untersuchen Sie den vollständigen Export, wenn nötig. Ein sich ändernder Prozentsatz kann eine geänderte Auswahl von Berichten sowie eine geänderte Sendekonfiguration widerspiegeln.
Überprüfen Sie eine echte Nachricht, bevor Sie die Richtlinie ändern
Verwenden Sie den DMARC Record Checker, um die aktuell veröffentlichte Richtlinie zu überprüfen und dann eine repräsentative Nachricht von dem betroffenen legitimen Dienst zu erhalten. Lesen Sie vertrauenswürdige Header mit dem Header-Analyzer und vergleichen Sie Identitäten mit dem Bericht. Aktuelles DNS kann von der Politik abweichen, die während eines früheren Berichtsintervalls beobachtet wurde. Halten Sie diesen Timing-Unterschied explizit. Sobald die Ursache verstanden ist, überprüfen Sie die entsprechende Servicekonfiguration und Ihren Richtlinienänderungsprozess. Ein Bericht ist ein diagnostischer Lead, kein Versprechen der Lieferung oder ein Befehl, sofort zu einer strengeren Politik überzugehen. Bewahren Sie die Beweise auf und überprüfen Sie die nachfolgenden Beobachtungen.