E-Mail-Authentifizierung: SPF, DKIM und DMARC

Das grundlegende SMTP-Protokoll, das in den 1970er-Jahren entwickelt wurde, verfügt über keine integrierte Authentifizierung des Absenders. Jeder Mailserver kann vorgeben, E-Mails von einer beliebigen Domäne zu senden – eine Technik namens E-Mail-Spoofing. Angreifer nutzen dies, um Phishing-E-Mails zu versenden, die scheinbar von legitimen Organisationen stammen, etwa Ihrer Bank, Ihrem CEO oder einem bekannten Anbieter. Um dieses Problem zu beheben, wurden drei DNS-basierte Standards zur E-Mail-Authentifizierung entwickelt: SPF, DKIM und DMARC. Jeder behandelt einen anderen Aspekt des Spoofing-Problems; gemeinsam eingesetzt sind sie am wirksamsten.

SPF ist ein DNS-TXT-Record, der festlegt, welche Mailserver berechtigt sind, E-Mails im Namen einer Domäne zu versenden. Wenn ein empfangender Mailserver eine Nachricht erhält, die angeblich von example.com stammt, ruft er den SPF-Record für example.com ab und prüft, ob die IP-Adresse des sendenden Servers dort aufgeführt ist. Ist die IP-Adresse nicht autorisiert, kann die Nachricht als Spam markiert oder abgewiesen werden. SPF prüft die Envelope-From-Adresse (den SMTP-Befehl MAIL FROM), nicht den für Benutzer sichtbaren From-Header.

SPF hat zwei wesentliche Einschränkungen. Erstens gilt: Weiterleitung macht SPF ungültig. Wenn eine E-Mail weitergeleitet wird, ist die IP-Adresse des weiterleitenden Servers nicht im SPF-Record der ursprünglichen Domäne enthalten, sodass SPF bei legitimer weitergeleiteter E-Mail fehlschlägt. Zweitens authentifiziert SPF nur den Envelope From, der für Benutzer unsichtbar ist, und nicht den in E-Mail-Clients sichtbaren From-Header. Angreifer können den sichtbaren From-Header weiterhin fälschen und zugleich einen SPF-bestandenen Envelope From verwenden – deshalb ist SPF allein nicht ausreichend. DKIM und DMARC schließen diese Lücken.

DKIM fügt ausgehenden E-Mails eine kryptografische Signatur hinzu. Der sendende Mailserver verwendet einen privaten Schlüssel, um bestimmte E-Mail-Header und den Nachrichtentext zu signieren, und fügt einen DKIM-Signature-Header hinzu. Der öffentliche Schlüssel wird als DNS-TXT-Record unter einer Selector-Subdomäne veröffentlicht. Empfangende Server rufen den öffentlichen Schlüssel ab und überprüfen die Signatur. Dadurch wird bestätigt, dass die E-Mail während der Übertragung nicht manipuliert wurde und von einem Server stammt, der Zugriff auf den privaten Schlüssel hatte. Anders als SPF bleiben DKIM-Signaturen bei der Weiterleitung erhalten, da sie in den E-Mail-Headern enthalten sind.

DKIM verwendet Selectoren, um mehrere öffentliche Schlüssel für eine Domäne gleichzeitig zu ermöglichen – beispielsweise für den Betrieb mehrerer Maildienste (Google Workspace und eine Marketingplattform) oder für eine unterbrechungsfreie Schlüsselrotation. Der Name des Selectors ist im DKIM-Signature-Header enthalten, damit empfangende Server wissen, welchen DNS-Record sie abfragen müssen. Unternehmen sollten DKIM-Schlüssel jährlich oder bei Verdacht auf eine Kompromittierung rotieren. Schlüssellänge: Es werden RSA-Schlüssel mit mindestens 2048 Bit empfohlen; 1024-Bit-Schlüssel gelten als veraltet und können mit moderner Rechenleistung gebrochen werden.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) baut auf SPF und DKIM auf und ergänzt diese um eine Alignment-Prüfung (die Domäne im sichtbaren From-Header muss mit der über SPF oder DKIM authentifizierten Domäne übereinstimmen) sowie eine Richtlinie, die empfangenden Servern vorgibt, wie mit nicht bestandenen Prüfungen umzugehen ist. DMARC-Richtlinien sind none (nur überwachen), quarantine (in den Spamordner zustellen) oder reject (nicht zustellen). DMARC ermöglicht außerdem zusammengefasste Berichte (RUA) und forensische Berichte (RUF), die an den Domäneninhaber zurückgesendet werden und Transparenz darüber schaffen, wer E-Mails in seinem Namen versendet.

Ausrichtung macht DMARC zu einem wirksamen Schutz gegen Spoofing von Headern. Bei der SPF-Ausrichtung muss die Domain im SMTP-Envelope-From mit der Domain im sichtbaren From-Header übereinstimmen. Bei der DKIM-Ausrichtung muss die signierende Domain (d= in DKIM-Signature) mit der Domain im From-Header übereinstimmen. Im strikten Modus müssen die Domains exakt übereinstimmen. Im entspannten Modus sind Subdomains zulässig. Eine E-Mail besteht DMARC, wenn sie SPF ODER DKIM mit korrekter Ausrichtung besteht – sie muss nicht beides bestehen. Diese Kombination schließt die Lücke, die SPF allein beim Spoofing sichtbarer Header offenlässt.

Organisationen sollten DMARC schrittweise einführen, um eine Beeinträchtigung legitimer E-Mails zu vermeiden. Phase 1: SPF und DKIM für alle Mailströme einrichten. Phase 2: Einen DMARC-Eintrag mit p=none und RUA-Reporting veröffentlichen. Analysieren Sie die Reports (Tools: DMARC Analyzer, dmarcian), um innerhalb von 2–4 Wochen alle legitimen Versandquellen zu ermitteln. Phase 3: Zu p=quarantine; pct=10 wechseln und pct schrittweise auf 100 % erhöhen. Phase 4: Zu p=reject wechseln, sobald alle legitimen Mailströme die Prüfung bestehen. Wenn Sie zu reject wechseln, bevor alle Mailströme ermittelt wurden, werden legitime E-Mails abgewiesen.

BIMI ist ein aufstrebender Standard, der auf DMARC aufbaut. Wenn für eine Domain eine DMARC-Richtlinie mit quarantine oder reject festgelegt ist, können E-Mail-Clients (Gmail, Apple Mail) das verifizierte Logo der Marke neben dem Namen des Absenders im Posteingang anzeigen. Für BIMI ist ein Verified Mark Certificate (VMC) eines zugelassenen Ausstellers erforderlich, das den Besitz der Marke bestätigt. BIMI ist zwar noch nicht Bestandteil der Security+-Prüfung, zeigt aber die Entwicklungsrichtung der E-Mail-Authentifizierung: Verifizierte Absender sollen auf einen Blick visuell von gefälschten Absendern unterscheidbar sein.

Die drei Standards bilden ein vollständiges System zur E-Mail-Authentifizierung. SPF überprüft, ob der sendende Server vom Domaininhaber autorisiert ist. DKIM überprüft die Integrität der Nachricht und bestätigt, dass die sendende Organisation über den privaten Schlüssel verfügt. DMARC verknüpft beide Verfahren mit dem sichtbaren From-Header, setzt bei Prüfungsfehlern eine Richtlinie durch und stellt Reporting bereit. Kein einzelner Standard ist ausreichend: SPF allein verhindert kein Spoofing des sichtbaren Headers, DKIM allein schreibt keine Zurückweisung fehlerhafter Nachrichten vor, und DMARC allein kann ohne SPF oder DKIM keine Prüfung durchführen. Für einen vollständigen Schutz vor Domain-Spoofing müssen alle drei Standards gemeinsam eingesetzt werden.

Eine praktische Maßnahme zur mehrschichtigen Abwehr von Phishing und BEC besteht darin, jeder Nachricht, die von außerhalb der Organisation stammt, ein Warnbanner für externe E-Mails hinzuzufügen. Dieses Banner – typischerweise vom SEG eingefügt – weist Mitarbeitende darauf hin, dass eine E-Mail von einem externen Absender stammt, selbst wenn der Anzeigename wie der eines Kollegen oder einer Führungskraft wirkt. Banner sind besonders wirksam, um BEC-Versuche zu kennzeichnen, bei denen der Angreifer eine ähnlich aussehende Domain oder ein gefälschtes Anzeigenamen-Spoofing verwendet. Das Banner sollte sich visuell deutlich abheben (farbiger Kopf- oder Fußbereich) und Anweisungen zum Melden verdächtiger Nachrichten enthalten.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: SPF verwendet DNS-TXT-Einträge, um sendende IPs zu autorisieren, prüft jedoch nur den Envelope-From und nicht den sichtbaren Header; DKIM fügt kryptografische Signaturen hinzu, die die Nachrichtenintegrität überprüfen und Weiterleitungen überstehen; und DMARC verknüpft SPF und DKIM über Ausrichtungsprüfungen mit dem sichtbaren From-Header und bietet neben Reporting eine durchsetzbare Richtlinie (none/quarantine/reject). Als Nächstes behandeln wir Secure Email Gateways und Maßnahmen gegen Spam.