SPF, DKIM und DMARC erklärt

Das Problem

E-Mail prüft von sich aus nicht, wer eine Nachricht verschickt: Jeder Server kann jede Absenderadresse verwenden, auch eine mit Ihrer Domain. Verschlüsselung zwischen Mailservern ist freiwillig, und wer die Verbindung manipulieren kann, kann sie unterdrücken oder Mails umleiten.

Sieben Verfahren schließen diese Lücken über Einträge im DNS. SPF, DKIM und DMARC zeigen Empfängern, ob eine Mail mit Ihrer Domain autorisiert ist. MTA-STS und DANE sichern den Transport der Mails an Ihre Domain; TLS-RPT berichtet darüber. DNSSEC schützt die DNS-Antworten, auf die sich alle stützen.

Überblick

Im Einzelnen

SPF

SPF listet die Server auf, die für Ihre Domain senden dürfen; der Empfänger vergleicht damit die IP-Adresse des einliefernden Servers. Geprüft wird die technische Absenderadresse (Return-Path), nicht die Adresse, die Ihr Mailprogramm anzeigt.

example.org. IN TXT "v=spf1 ip4:192.0.2.25 include:_spf.example.net -all"

Typischer Fehler: mehr als zehn Angaben, die DNS-Abfragen auslösen (etwa include oder mx, verschachtelte mitgezählt), oder zwei SPF-Einträge an einer Domain. Beides macht den Eintrag unbrauchbar.

DKIM

Der sendende Server signiert den Inhalt und ausgewählte Kopfzeilen jeder Mail. Die signierende Domain veröffentlicht den öffentlichen Schlüssel im DNS unter einem frei wählbaren Selektor (hier key1). Empfänger können so Veränderungen erkennen und sehen, welche Domain für die Mail einsteht.

key1._domainkey.example.org. IN TXT "v=DKIM1; k=ed25519; p=2jNfm9hFwOt+8YT568bIRZLOU6WflFg++ZYlyT0CTlc="

Typischer Fehler: Ein Newsletter-Dienst, der für Sie versendet, signiert mit seiner eigenen Domain. Die Signatur ist gültig, zählt für DMARC aber nicht.

DMARC

SPF und DKIM prüfen technische Domains, nicht die sichtbare Absenderadresse. DMARC vergleicht sie mit der sichtbaren Absenderdomain; in der Voreinstellung passen auch Subdomains wie news.example.org. Außerdem nennen Sie Ihren Wunsch für durchgefallene Mails, none (nur beobachten), quarantine (als verdächtig behandeln) oder reject (abweisen), und eine Adresse für Sammelberichte.

_dmarc.example.org. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.org"

Typischer Fehler: reject setzen, bevor alle eigenen Absender bestehen; dann scheitern echte Mails. Oder dauerhaft bei none bleiben: Das liefert Berichte, setzt aber nichts durch.

MTA-STS

Ihre Domain sagt zu, dass ihre Mailserver TLS mit gültigem Zertifikat anbieten, und nennt deren Namen. Im Modus enforce stellen Sender, die MTA-STS auswerten, nur unter diesen Bedingungen zu. Ein TXT-Eintrag kündigt die Richtlinie an:

_mta-sts.example.org. IN TXT "v=STSv1; id=20261005"

Die Richtlinie ist eine Textdatei, die mta-sts.example.org per HTTPS unter /.well-known/mta-sts.txt ausliefert:

version: STSv1
mode: enforce
mx: mx1.example.org
max_age: 604800

Typischer Fehler: Die Mailserver wechseln, aber die Richtlinie nennt noch die alten. Ändern Sie zuerst die Datei, dann die id und erst danach die MX-Einträge.

TLS-RPT

TLS-RPT schützt nicht selbst, sondern zeigt, ob die Transportverschlüsselung funktioniert. Teilnehmende Sender schicken tägliche Berichte im JSON-Format an die Adresse, die Sie veröffentlichen.

_smtp._tls.example.org. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.org"

Typischer Fehler: MTA-STS oder DANE scharf schalten, ohne vorher Berichte zu sammeln.

DANE

DANE veröffentlicht im DNS, welchen Schlüssel ein Mailserver bei TLS vorweisen muss. Sender, die DANE auswerten, verlangen dann Verschlüsselung und stellen nur zu, wenn der Schlüssel zu diesem TLSA-Eintrag passt. Er steht am Namen des Mailservers; liegt Ihre Mail bei einem Anbieter, veröffentlicht dieser den Eintrag.

_25._tcp.mx1.example.org. IN TLSA 3 1 1 7c9e649aa9ee78f562c3a484163e1747d27f6e4c944ac979f352788a0a45099e

Typischer Fehler: Der Server bekommt einen neuen Schlüssel, der Eintrag bleibt aber der alte. Veröffentlichen Sie vorher zusätzlich den neuen Eintrag.

DNSSEC

DNSSEC signiert die Einträge Ihrer Zone, sodass prüfende Resolver erkennen, ob eine Antwort echt und unverändert ist. Die Vertrauenskette läuft über die übergeordnete Zone: Dort steht ein DS-Eintrag mit dem Fingerabdruck Ihres Schlüssels.

example.org. IN DS 63814 13 2 1387cc5c80a36d6686f050ebc31606db4aae3041d788f3c7d637f234cdb2abd4

Typischer Fehler: Nach einem Wechsel des DNS-Anbieters bleibt der alte DS-Eintrag stehen. Prüfende Resolver verwerfen dann jede Antwort; Website und Mail sind für deren Nutzer nicht erreichbar.

Zusammenspiel

Eine Mail besteht DMARC nur, wenn SPF oder DKIM besteht und die dabei geprüfte Domain zur sichtbaren Absenderdomain passt. Bei Weiterleitungen scheitert meist SPF, während eine DKIM-Signatur in der Regel gültig bleibt; RFC 9989 empfiehlt, beide einzusetzen. Ändert eine Mailingliste Betreff oder Text, bricht allerdings auch die Signatur.

DANE setzt DNSSEC voraus, auch für Ihre eigene Domain. MTA-STS ist die Alternative ohne DNSSEC: Es stützt sich auf Zertifizierungsstellen und HTTPS, schützt aber erst, nachdem ein Sender die Richtlinie einmal ungestört abgerufen hat. TLS-RPT berichtet über beide.

DMARC schützt Ihre exakte Domain, nicht ähnlich aussehende Domains oder Anzeigenamen. Über die Behandlung einer Mail entscheidet immer der Empfänger.

Reihenfolge der Einführung

1. Alle Systeme auflisten, die mit Ihrer Domain senden: Postfächer, Newsletter, Shop.
2. SPF veröffentlichen und DKIM mit Ihrer eigenen Domain einschalten.
3. DMARC mit p=none und einer Berichtsadresse veröffentlichen; die Berichte lesen, bis alle legitimen Quellen bestehen.
4. Auf quarantine verschärfen. reject passt nicht zu jeder Domain: RFC 9989 rät davon ab, wenn Nutzer an Mailinglisten schreiben.
5. TLS-RPT einrichten, dann MTA-STS zunächst im Modus testing, später enforce.
6. DNSSEC aktivieren, danach DANE.

Bei lettron.eu

Der Maildienst von lettron.eu ist noch nicht verfügbar. Der geplante Domain Autopilot soll die passenden DNS-Einträge für eigene Domains erzeugen und überwachen.