E-Mail-Authentizität: SPF, DKIM, DMARC, MTA-STS, DANE im Zusammenspiel

Problem

E-Mail ist das älteste in Betrieb befindliche offene Standardprotokoll, das flächendeckend für Geschäftsvorgänge genutzt wird. Bemerkenswert in diesem Kontext ist, dass es damals strukturell ohne Authentizitätsmechanismus entworfen wurde. SMTP (Simple Mail Transfer Protocol, das Protokoll, mit dem Mailserver Nachrichten austauschen) akzeptiert im Grundzustand einen beliebigen MAIL FROM, also eine beliebige Absenderadresse in der Signatur. Wie wenn man den Absender handschriftlich auf einen Briefumschlag schreibt, der dann per Post kommt.

Fünf sich ergänzende Standards adressieren unterschiedliche Aspekte dieses Problems. Nur die Kombination aller fünf ergibt ein belastbares Bild; die Weglassung einer Schicht hebelt die nächste aus.

Für wen ist das? Für alle, die E-Mail unter eigener Domain versenden und vor Fälschung schützen wollen.

Kurze Antwort

Fünf DNS-basierte Standards greifen ineinander. SPF, DKIM und DMARC sichern die Absender-Authentizität (wirklich von dieser Domain?), MTA-STS und DANE sichern den Transport (wirklich verschlüsselt und an den richtigen Server?):

• SPF (RFC 7208): legt fest, welche IP-Adressen für eine Domain mailen dürfen. Prüft den Envelope-Sender (die technische Absenderadresse hinter den Kulissen, nicht die sichtbare).
• DKIM (RFC 6376): signiert relevante Header und den Body mit einem privaten Schlüssel; der öffentliche Schlüssel steht im DNS.
• DMARC (RFC 7489): koppelt SPF und DKIM an den sichtbaren From-Header und definiert eine Policy (Regel) für Nicht-Konformität.
• MTA-STS (RFC 8461): signalisiert, dass Mails an diese Domain nur über authentifiziertes TLS (verschlüsselten Transport) anzunehmen sind.
• DANE (RFC 7672): hinterlegt erwartete TLS-Zertifikate per DNSSEC (kryptografisch signiertes DNS), unabhängig von der Web-PKI.

Ohne DMARC bleiben SPF und DKIM Detail-Werkzeuge ohne gemeinsame Durchsetzung; ohne MTA-STS oder DANE ist der verschlüsselte Transport nur ein Vorschlag, den ein Angreifer entfernen kann.

Tiefgang

SPF: IP-Whitelist für die sendende Domain

Ein SPF-Eintrag (Sender Policy Framework) ist ein DNS-TXT-Record am Scheitel der Domain:

example.de. IN TXT "v=spf1 ip4:203.0.113.5 include:_spf.google.com -all"

Der Empfänger-Server prüft, ob die einliefernde IP in der SPF-Liste vorkommt. Bei -all wird ein Nichttreffer als hart ungültig gewertet, bei ~all als weich, bei ?all neutral.

Grenzen:

• SPF prüft den Envelope Sender (MAIL FROM), nicht den sichtbaren From-Header. Das macht SPF allein für Phishing-Schutz unbrauchbar, weil das Opfer nur den sichtbaren Header sieht.
• SPF bricht bei Weiterleitungen (Forwarding), weil die weiterleitende IP nicht in der ursprünglichen SPF-Liste steht. Lösungen wie SRS (Sender Rewriting Scheme, das Umschreiben der Absenderadresse beim Weiterleiten) existieren, sind aber nicht flächendeckend implementiert.

DKIM: kryptografische Signatur der Mail

DKIM (DomainKeys Identified Mail) signiert einen konfigurierbaren Satz von Headern (typischerweise From, Subject, Date, To, und der Body-Hash, eine kurze Prüfsumme des Nachrichtentexts) mit einem privaten RSA- oder Ed25519-Schlüssel. Der öffentliche Schlüssel liegt als TXT-Record unter dem Selector (einem frei wählbaren Namen, der den passenden Schlüssel benennt):

mail._domainkey.example.de. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

Die Mail trägt einen DKIM-Signature:-Header mit dem Selector und der Signatur. Der Empfänger holt den Public Key, verifiziert und weiß: der Inhalt stammt aus dieser Domain und ist nicht verändert.

Grenzen:

• DKIM ist robust gegen Forwarding (die Signatur bleibt gültig, solange die signierten Header nicht verändert werden).
• DKIM allein sagt nichts über den Envelope-Sender und koppelt nicht an den sichtbaren From-Header. Das macht DMARC nötig.

DMARC: die Klammer

DMARC (Domain-based Message Authentication, Reporting and Conformance) verbindet SPF und DKIM mit dem für den Nutzer sichtbaren From-Header (Header-From). Eine Mail gilt als DMARC-konform, wenn entweder SPF oder DKIM auf die gleiche Domain ausgerichtet sind wie der Header-From ("alignment", die Übereinstimmung der Domains).

_dmarc.example.de. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.de; ruf=mailto:dmarc@example.de; fo=1"

Die Policy p= kennt drei Werte:

• none: nur berichten, nicht behandeln. Einstiegsstufe zum Aufräumen.
• quarantine: nicht-konforme Mails in den Spam-Ordner.
• reject: nicht-konforme Mails ablehnen.

Die rua=-Adresse erhält tägliche aggregierte Reports über den Ausgang, aus denen sich ablesen lässt, welche Versand-Quellen in der eigenen Domain aktiv sind und welche davon DMARC bestehen oder scheitern.

Der Migrationspfad ist standardmäßig: p=none -> Auswertung für ein paar Wochen, bis alle legitimen Quellen SPF/DKIM-konform sind -> p=quarantine -> p=reject.

MTA-STS: Transport mit obligatorischem TLS

SMTP verhandelt TLS optional. Ein Man-in-the-Middle (ein Angreifer, der sich unbemerkt in die Verbindung zwischen zwei Servern setzt) kann die STARTTLS-Nachricht entfernen und die Verbindung auf Klartext herunterstufen. MTA-STS (Mail Transfer Agent Strict Transport Security) signalisiert, dass der empfangende Server nur über TLS angesprochen werden will:

_mta-sts.example.de. IN TXT "v=STSv1; id=20230101010000"

Zusätzlich stellt der Server eine Policy-Datei unter https://mta-sts.example.de/.well-known/mta-sts.txt bereit:

version: STSv1
mode: enforce
mx: mx1.example.de
mx: mx2.example.de
max_age: 604800

Der sendende Server holt diese Policy (HTTPS mit öffentlich validem Zertifikat) und weiß für die Zeitdauer max_age: an diese Domain nur mit TLS, nur zu den gelisteten MX-Hosts (den im DNS hinterlegten Mailservern der Domain), deren Zertifikate zur Web-PKI passen müssen.

Zusätzlich unterstützen viele Provider TLS-RPT (RFC 8460, TLS Reporting), das tägliche Berichte über gescheiterte TLS-Verbindungen an eine angegebene Adresse liefert.

DANE: TLSA-Pinning per DNSSEC

DANE (DNS-based Authentication of Named Entities) verlegt das Vertrauen in TLS-Zertifikate von der Web-PKI ins DNS, aber nur, wenn DNSSEC das DNS signiert. Ein TLSA-Record steht unter _25._tcp.mx.example.de und pinnt (legt verbindlich fest) entweder den konkreten Zertifikat-Hash oder den öffentlichen Schlüssel:

_25._tcp.mx1.example.de. IN TLSA 3 1 1 abc123...

Sendende Server, die DANE unterstützen, validieren beim TLS-Handshake (dem Verbindungsaufbau, bei dem die Verschlüsselung ausgehandelt wird), dass der vom MX präsentierte Key mit dem TLSA-Record übereinstimmt. Damit wird ein CA-basierter Angriff (ein missbräuchlich ausgestelltes Zertifikat einer gutgläubigen Zertifizierungsstelle) ins Leere geleitet.

DANE und MTA-STS schließen sich nicht aus: sie sind komplementär. DANE setzt DNSSEC voraus, das (noch) nicht flächendeckend verfügbar ist; MTA-STS setzt die Web-PKI voraus, die jeder Anbieter sowieso hat. Beide gleichzeitig auszurollen bietet Schutz unabhängig davon, welcher Standard beim sendenden Server aktiv ist.

Abgelehnte Alternativen und Mythen

"SPF allein reicht." Für den Schutz gegen gefälschte Absender-Adressen im From-Header reicht SPF nicht, weil SPF den Envelope-Sender prüft und der Angreifer beides wählen kann.

"Wir haben DKIM, das ist die Signatur, das sollte genügen." DKIM ohne DMARC verhindert nicht, dass ein Angreifer eine unsignierte Mail mit gleichem From verschickt. Empfänger akzeptieren unsignierte Mails standardmäßig weiter.

"DMARC p=reject bricht uns die Mails." Tut es, wenn nicht alle legitimen Versandquellen korrekt SPF/DKIM-signiert senden. Der Migrationspfad über p=none mit Reports ist genau dafür da, drei bis sechs Monate Auswertung decken regelmässig alles auf, was über Newsletter-Dienste, CRM-Systeme und Altsysteme abgeht.

"S/MIME oder PGP lösen das gleiche Problem." Nicht das gleiche, und für Massen-Mailverkehr nicht praktikabel. S/MIME und PGP signieren den Nachrichteninhalt Ende-zu-Ende; SPF/DKIM/DMARC/MTA-STS/DANE sichern die Kommunikation zwischen Servern und die Domain-Authentizität ab. Beide Schichten sind unabhängig.

Was Sie jetzt tun sollten

1. Setzen Sie DMARC zuerst auf p=none mit einer rua=-Adresse für die Reports. Das verändert nichts an der Zustellung, schafft aber sofort Sichtbarkeit darüber, wer unter Ihrer Domain mailt.
2. Werten Sie die Aggregate-Reports über einige Wochen aus und sorgen Sie dafür, dass jede legitime Versandquelle (Newsletter, CRM, Altsysteme) SPF- und DKIM-konform sendet.
3. Verschärfen Sie DMARC erst dann schrittweise auf p=quarantine und schließlich p=reject, wenn die Reports keine legitimen Fehlschläge mehr zeigen.
4. Veröffentlichen Sie MTA-STS im Modus testing, prüfen Sie über TLS-RPT, dass keine echten Verbindungen scheitern, und schalten Sie dann auf enforce.
5. Ergänzen Sie DANE über TLSA-Records, sobald Ihre Domain DNSSEC-signiert ist - so sind Sie für beide Empfänger-Welten abgedeckt.

Wie Dernium hier hilft

Dernium Mailcheck ist genau für den hier beschriebenen Stack gebaut: Prüfung von SPF, DKIM, DMARC, MTA-STS und DANE-Konfiguration einer Domain, Empfang und Auswertung der DMARC-Aggregate-Reports (RUA), Zeitreihen-Diagramme über die tatsächlich versendenden Quellen unter der eigenen Domain. Ziel im Produkt-Pfad ist, Domäneninhaber in drei bis sechs Monaten ohne Nebenwirkungen auf p=reject zu führen, inklusive Anbindung an TLS-RPT für Transport-Sichtbarkeit. Wer den Schritt zum verifizierten Markenlogo im Posteingang gehen will, erzeugt den BIMI-Record mit dem BIMI-Generator in den Dernium Webtools und beschafft das VMC (Verified Mark Certificate, das Zertifikat zum Markenlogo) direkt bei einem anerkannten Issuer.

Verifikation

Für die eigene Domain lassen sich alle Schichten mit offenen Tools prüfen:

• mxtoolbox.com, SPF, DKIM, DMARC-Abfrage pro Domain.
• internet.nl/mail/, niederländisches Bundes-Tool, prüft gleich alle fünf Standards inklusive DNSSEC und TLS-Parameter.
• hardenize.com, umfassende Security-Analyse, inkl. MTA-STS und DANE.
• Lokal: dig TXT _dmarc.example.de, dig TXT _mta-sts.example.de, dig TLSA _25._tcp.mx1.example.de.

Dabei ist darauf zu achten, dass es sich hierbei um ausländische Anbieter handelt. Dernium bietet diese Dienstleistung aus Deutschland an, auch kostenlos.

Offene Punkte

BIMI (Brand Indicators for Message Identification) setzt auf DMARC p=quarantine oder reject auf und zeigt ein Markenlogo neben Mails, die den Authentizitätstest bestehen. Noch nicht in allen Mailclients unterstützt, wird aber in Gmail, Yahoo und Apple Mail schrittweise ausgerollt.

Weiterleitungs-Bruch bleibt real: eine korrekt DMARC-konforme Mail, die durch eine alte Mailingliste läuft, verliert häufig die DKIM-Signatur. ARC (Authenticated Received Chain, RFC 8617, eine signierte Kette über alle Weiterleitungsstationen) soll das lösen und ist zunehmend etabliert.

DNSSEC-Verbreitung. DANE setzt DNSSEC voraus. In Deutschland liegt die DNSSEC-Rate deutlich unter der skandinavischer oder niederländischer Nachbarn; für deutsche Empfänger lohnt MTA-STS deshalb oft mehr, DANE ist der saubere Zusatz für alle Empfänger, die es validieren können.

Häufige Fragen

Welche der fünf Schichten sollte ich zuerst einrichten?

SPF und DKIM zuerst, danach DMARC im Modus p=none. SPF und DKIM sind die eigentlichen Nachweise, DMARC ist die Klammer, die beide an den sichtbaren Absender koppelt und Ihnen über Reports zeigt, ob alles greift. MTA-STS und DANE betreffen den Transport und können danach folgen.

Warum reicht SPF nicht aus, um Phishing zu stoppen?

Weil SPF nur die technische Absenderadresse hinter den Kulissen prüft (den Envelope-Sender), nicht die Adresse, die der Empfänger im Mailprogramm sieht (den From-Header). Ein Angreifer kann eine SPF-konforme Mail von einer eigenen Domain versenden und trotzdem im sichtbaren Absender Ihren Namen vortäuschen. Erst DMARC verknüpft die Prüfung mit dem sichtbaren Absender.

Ist DMARC p=reject riskant für meine echten Mails?

Riskant nur, wenn Sie es zu früh scharf schalten. Solange noch legitime Versandquellen nicht korrekt signieren, würden deren Mails abgelehnt. Deshalb beginnt man mit p=none, wertet die Reports aus, bis alle echten Quellen sauber sind, und verschärft erst dann. Mit diesem Vorgehen ist p=reject ungefährlich.

Brauche ich sowohl MTA-STS als auch DANE oder reicht eines?

Beide ergänzen sich. MTA-STS stützt sich auf die normale Web-PKI und funktioniert sofort, setzt aber kein DNSSEC voraus. DANE bietet stärkeren Schutz, verlangt aber, dass Ihre Domain DNSSEC-signiert ist. Wer beide veröffentlicht, ist gegen sendende Server abgesichert, die nur eines der beiden Verfahren unterstützen.

Was ist der Unterschied zwischen dem sichtbaren Absender und dem Envelope-Sender?

Der sichtbare Absender (From-Header) ist das, was Ihr Mailprogramm anzeigt. Der Envelope-Sender (MAIL FROM) ist eine separate Adresse, die nur die Server beim Transport auswerten, etwa für Fehlermeldungen. Beide können unterschiedlich sein, und genau diese Trennung machen sich Phishing-Angriffe zunutze, weshalb DMARC die Übereinstimmung erzwingt.

Aktualisierungen

• 2024-02-04 - Gmail und Yahoo: DMARC-Pflicht für Massenversender