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

6 Min Lesezeit Serie: infrastructure #email#dmarc#dkim#spf#mta-sts#dane

SPF allein schützt nicht, DKIM ohne DMARC auch nicht, und Transport-Sicherheit ohne MTA-STS oder DANE bleibt Vertrauenssache. Welche Schicht was leistet, und wie eine Domain aussieht, die alle fünf sauber konfiguriert.

Problem

E-Mail ist das älteste in Betrieb befindliche offene Standardprotokoll, das flächendeckend für Geschäftsvorgänge genutzt wird, und es ist strukturell ohne Authentizitätsmechanismus entworfen worden. SMTP akzeptiert im Grundzustand einen beliebigen MAIL FROM, einen beliebigen From-Header und eine beliebige Absenderadresse in der Signatur. Der Empfänger-Server sieht zunächst nur, dass ihm jemand Bytes schickt.

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.

Kurze Antwort

  • SPF (RFC 7208): legt fest, welche IPs für eine Domain mailen dürfen. Prüft den Envelope-Sender.
  • 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 für Nicht-Konformität.
  • MTA-STS (RFC 8461): signalisiert, dass Mails an diese Domain nur über authentifiziertes TLS anzunehmen sind.
  • DANE (RFC 7672): hinterlegt erwartete TLS-Zertifikate per DNSSEC, unabhängig von der Web-PKI.

SPF + DKIM + DMARC sichern die Absender-Authentizität, MTA-STS und DANE sichern den Transport. Ohne DMARC bleiben SPF und DKIM Detail-Werkzeuge ohne gemeinsame Durchsetzung; ohne MTA-STS oder DANE ist der verschlüsselte Transport ein Vorschlag.

Tiefgang

SPF: IP-Whitelist für die sendende Domain

Ein SPF-Eintrag 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) existieren, sind aber nicht flächendeckend implementiert.

DKIM: kryptografische Signatur der Mail

DKIM signiert einen konfigurierbaren Satz von Headern (typischerweise From, Subject, Date, To, und der Body-Hash) mit einem privaten RSA- oder Ed25519-Schlüssel. Der öffentliche Schlüssel liegt als TXT-Record unter dem Selector:

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 weiss: 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 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").

_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ässig: 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 kann die STARTTLS-Nachricht entfernen und die Verbindung auf Klartext herunterstufen. MTA-STS 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 weiss für die Zeitdauer max_age: an diese Domain nur mit TLS, nur zu den gelisteten MX-Hosts, deren Zertifikate zur Web-PKI passen müssen.

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

DANE: TLSA-Pinning per DNSSEC

DANE 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 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, dass der vom MX präsentierte Key mit dem TLSA-Record übereinstimmt. Damit wird ein CA-basierter Angriff (missbräuchlich ausgestelltes Zertifikat einer gutgläubigen CA) ins Leere geleitet.

DANE und MTA-STS schliessen 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ässig 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.

Wie Svelnor hier hilft

Svelnor 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 fuehren, inklusive Anbindung an TLS-RPT für Transport-Sichtbarkeit.

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.

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) 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.

Aktualisierungen