SPF, DKIM und DMARC für Blue Teams: E-Mail-Authentifizierung nutzen

SPF, DKIM und DMARC sind Begriffe, die in fast jedem Phishing-Beitrag als bekannt vorausgesetzt werden, das Phishing-Playbook prüft sie in der Erstanalyse, aber selten erklärt. Dabei sind sie für ein Blue Team doppelt wichtig: Sie schützen die eigene Domain davor, dass Angreifer in ihrem Namen phishen, und sie liefern bei jeder eingehenden Mail ein Erkennungssignal, ob der Absender echt ist. Dieser Beitrag erklärt die drei Standards ohne Vorwissen, zeigt, wie man die Authentifizierungsergebnisse in den Kopfzeilen liest, und wie man sie sowohl zur Absicherung der eigenen Domain als auch zur Erkennung eingehender Fälschungen nutzt.

Das Problem, das die drei lösen

E-Mail wurde in einer Zeit erfunden, in der Vertrauen selbstverständlich war: Der Absender einer Mail lässt sich frei eintragen, so wie man auf einen Briefumschlag jeden beliebigen Absender schreiben kann. Ein Angreifer kann also eine Mail verschicken, die aussieht, als käme sie von deiner Bank, deinem Chef oder deiner eigenen Domain, ohne Zugriff auf irgendetwas davon. SPF, DKIM und DMARC schließen diese Lücke, indem sie dem empfangenden Server erlauben zu prüfen, ob eine Mail wirklich von der Domain kommt, die sie behauptet. Die drei bauen aufeinander auf und ergeben erst zusammen einen wirksamen Schutz.

SPF: wer darf senden

Das Sender Policy Framework ist ein Eintrag im DNS der Domain, der auflistet, welche Server im Namen dieser Domain Mails verschicken dürfen. Wenn ein empfangender Server eine Mail von deiner-firma.de bekommt, schaut er in den SPF-Eintrag von deiner-firma.de und prüft, ob die sendende IP-Adresse dort erlaubt ist. Steht sie nicht drin, ist die Mail verdächtig. SPF hat zwei Schwächen: Es prüft die technische Absenderdomain (den Envelope-From), nicht die Adresse, die der Empfänger im Mailprogramm sieht (den Header-From), und es bricht bei Weiterleitungen, weil dann ein anderer Server sendet. Deshalb ist SPF allein kein ausreichender Schutz, sondern ein Baustein.

DKIM: die kryptografische Signatur

DomainKeys Identified Mail geht anders vor: Der sendende Server signiert die Mail mit einem privaten Schlüssel, und der öffentliche Schlüssel steht im DNS der Domain. Der empfangende Server kann mit dem öffentlichen Schlüssel prüfen, ob die Signatur stimmt und die Mail unterwegs nicht verändert wurde. Der Vorteil gegenüber SPF: Die Signatur überlebt Weiterleitungen, weil sie an der Mail hängt, nicht an der sendenden IP. Auch DKIM allein hat eine Lücke: Es bestätigt, dass eine Mail von der signierenden Domain kommt, aber es verlangt nicht, dass diese Domain zur sichtbaren Absenderadresse passt. Diese Verbindung stellt erst DMARC her.

DMARC: die Klammer und die Richtlinie

Domain-based Message Authentication, Reporting and Conformance verbindet SPF und DKIM und schließt die entscheidende Lücke: Es verlangt, dass die Domain, die SPF oder DKIM bestätigt hat, zur sichtbaren Absenderadresse passt (das nennt sich Ausrichtung, Alignment). Damit greift der Schutz genau dort, wo der Empfänger hinschaut. Vor allem aber legt DMARC eine Richtlinie fest, was der empfangende Server mit einer Mail tun soll, die die Prüfung nicht besteht:

• none. Nichts tun, nur berichten. Der Einstieg, um zu sehen, was passiert, ohne Mails zu verlieren.
• quarantine. Verdächtige Mails in den Spam-Ordner.
• reject. Gefälschte Mails ganz ablehnen. Das Ziel, denn nur so wird der Missbrauch der eigenen Domain wirklich verhindert.

Der zweite Teil von DMARC ist das Reporting: Die empfangenden Server schicken täglich Berichte an eine hinterlegte Adresse, die zeigen, wer im Namen deiner Domain gesendet hat und ob die Mails die Prüfung bestanden. Diese Berichte sind für das Blue Team wertvoll, weil sie Missbrauchsversuche und vergessene legitime Absender sichtbar machen.

Die eigene Domain absichern

Der Weg zur abgesicherten Domain hat eine klare Reihenfolge, und der häufigste Fehler ist, zu schnell auf reject zu gehen und dabei legitime Mail zu verlieren.

1. SPF und DKIM einrichten. Alle legitimen Sendewege der Domain erfassen, den eigenen Mailserver, aber auch Newsletter-Dienste, das CRM, die Rechnungssoftware, und sie in SPF und DKIM aufnehmen. Diese Bestandsaufnahme ist die eigentliche Arbeit.
2. DMARC mit none starten. Zuerst die Richtlinie auf none und die Reporting-Adresse setzen. Dann kommen die Berichte, ohne dass eine Mail verloren geht.
3. Die Berichte auswerten. Aus den Berichten ergibt sich, welche legitimen Absender noch fehlen und wer die Domain missbraucht. Werkzeuge, die die XML-Berichte lesbar aufbereiten, helfen dabei. Erst wenn alle legitimen Wege sauber authentifiziert sind, ist der nächste Schritt sicher.
4. Auf quarantine, dann reject. Schrittweise die Richtlinie verschärfen, erst quarantine, dann reject, und dabei die Berichte im Blick behalten. Am Ende steht reject, und niemand kann mehr im Namen der Domain phishen.

Eine Domain auf reject ist eine der wirksamsten Maßnahmen gegen den Missbrauch der eigenen Marke für Phishing, und sie schützt zugleich Kunden und Partner, die sonst gefälschte Mails in deinem Namen bekommen würden. Auch nicht genutzte Domains gehören auf reject, damit niemand sie für Phishing missbraucht.

Eingehende Mails: die Ergebnisse lesen

Der zweite, für die Erkennung wichtigere Teil: Bei jeder eingehenden Mail schreibt der empfangende Server das Ergebnis der Authentifizierung in die Kopfzeilen, meist in eine Zeile namens Authentication-Results. Dort steht, ob SPF, DKIM und DMARC bestanden wurden. Genau das prüft die Erstanalyse im Phishing-Playbook:

• DMARC fail bei einer Mail, die von einer bekannten Domain zu kommen scheint, ist ein starkes Signal für eine Fälschung. Wenn eine Mail vorgibt, von einer großen, gut konfigurierten Domain zu stammen, aber die DMARC-Prüfung nicht besteht, ist sie mit hoher Wahrscheinlichkeit gefälscht.
• SPF- und DKIM-Ergebnisse zusammen betrachten. Eine legitime Mail besteht in der Regel mindestens eine der beiden Prüfungen mit Ausrichtung. Fehlen beide, ist Vorsicht geboten.
• Auf ähnlich aussehende Domains achten. DMARC schützt nur die exakte Domain. Ein Angreifer, der eine täuschend ähnliche Domain registriert (deiner-firrna.de statt deiner-firma.de), besteht dort seine eigene DMARC-Prüfung. Diese Nachbardomains erkennt kein DMARC, sondern nur die Wachsamkeit und ein Abgleich mit bekannten Mustern.

Aus diesen Ergebnissen lässt sich eine Erkennungsregel im SIEM oder im Mail-Gateway bauen: Mails mit DMARC fail, die eine bekannte Domain vortäuschen, werden markiert oder blockiert. Das fängt einen erheblichen Teil des einfachen Spoofings, bevor es den Nutzer erreicht, und ergänzt die menschliche Erkennung aus dem Beitrag zu Social Engineering und Meldewegen.

Die Grenzen

SPF, DKIM und DMARC schützen vor dem Vortäuschen einer exakten Domain, mehr nicht. Sie helfen nicht gegen Phishing von einer ähnlich aussehenden Domain, nicht gegen ein kompromittiertes echtes Konto, das legitim authentifizierte Phishing-Mails verschickt, und nicht gegen Quishing oder AiTM-Angriffe, die den Nutzer auf eine externe Seite locken. Sie sind ein wichtiger Baustein der Mail-Sicherheit, aber kein vollständiger Phishing-Schutz. Ihr größter Wert liegt darin, das einfachste und häufigste Spoofing zu unterbinden und bei jeder eingehenden Mail ein prüfbares Signal zu liefern.

Fazit

SPF, DKIM und DMARC sind die drei Standards, die E-Mail die fehlende Absenderprüfung nachrüsten. Für ein Blue Team sind sie zweierlei: eine Prävention, die die eigene Domain mit einer Richtlinie auf reject vor Missbrauch schützt, und eine Erkennung, die bei jeder eingehenden Mail über die Authentifizierungsergebnisse zeigt, ob der Absender echt ist. Wer die eigene Domain schrittweise über none und quarantine auf reject bringt und die Ergebnisse eingehender Mails zur Erkennung nutzt, hat das einfache Spoofing weitgehend ausgeschaltet. Für ein Blue Team gehört das Lesen dieser drei Zeilen zum Handwerk, weil sie bei fast jeder Phishing-Analyse die erste, schnelle Antwort auf die Frage geben, ob der Absender gefälscht ist.