SPF, DKIM, DMARC: Der umfassende Leitfaden zur E-Mail-Sicherheit

E-Mails sind nach wie vor der häufigste Einfallstor für Angriffe auf Unternehmen: Phishing, CEO-Betrug, gefälschte Überweisungsaufträge, Verbreitung von Ransomware. Diese Anfälligkeit ist zum Teil auf eine ursprüngliche Schwachstelle zurückzuführen. Das 1982 entwickelte SMTP-Protokoll sah weder eine Verschlüsselung noch eine Überprüfung des Absenders vor. Auch heute noch kann jeder Server eine Nachricht versenden, wobei die Adresse einer anderen Domain angezeigt wird.

Um diese Schwachstellen zu beheben, hat die IETF (Internet Engineering Task Force) im Laufe von vierzig Jahren eine Reihe sich ergänzender Mechanismen standardisiert: SPF, DKIM und DMARC zur Authentifizierung, STARTTLS, MTA-STS und DANE zur Verschlüsselung sowie DNSSEC zur Absicherung der DNS-Infrastruktur, auf der sie alle basieren. Dieser Leitfaden erläutert, wozu jeder dieser Standards dient, wie sie miteinander verzahnt sind und welche Entscheidungen sie für einen Sicherheitsbeauftragten oder eine Führungskraft mit sich bringen. Es handelt sich hierbei nicht um ein Konfigurationshandbuch, sondern um einen Rahmen zum Verständnis und zur Entscheidungsfindung.

Die Sicherheit von E-Mails beruht auf zwei untrennbaren Säulen

Der Schutz eines E-Mail-Systems läuft darauf hinaus, zwei unterschiedliche Fragen zu beantworten.

Der erste Punkt betrifft die Vertraulichkeit der Übertragung: Kann eine E-Mail auf dem Weg vom Server des Absenders zum Server des Empfängers abgefangen, gelesen oder verändert werden? Hier kommt die Verschlüsselung während der Übertragung zum Tragen.

Der zweite Punkt betrifft die Authentizität des Absenders: Stammt die Nachricht tatsächlich von der angegebenen Domain, und ist ihr Inhalt unverändert geblieben? Dies ist die Aufgabe der Authentifizierungsmechanismen.

Diese beiden Säulen heben sich nicht gegenseitig auf. Eine perfekt verschlüsselte E-Mail, die jedoch von einem Betrüger versendet wird, stellt nach wie vor einen erfolgreichen Social-Engineering-Angriff dar. Umgekehrt kann eine perfekt authentifizierte E-Mail, die jedoch unverschlüsselt übertragen wird, von einem Akteur im Netzwerk gelesen werden. Eine Organisation, die nur in eine der beiden Säulen investiert, lässt eine Lücke bei der anderen offen.

Acht Standards erfüllen jeweils eine bestimmte Funktion

Die Abkürzungen nehmen zu, doch jeder Standard erfüllt eine klare Funktion. Die nachstehende Tabelle fasst diese zusammen; in den folgenden Abschnitten werden sie näher erläutert.

SPF, DKIM und DMARC verhindern Identitätsbetrug

Das SMTP-Protokoll ermöglicht es, im Feld „Von:“, das dem Empfänger angezeigt wird, eine beliebige Adresse einzutragen. Genau diese Freiheit machen sich Phishing-Kampagnen und Betrugsversuche im Stil des „CEO-Betrugs“ zunutze. Drei Standards, die zusammenwirken, ermöglichen es, dem ein Ende zu setzen.

SPF gibt die Server an, die zum Senden berechtigt sind

SPF (Sender Policy Framework) ist ein im DNS der Domain veröffentlichter Eintrag, der die Server und Dienste auflistet, die berechtigt sind, E-Mails in deren Namen zu versenden: das E-Mail-System der Organisation, aber auch das Newsletter-Tool, das CRM oder die Rechnungsstellungsplattform. Der Empfängerserver überprüft, ob die IP-Adresse des Absenders in dieser Liste enthalten ist.

SPF weist drei Einschränkungen auf, die jeder Sicherheitsbeauftragte kennen muss. Es überprüft die technische Adresse im Nachrichtenkopf und nicht die für den Benutzer sichtbare „Von:“-Adresse. Es schlägt fehl, sobald eine E-Mail automatisch weitergeleitet wird, da der Weiterleitungsserver nicht in der Liste aufgeführt ist. Schliesslich begrenzt der Standard die Anzahl der zur Überprüfung eines Eintrags erforderlichen DNS-Abfragen auf zehn: Eine Organisation, die zahlreiche Versanddienstleister einsetzt, überschreitet diesen Schwellenwert schnell, und ihr SPF wird dann ungültig, ohne dass dies jemand bemerkt.

DKIM signiert jede Nachricht

DKIM (DomainKeys Identified Mail) fügt jeder E-Mail eine kryptografische Signatur hinzu. Der Absenderserver signiert den Inhalt und die wichtigsten Kopfzeilen (Absender, Datum, Betreff) mit einem privaten Schlüssel; der Empfänger ruft den entsprechenden öffentlichen Schlüssel aus dem DNS ab und überprüft die Signatur. Wurde die Nachricht unterwegs verändert oder stammt sie nicht vom Inhaber des Schlüssels, schlägt die Überprüfung fehl.

Im Gegensatz zu SPF wird die DKIM-Signatur mit der Nachricht weitergeleitet und bleibt auch bei den meisten Weiterleitungen erhalten. Was die Governance betrifft, verdienen zwei Punkte besondere Beachtung: die Länge der Schlüssel (2048 Bit sind heute das sinnvolle Minimum für RSA) und deren regelmässige Erneuerung, die denselben Sicherheitsgrundsätzen unterliegt wie die anderen kryptografischen Geheimnisse der Organisation.

DMARC erteilt den Befehl zum Blockieren

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist das Element, das SPF und DKIM in einen wirksamen Schutz verwandelt. Für sich genommen stellen diese beiden Mechanismen zwar eine Anomalie fest, geben dem Empfänger jedoch keine Anweisung, wie er damit umgehen soll. DMARC schliesst diese Lücke mit drei Funktionen.

Der erste Mechanismus ist die Übereinstimmung. DMARC verlangt, dass die durch SPF oder DKIM validierte Domain mit der im Feld „Von:“ angezeigten Domain übereinstimmt. Diese Überprüfung verhindert letztendlich die sichtbare Identitätsfälschung. Es reicht aus, wenn einer der beiden Mechanismen gültig und abgeglichen ist, damit die Nachricht durchgelassen wird. Der Abgleich kann locker (eine Subdomain wird akzeptiert) oder streng (exakte Übereinstimmung) sein.

Die zweite ist die Richtlinie, die der Eigentümer der Domäne aus drei Stufen auswählt:

• p=none (Beobachtung): Nicht konforme E-Mails werden wie gewohnt zugestellt. Dieser Modus dient ausschliesslich dazu, den legitimen Datenverkehr vor der Verschärfung der Sicherheitsmassnahmen zu erfassen.
• p = Quarantäne (Isolierung): Nicht konforme E-Mails werden in den Spam-Ordner verschoben.
• p=reject (Ablehnung): Nicht konforme E-Mails werden bereits abgelehnt, bevor sie den Posteingang des Empfängers erreichen.

Der dritte Punkt betrifft die Berichterstattung. E-Mail-Anbieter senden dem Domaininhaber täglich zusammengefasste Berichte, aus denen hervorgeht, welche Server E-Mails in seinem Namen versendet haben und mit welchem Ergebnis. Diese Berichte decken sowohl Identitätsdiebstahlversuche als auch legitime Dienste auf, die bei der Bestandsaufnahme übersehen wurden. Einzelne Fehlerberichte, die ebenfalls im Standard vorgesehen sind, werden hingegen von den grossen Anbietern aus Datenschutzgründen nur in sehr geringem Umfang übermittelt.

Der entscheidende Punkt für einen Entscheidungsträger lässt sich in einem Satz zusammenfassen: Eine Domäne mit dem Status „p=none“ ist nicht geschützt. Sie wird lediglich überwacht. Nur die Stufen „quarantäne“ und „ablehnen“ verhindern die Zustellung betrügerischer E-Mails.

DMARCbis: Was sich im Jahr 2026 ändert

Die 2015 veröffentlichte erste Version von DMARC (RFC 7489) hatte lediglich informativen Charakter. Im Mai 2026 veröffentlichte die IETF ihre überarbeitete Fassung, bekannt unter dem Namen DMARCbis, in drei Dokumenten: RFC 9989 für das Protokoll, RFC 9990 für aggregierte Berichte und RFC 9991 für Fehlerberichte. Damit wird DMARC erstmals zu einem offiziellen IETF-Standard (Proposed Standard).

Für eine bereits ausgestattete Organisation verläuft der Übergang reibungslos: Die bestehenden Datensätze behalten ihre Gültigkeit. Die wesentlichen Änderungen sind folgende:

• Das Tag „pct“, mit dem die Richtlinie auf einen bestimmten Prozentsatz der Nachrichten angewendet werden konnte, wird zugunsten eines binären Testmodus (Tag „t“) abgeschafft;
• Ein neues „np“-Tag ermöglicht es, eine Richtlinie für nicht existierende Subdomänen festzulegen – eine Sicherheitslücke, die Angreifer ausnutzten, indem sie plausible Subdomänen erfanden;
• Die Ermittlung der organisatorischen Domäne hängt nicht mehr von einer externen Liste (der „Public Suffix List“) ab, sondern erfolgt durch eine direkte Abfrage des DNS;
• Der Standard warnt nun vor der „p=reject“-Richtlinie für Domänen, deren Nutzer Beiträge in Mailinglisten verfassen, es sei denn, das Risiko wurde bewertet und unter Kontrolle gebracht.

Über die technische Seite hinaus ist die Änderung des Status von Bedeutung: DMARC ist nicht mehr nur eine empfohlene bewährte Vorgehensweise, sondern ein Referenzstandard. Die Anforderungen grosser E-Mail-Anbieter an Absender mit hohem E-Mail-Aufkommen sowie die Erwartungen regulatorischer Rahmenwerke wie NIS2 stützen sich nun auf einen feststehenden Standard.

STARTTLS, MTA-STS und DANE machen die Verschlüsselung obligatorisch

Die zweite Säule betrifft die Übertragung. Wenn eine E-Mail den Server des Absenders verlässt, wird sie über das Internet zum Server des Empfängers weitergeleitet. Ohne Verschlüsselung wird sie im Klartext übertragen und kann von jedem Akteur gelesen werden, der den Datenverkehr überwachen kann.

STARTTLS verschlüsselt, jedoch nur, wenn niemand Einwände erhebt

STARTTLS ermöglicht es zwei E-Mail-Servern, eine ursprünglich unverschlüsselte Verbindung auf eine TLS-verschlüsselte Verbindung umzustellen. Es ist mittlerweile sehr weit verbreitet.

Die Schwachstelle ist struktureller Natur: Die Verschlüsselung erfolgt opportunistisch. Wenn der Zielserver dies nicht ankündigt, erfolgt die Übertragung im Klartext, ohne dass ein Fehler oder eine Warnung ausgegeben wird. Ein Angreifer, der sich zwischen den beiden Servern befindet, kann daher diese Ankündigung unterdrücken und eine unverschlüsselte Übertragung erzwingen: Dies ist der sogenannte „Downgrade“-Angriff. STARTTLS schützt vor passivem Abhören, nicht jedoch vor einem aktiven Angreifer.

Hinzu kommt eine weitere Konfigurationsanforderung: Die Server müssen veraltete Protokollversionen ablehnen und dürfen nur TLS 1.2 oder TLS 1.3 akzeptieren.

MTA-STS schreibt die Verschlüsselung über das Internet vor

MTA-STS (Mail Transfer Agent Strict Transport Security) ermöglicht es einer Domain, öffentlich zu erklären, dass ihre Server eine verschlüsselte Verbindung mit einem gültigen Zertifikat verlangen. Diese Richtlinie wird auf einer gesicherten Website veröffentlicht und im DNS bekannt gegeben. Ein kompatibler Absenderserver ruft diese Informationen ab und lehnt die Übermittlung der E-Mail ab, wenn die Verschlüsselung nicht ordnungsgemäss hergestellt werden kann.

MTA-STS hat den Vorteil, dass es kein DNSSEC erfordert, wodurch es für die meisten Organisationen zugänglich ist. Google und Microsoft setzen es für ihre E-Mail-Dienste ein. Seine Einschränkung: Die Richtlinie wird von den Absendern zwischengespeichert, und der allererste Kontakt mit einer Domain bleibt ungeschützt.

DANE schafft Vertrauen im DNS

DANE (DNS-based Authentication of Named Entities) geht noch einen Schritt weiter. Der Domaininhaber veröffentlicht in seinem DNS den Fingerabdruck des Zertifikats seines E-Mail-Servers. Ein kompatibler Absenderserver überprüft, ob das vorgelegte Zertifikat mit diesem Fingerabdruck übereinstimmt; fehlt die Verschlüsselung oder ist das Zertifikat nicht konform, wird die E-Mail zurückgestellt, anstatt weitergeleitet zu werden.

DANE verhindert somit sowohl die Herabstufung als auch die Verwendung gefälschter Zertifikate, selbst wenn diese von einer kompromittierten Zertifizierungsstelle ausgestellt wurden. Es stützt sich jedoch vollständig auf DNSSEC: Ohne Signatur der DNS-Antworten könnte ein Angreifer den veröffentlichten Fingerabdruck fälschen. Microsoft stellt es als Massstab für die Sicherung des SMTP-Verkehrs dar und unterstützt es in Exchange Online sowohl für eingehende als auch für ausgehende Daten.

Das Hauptrisiko von DANE ist operativer Natur: Bei der Erneuerung eines Zertifikats muss der im DNS veröffentlichte Fingerabdruck koordiniert aktualisiert werden. Ein Fehler blockiert den Empfang von E-Mails von Absendern, die DANE anwenden.

MTA-STS oder DANE: Eine Wahl, die gar keine ist

Beide Mechanismen können auf derselben Domain nebeneinander bestehen, und dies ist die empfehlenswerteste Vorgehensweise: Jeder Absender wendet den Mechanismus an, den er unterstützt. Die Entscheidung hängt vielmehr von der Reihenfolge der Einführung ab. MTA-STS lässt sich schnell implementieren und deckt die grossen Anbieter ab. DANE bietet eine stärkere Garantie, setzt jedoch voraus, dass DNSSEC bereits eingeführt und beherrscht wird.

In beiden Fällen ergänzt TLS-RPT das System: Es ermöglicht den Empfang von Berichten über Verschlüsselungsfehler, die von den Absendern festgestellt wurden, und somit die Erkennung einer Störung oder eines Angriffs.

Was die Verschlüsselung während der Übertragung nicht schützt

STARTTLS, MTA-STS und DANE schützen E-Mails während der Übertragung zwischen Servern. Sie schützen sie jedoch weder auf dem Computer des Absenders noch auf den Zwischenservern noch nach der Speicherung im Postfach des Empfängers. Um sicherzustellen, dass nur der Empfänger eine Nachricht lesen kann, ist eine End-to-End-Verschlüsselung erforderlich, wie beispielsweise S/MIME oder OpenPGP. Diese Lösungen fallen unter eine andere Entscheidungsebene (Verwaltung von Benutzerzertifikaten, Interoperabilität mit Partnern) und ersetzen nicht die hier beschriebenen Standards.

DNSSEC sichert die Grundlage, auf der alles beruht

Alle in diesem Leitfaden vorgestellten Mechanismen veröffentlichen ihre Informationen im DNS: Liste der autorisierten Server für SPF, öffentliche Schlüssel für DKIM, Richtlinien für DMARC, Zertifikats-Fingerabdrücke für DANE. Kann ein Angreifer die DNS-Antworten fälschen, kann er das gesamte System umgehen.

DNSSEC (DNS Security Extensions) versieht DNS-Antworten mit einer kryptografischen Signatur und ermöglicht es, zu überprüfen, ob diese tatsächlich vom rechtmässigen Inhaber der Domain stammen. Es ist für DANE unverzichtbar und verstärkt alle anderen Standards. Seine Einführung hängt weitgehend von der Registrierungsstelle und dem DNS-Anbieter ab; diese Frage sollte bei jedem Anbieter ausdrücklich gestellt werden.

Die Fallstricke, die zur Scheitern von Implementierungen führen

Die meisten Domänen sind nicht etwa aus Unkenntnis der Standards unzureichend geschützt, sondern weil die Umsetzung auf halbem Wege ins Stocken gerät. Fünf Situationen treten regelmässig auf.

Auf unbestimmte Zeit im Status „p=none“ verbleiben. Die Beobachtungsphase ist zwar notwendig, wird jedoch zu einer Falle, wenn sie sich aufgrund fehlender Ressourcen für die Auswertung der Berichte in die Länge zieht. Die Domain weist dann eine DMARC-Konfiguration auf, ohne dass ein tatsächlicher Schutz besteht.

Verzichten Sie auf Dienste von Drittanbietern. Marketing-Tools, HR-Plattformen, Rechnungssoftware: Jeder Dienstleister, der E-Mails im Namen Ihrer Organisation versendet, muss im SPF-Eintrag angegeben werden und sollte idealerweise mit DKIM signiert sein. Eine unvollständige Auflistung führt dazu, dass legitime E-Mails im „Reject“-Status abgelehnt werden, und führt häufig dazu, dass man auf frühere Verfahren zurückgreifen muss.

Domains, von denen keine E-Mails versendet werden, sollten ignoriert werden. Sekundäre Domains, ehemalige Marken und Domains, die zum Schutz vor Typosquatting reserviert wurden, sind ideale Ziele, da niemand deren Nutzung überwacht. Sie müssen ausdrücklich erklären, dass kein Server berechtigt ist, in ihrem Namen E-Mails zu versenden (SPF ohne autorisierten Server, DMARC mit „p=reject“ und, sofern möglich, einen Eintrag, der angibt, dass sie keine E-Mails empfangen).

Umleitungen und Mailinglisten ignorieren. Diese Prozesse verändern die Nachrichten oder ihren Übertragungsweg, was dazu führen kann, dass SPF und DKIM fehlschlagen. Der ARC-Standard (Authenticated Received Chain) ermöglicht es Zwischenstellen, die Authentifizierungsergebnisse zu bewahren, doch seine Unterstützung ist nach wie vor uneinheitlich. Dies ist einer der Gründe, warum DMARCbis dazu aufruft, dieses Risiko zu bewerten, bevor eine Ablehnung erzwungen wird.

DANE ohne Erneuerungsprozess bereitstellen. Ohne Abstimmung zwischen dem Team, das die Zertifikate verwaltet, und dem Team, das das DNS verwaltet, kann eine routinemässige Erneuerung den E-Mail-Empfang unterbrechen.

Von p=none bis p=reject: Ein Weg zur Einführung

Der Übergang zu einem wirksamen Schutz erfolgt nach einem bewährten Ablauf, der sich je nach Komplexität der Organisation in der Regel über mehrere Wochen bis hin zu einigen Monaten erstreckt.

1. Erstellen Sie eine Übersicht über alle Dienste, die im Namen jeder Domain der Organisation E-Mails versenden, einschliesslich inaktiver Domains.
2. Veröffentlichen Sie die SPF-Einträge und aktivieren Sie DKIM für jeden legitimen Dienst.
3. Veröffentlichen Sie DMARC mit „p=none“ und einer Adresse für den Empfang von Berichten und richten Sie die entsprechenden Tools für deren Analyse ein.
4. Korrigieren Sie die berechtigten Transaktionen, die fehlgeschlagen sind, bis in den Berichten nur noch betrügerische oder unbekannte Nutzungen angezeigt werden.
5. In den Status „p=quarantine“ versetzen, gegebenenfalls unter Verwendung des von DMARCbis vorgesehenen Testmodus, anschliessend in den Status „p=reject“.
6. Sichern Sie die Übertragung zunächst mit MTA-STS und TLS-RPT und anschliessend mit DANE, sobald DNSSEC eingerichtet ist.
7. Fortführung: Jeder neue Versanddienstleister muss vor seiner Inbetriebnahme in das System integriert werden, und die Berichte müssen langfristig weiterverfolgt werden.

Häufig gestellte Fragen zur E-Mail-Sicherheit