DMARCTS Handbuch
DMARCTS ist eine einfache Webanwendung zur Ansicht von aggregierten DMARC-Berichten (DMARC Aggregate Reports). Dieses Handbuch erklärt wie DMARCTS funktioniert und wie die Ergebnisse zu interpretieren sind.
Sprache: Deutsch / English
Schnellstart
- DMARC DNS-Eintrag anlegen und aggregierte Berichte in einem IMAP-Postfach empfangen.
- dmarcts-report-parser und dmarcts-report-viewer installieren.
- Filter “Report Status” auf “At least one failed result” einstellen und DMARC-Berichte alle paar Tage durchsehen.
- Potentielle SPF- oder DKIM-Konfigurationsfehler aufspüren.
Aggregierter Bericht
E-Mail-Empfänger fungieren als DMARC-Berichterstatter und versenden aggregierte DMARC-Berichte an den Inhaber einer E-Mail-Domain. Ein aggregierter Bericht enthält die DMARC-Policy der Absenderdomain sowie die aggregierten Daten der SPF- und DKIM-Prüfung aller erhaltenen E-Mails eines Tages. Die Informationen verteilen sich über mehrere Datensätze (oder Zeilen) im Bericht. Siehe “Understanding DMARC Reports” für weitere Informationen über das Datenformat der Berichte.
Installation
Installiere dmarcts-report-parser, um aggregierte DMARC-Berichte aus einem IMAP-Postfach in eine SQL-Datenbank zu laden. Der Parser ist ein Perl-Skript und kann per Cron-Daemon aufgerufen werden.
Installiere anschließend dmarcts-report-viewer, um den Inhalt der SQL-Datenbank zu visualisieren. Der Viewer ist eine PHP-Webanwendung. Er bietet keine Authentifizierung; daher ist es ratsam, ihn entweder auf einem internen Webserver auszuführen oder .htaccess zur Zugriffskontrolle zu verwenden.
DMARCTS-Benutzeroberfläche
Abbildung 1: Screenshot von DMARCTS.
Die Benutzeroberfläche von DMARCTS besteht aus drei Bereichen, von oben nach unten:
Es gibt keine aggregierte Statistik über die Anzahl der empfangenen Berichte oder die darin enthaltenen DMARC-Ergebnisse. Falls ein grafisches Dashboard benötigt wird, eignet sich dafür parsedmarc mit Kibana oder Splunk. Der Vorteil von DMARCTS gegenüber parsedmarc ist die Detailansicht von einzelnen Berichten.
Optionsleiste
Die Optionsleiste am oberen Bildschirmrand bietet mehrere Einstellungen zur Filterung der Ansicht.
Abbildung 2: Optionsleiste.
Die Option “Hostname” schaltet den DNS-Reverse-Lookup für die IP-Adressen in den Berichten an oder aus. Der Reverse-Lookup erfolgt zum Zeitpunkt der Ansicht und der resultierende Hostname wird nicht in der Datenbank gespeichert. Der eingeschaltete Reverse-Lookup kann zu einer deutlichen Verzögerung führen, wenn der Bericht viele Einträge enthält oder die DNS-Abfrage sehr lange dauert. Falls sich die Benutzeroberfläche träge anfühlt, kann es helfen, die Funktion abzuschalten.
Die Option “DMARC Result” ermöglicht die Filterung nach Berichten, bei denen in allen Zeilen die DMARC-Prüfung entweder erfolgreich, nicht erfolgreich oder bei denen das Ergebnis gemischt war. “Mixed” schließt Berichte aus, in denen alle Zeilen einen Fehlschlag beinhalten, wodurch der Nutzen dieser Filteroption eingeschränkt ist.
Die Option “Report Status” ermöglicht die Filterung nach Berichten, bei denen die SPF-, DKIM- und DMARC-Prüfungen entweder durchgehend erfolgreich oder durchgehend fehlgeschlagen war. Die nützlichste Einstellung ist “At least one failed result”, da dies genau die Berichte anzeigt, bei denen eine der Prüfungen fehlgeschlagen war. “Other condition” ermöglicht die Ansicht der Berichte, bei denen die SPF- oder DKIM-Prüfung nicht durchgeführt werden konnte, weil etwas schiefgelaufen ist. Dies wird üblicherweise als SPF- oder DKIM-Fehlschlag gewertet, wodurch diese Ergebnisse auch bei “At least one failed result” angezeigt werden.
Die Option “Month” ermöglicht die Filterung nach einem bestimmten Monat.
Die Option “Domain(s)” ermöglicht die Filterung nach Absenderdomains. Falls eine Domain in der Liste fehlt, so hat diese noch keine DMARC-Berichte erhalten.
Die Option “Reporter(s)” ermöglicht die Filterung nach E-Mail-Empfängern (also den DMARC-Berichterstattern). Ein Eintrag ist üblicherweise eine Organisation, nicht eine Empfängerdomain. Selbst wenn eine Organisationsdomain angezeigt wird, so kann diese stellvertretend für alle E-Mail-Domains der Organisation stehen (dies ist etwa bei google.com der Fall). Allerdings gibt es auch Berichterstatter, die individuelle Berichte von jedem E-Mail-Server versenden, die man anhand des Hostnamens unterscheiden kann.
Die Schaltfläche “≡” ganz rechts ermöglicht die Anpassung der Benutzeroberfläche und den Wechsel zwischen Light und Dark Theme.
Berichtliste
Die Berichtliste in der Mitte zeigt eine tabellarische Auflistung aller empfangenen aggregierten Berichte.
Abbildung 3: Berichtliste. Die roten und orangenen Kreise weisen auf Probleme bei der E-Mail-Authentifizierung hin.
Der farbige Kreis auf der linken Seite zeigt das Gesamtergebnis eines Berichts an. Ein grüner Kreis benötigt keine Aufmerksamkeit, da die SPF/DKIM/DMARC-Prüfung erfolgreich war. Alle anderen Farben sollten auf potentielle Konfigurationsfehler überprüft werden. Bei Klick auf einen Eintrag öffnen sich die Berichtdetails im unteren Bereich der Benutzeroberfläche.
Berichtdetails
Der untere Bereich der Benutzeroberfläche zeigt die Details eines ausgewählten DMARC-Berichts. Das Textfeld “Policies” oberhalb der Tabelle zeigt die DMARC-Policy so wie sie der E-Mail-Empfänger interpretiert hat. Dies kann in Einzelfällen von der eingestellten DMARC-Policy der Absenderdomain abweichen, beispielsweise wenn der DMARC-DNS-Eintrag einen Syntaxfehler enthält. Das klickbare “XML"-Icon ermöglicht die Ansicht der XML-Rohdaten eines Berichts.
Abbildung 4: Detailansicht eines aggregierten Berichts mit erfolgreichem Ergebnis.
Die farbige Tabelle zeigt eine einfach zu lesende Auswertung der XML-Daten. Hierbei ist zu beachten, dass DMARCTS die Daten so anzeigt, wie sie vom Berichterstatter empfangen wurden. DMARCTS evaluiert nicht, ob die Daten tatsächlich sinnvoll sind. Die Tabelle besteht aus den folgenden Spalten.
“IP” ist die Serveradresse, von der der Berichterstatter E-Mails von einer Absenderdomain erhalten hat. Dies ist nicht unbedingt die tatsächliche Herkunft einer E-Mail. Im Fall einer serverbasierten Weiterleitung oder einer Mailing-Liste handelt es sich bei der IP-Adresse lediglich um den letzten Hop, der die E-Mail beim Empfänger eingeliefert hat.
“Host Name” ist das Ergebnis des DNS-Reverse-Lookups der IP-Adresse. Der Hostname wird von DMARCTS zur Laufzeit ermittelt, aber nicht in der Datenbank gespeichert. Der Hostname wird nicht vom Berichterstatter mitgeteilt.
“Message Count” ist die Anzahl von empfangenen E-Mails, die zu dem in der Zeile angezeigten SPF/DKIM/DMARC-Prüfergebnis geführt haben.
“Disposition” gibt an, ob der Berichterstatter die E-Mail anhand des DMARC-Ergebnisses in die Quarantäne verschoben (“quarantine”) oder abgelehnt (“reject”) hat. Die Disposition hängt vom Gesamtergebnis der DMARC-Prüfung, von der Policy der Absenderdomain, aber auch von der lokalen Policy des Empfängers ab. Die Disposition “none” zeigt an, dass die E-Mail nicht aufgrund der DMARC-Prüfung aussortiert wurde. Die E-Mail kann dennoch aus anderen Gründen aussortiert worden sein, beispielsweise durch den Spamfilter des Empfängers; dies wird im DMARC-Bericht nicht angezeigt.
“Reason” ist ein optionales Feld, in dem der Berichterstatter anzeigen kann, warum er die DMARC-Policy des Absenders übergangen hat. Dies ist der Fall, wenn der Empfänger eine lokale Policy angewandt hat und daher das Dispositionsergebnis nicht der DMARC-Policy der Absenderdomain entspricht.
Abbildung 5: Prüfergebnis für zwei DKIM-Signaturen. Der DKIM-Selektor wird nur in der XML-Ansicht angezeigt.
“DKIM Domain” ist die verwendete Domain einer DKIM-Prüfung (Parameter d= im Header DKIM-Signature). Falls die E-Mail mehrere DKIM-Signaturen hatte, kann es mehrere DKIM-Ergebnisse geben, die in DMARCTS als eine Liste von DKIM-Domains angezeigt werden (Abbildung 5). Das hängt allerdings davon ab, ob der Berichterstatter mehrere DKIM-Ergebnisse im Bericht aufführt oder nur das erste erfolgreiche DKIM-Ergebnis.
Ein Berichterstatter kann optional auch den verwendeten DKIM-Selektor angeben, der aber von DMARCTS nicht angezeigt wird. Er ist jedoch in der XML-Rohdatenansicht einsehbar (Abbildung 5).
“DKIM Auth” enthält das DKIM-Prüfergebnis bevor der DMARC-Domainabgleich durchgeführt wurde (Identifier Alignment). Eine Einschränkung von DMARCTS ist hierbei, dass nur das erste DKIM-Prüfergebnis angezeigt wird, auch wenn der Bericht mehrere Ergebnisse enthält (was anhand der DKIM-Domains erkennbar ist). Die anderen Ergebnisse sind in der XML-Rohdatenansicht einsehbar (Abbildung 5).
Abbildung 6: SPF-Prüfergebnis für zwei Domains. Der SPF-Scope ist nur in der XML-Ansicht einsehbar.
“SPF Domain” ist die verwendete Domain einer SPF-Prüfung. Dies entspricht entweder dem SMTP Envelope-From (RFC 5321) oder dem HELO/EHLO Hostnamen. Es können auch beide gleichzeitig in einem Bericht enthalten sein, was DMARCTS als ein Paar von SPF-Domains anzeigt (Abbildung 6).
Ein Berichterstatter kann optional auch den verwendeten SPF-Scope angeben (“mfrom” = Envelope-From-Domain, “helo” = HELO/EHLO Hostname), der aber von DMARCTS nicht angezeigt wird. Er ist jedoch in der XML-Ansicht einsehbar (Abbildung 6).
“SPF Auth” enthält das SPF-Prüfergebnis bevor der DMARC-Domainabgleich durchgeführt wurde (Identifier Alignment). Eine Einschränkung von DMARCTS ist hierbei, dass nur das erste SPF-Prüfergebnis angezeigt wird, auch wenn der Bericht zwei Ergebnisse enthält (was anhand der SPF-Domains erkennbar ist). Das andere Ergebnis ist in der XML-Ansicht einsehbar (Abbildung 6).
“DKIM Align” and “SPF Align” enthalten das Ergebnis der DKIM- und SPF-Prüfung nachdem der DMARC-Domainabgleich (Identifier Alignment) durchgeführt wurde. DMARC setzt voraus, dass die bei DKIM oder SPF geprüfte Domain mit dem Header-From der E-Mail (RFC 5322) übereinstimmt. Eine E-Mail, die zwar die reine SPF- oder DKIM-Prüfung besteht, nicht jedoch den Domainabgleich, gilt bei DMARC nicht als authentisch. Die Felder “DKIM Align” und “SPF Align” sind deswegen maßgeblich gegenüber den entsprechenden “Auth”-Feldern.
“DMARC” ist das Gesamtergebnis der DMARC-Prüfung. Die DMARC-Prüfung war erfolgreich (“Pass”), falls mindestens eine der beiden Prüfungen “DKIM Align” oder “SPF Align” erfolgreich war. Falls beide fehlgeschlagen sind, wurde die E-Mail entsprechend der DMARC-Policy des Absenders und ggf. der lokalen Policy des Empfängers aussortiert.
Beispiele
Die folgenden Beispiele zeigen typische Anwendungsfälle, in denen die E-Mail-Authentifizierung fehlgeschlagen ist.
DMARC erfolgreich
DMARC erfordert, dass mindestens eines der beiden Prüfverfahren, SPF oder DKIM, erfolgreich abschließt. Falls eines fehlschlägt, genügt das andere für eine erfolgreiche DMARC-Prüfung.
Abbildung 7: DMARC-Prüfung erfolgreich, auch ohne DKIM.
In dem Beispiel in Abbildung 7 hatte die E-Mail keine DKIM-Signatur. Dies ist erkennbar anhand “DKIM Auth=unknown”. Ohne DKIM-Signatur schlägt der “DKIM Align”-Domainabgleich fehl. Die SPF-Prüfung mitsamt Domainabgleich war jedoch erfolgreich, sodass das DMARC-Gesamtergebnis “Pass” lautet. Es empfiehlt sich, zu prüfen, ob die DKIM-Signierung korrekt eingerichtet ist.
Abbildung 8: DMARC-Prüfung erfolgreich, auch ohne SPF.
Abbildung 8 zeigt zwei verschiedene Ergebnisse: in der ersten Zeile waren sowohl die SPF- als auch die DKIM-Prüfung erfolgreich. In der zweiten Zeile zeigt “SPF Auth=none” an, dass für die Envelope-From-Domain (“SPF Domain=srs.mailroute.net”) kein SPF eingerichtet ist. Daher schlägt auch der “SPF Align”-Domainabgleich fehl. Das DKIM-Prüfergebnis zeigt jedoch, dass die E-Mail authentisch ist und daher die DMARC-Prüfung insgesamt besteht.
Dieses Beispiel ist typisch für eine serverbasierte E-Mail-Weiterleitung. Der Empfänger erhält die E-Mail von einer anderen IP-Adresse, wodurch die SPF-Prüfung zwangsläufig fehlschlägt. Solange die DKIM-Prüfung erfolgreich ist, ist die E-Mail authentisch und es ist keine Handlung erforderlich.
Abbildung 9: DMARC-Prüfung erfolgreich, obwohl SPF fehlschlägt.
Abbildung 9 ist ähnlich zum vorherigen Beispiel, allerdings mit “SPF Auth=fail”. Das liegt daran, dass die IP-Adresse des einliefernden Servers nicht im SPF-Eintrag der Envelope-From-Domain (“SPF Domain=wander.science”) autorisiert ist. Auch dieses Beispiel ist typisch für eine serverbasierte Weiterleitung. Allerdings kann dies auch auftreten, wenn der Domaininhaber es versäumt hat, alle IP-Adressen vollständig im SPF-Eintrag aufzulisten. Es empfiehlt sich daher, zu prüfen, ob es sich bei der im DMARC-Bericht aufgeführten IP-Adresse um eine authentische Serveradresse handelt.
DMARC fehlgeschlagen
Es folgen diverse Beispiele von gefälschten E-Mail-Absendern. Sofern als DMARC-Policy “p=quarantine” oder “p=reject” eingestellt ist, erfordern Berichte über gefälschte Absenderadressen keine weitere Handlung. Es empfiehlt sich aber, gelegentlich zu überprüfen, ob es sich wirklich um E-Mail-Spoofing handelt oder ob die DMARC-Prüfung fälschlicherweise legitime E-Mails ablehnt. DMARC-Berichte helfen dabei, Randfälle von SPF/DKIM/DMARC-Fehlkonfigurationen zu identifizieren, die ansonsten unentdeckt blieben.
Abbildung 10: Kein DKIM oder SPF.
Im Beispiel in Abbildung 10 sind sowohl DKIM als auch SPF fehlgeschlagen. Die E-Mail hatte keine DKIM-Signatur (erkennbar anhand von “DKIM Auth=unknown”) und die Envelope-From-Domain hatte keinen SPF-Eintrag (“SPF Auth=none”). Der Absender war somit nicht autorisiert, E-Mails im Namen der Header-From-Domain zu versenden (ganz oben sichtbar: Report from google.com for swznet.de). Das DMARC-Gesamtergebnis ist “Fail” und die E-Mail wurde entsprechend der DMARC-Policy abgelehnt (“Disposition=reject”).
Abbildung 11: Domainabgleich bei SPF fehlgeschlagen.
Das Beispiel in Abbildung 11 ist ähnlich zum vorherigen, abgesehen von “SPF Auth=pass”. Das weist darauf hin, dass die Envelope-From-Domain (“SPF Domain=eigbox.net”) einen SPF-Eintrag verwendet, der die IP-Adresse des Absenders autorisiert hat. Allerdings ist der Domainabgleich zwischen der Envelope-From-Domain eigbox.net und der Header-From-Domain swznet.de fehlgeschlagen, was zum Bewertungsergebnis “SPF Align=fail” führt. Da es zudem auch keine DKIM-Signatur gibt, lautet das Gesamtergebnis “DMARC=Fail”.
Abbildung 12: Domainabgleich bei DKIM fehlgeschlagen.
Das Beispiel in Abbildung 12 zeigt “DKIM Auth=pass”, was auf eine korrekte DKIM-Signatur hinweist. Allerdings ist die DKIM-Signatur für “DKIM Domain=evastores.com” ausgestellt, was nicht der Header-From-Domain swznet.de entspricht. Demnach ist der Domainabgleich fehlgeschlagen (“DKIM Align=fail”). Als Envelope-From-Domain wird zwar “SPF Domain=swznet.de” behauptet, aber die SPF-Prüfung schlägt tatsächlich fehl (“SPF Auth=fail”). Ohne ein gültiges SPF-Prüfergebnis gilt auch der Domainabgleich als fehlgeschlagen (“SPF Align=fail”). Das Gesamtergebnis ist somit “DMARC=Fail”.