DKIM
Jede E-Mail, die ein Mailserver verschickt, kann auf dem Weg zum Empfänger verändert werden. Eine digitale Signatur im Nachrichtenkopf macht solche Veränderungen erkennbar. Das Verfahren, das diese Signatur erzeugt und prüfbar macht, heißt DKIM.
Wie eine E-Mail ihre Herkunft beweist
Wenn ein Mailserver eine Nachricht versendet, berechnet er aus dem Inhalt und bestimmten Kopfzeilen einen Prüfwert. Diesen Prüfwert verschlüsselt er mit einem privaten Schlüssel. Das Ergebnis ist die DKIM-Signatur. Sie wird als zusätzliche Kopfzeile (DKIM-Signature) in die E-Mail eingefügt.
Der empfangende Mailserver liest diese Kopfzeile, holt den öffentlichen Schlüssel aus dem DNS-Eintrag der Absenderdomain und prüft, ob die Signatur zum Inhalt passt. Stimmt alles überein, ist belegt: Die Mail stammt tatsächlich von dieser Domain und wurde unterwegs nicht verändert.
Beispiel: Ein Unternehmen versendet eine Auftragsbeestätigung per E-Mail. Der Mailserver signiert die Nachricht mit DKIM. Der Mailserver des Empfängers prüft die Signatur automatisch. Im E-Mail-Header erscheint dkim=pass. Der Empfänger kann sicher sein, dass der Inhalt unverändert ist.
Beispiel: Ein Angreifer fängt eine E-Mail ab und ändert die Kontonummer im Text. Der empfangende Server berechnet den Prüfwert neu und vergleicht ihn mit der DKIM-Signatur. Die Werte stimmen nicht überein. Die Prüfung schlägt fehl: dkim=fail.
Privater und öffentlicher Schlüssel
DKIM basiert auf asymmetrischer Kryptographie. Zwei Schlüssel gehören zusammen: ein privater Schlüssel, den nur der sendende Mailserver kennt, und ein öffentlicher Schlüssel, den jeder abfragen kann. Was der private Schlüssel signiert, kann nur der passende öffentliche Schlüssel verifizieren.
Der öffentliche Schlüssel wird als TXT-Record im DNS der Absenderdomain hinterlegt. Der Eintrag folgt dem Muster selektor._domainkey.example.com. Der Selektor ist ein frei wählbarer Name, der es ermöglicht, mehrere Schlüsselpaare parallel zu betreiben.
Beispiel: Ein DNS-Eintrag für DKIM sieht so aus: s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0G...". Der Selektor s1 verweist auf genau dieses Schlüsselpaar. Der Mailserver referenziert denselben Selektor in der DKIM-Signatur.
Beispiel: Ein Unternehmen wechselt seinen E-Mail-Dienstleister. Es erstellt ein neues Schlüsselpaar mit dem Selektor s2 und hinterlegt den öffentlichen Schlüssel im DNS. Der alte Selektor s1 bleibt aktiv, bis alle E-Mails mit der alten Signatur zugestellt sind. Danach wird s1 gelöscht.
Aufbau der DKIM-Signatur
Die DKIM-Signatur ist eine strukturierte Kopfzeile mit mehreren Feldern. Jedes Feld hat eine definierte Funktion. Die wichtigsten Felder:
v=1: Version des DKIM-Standardsa=rsa-sha256: Signaturalgorithmus (RSA mit SHA-256-Hash)d=example.com: Die signierende Domains=s1: Der Selektor, der auf den DNS-Eintrag mit dem öffentlichen Schlüssel verweisth=from:to:subject:date: Liste der signierten Kopfzeilenbh=...: Hash des E-Mail-Bodyb=...: Die eigentliche Signatur (Base64-kodiert)
Beispiel: Eine vollständige DKIM-Signatur im E-Mail-Header: DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:to:subject:date; bh=2jUSOH9Nht...; b=dzdVyOfAKC.... Jeder empfangende Server kann diese Angaben nutzen, um den öffentlichen Schlüssel abzufragen und die Signatur zu prüfen.
Beispiel: Das Feld h=from:to:subject:date legt fest, welche Kopfzeilen in die Signatur einfließen. Wird nach dem Signieren eine dieser Kopfzeilen geändert (etwa der Betreff), schlägt die Prüfung fehl. Kopfzeilen, die nicht im h-Feld stehen, können verändert werden, ohne die Signatur zu brechen.
Ablauf der Signaturprüfung
Die Prüfung läuft automatisch auf dem empfangenden Mailserver ab. Kein menschliches Eingreifen ist nötig. Der Ablauf:
Der empfangende Server extrahiert aus der DKIM-Signatur die Domain (d=) und den Selektor (s=). Damit fragt er den DNS-Eintrag ab und erhält den öffentlichen Schlüssel. Anschließend berechnet er den Hash über die im h-Feld genannten Kopfzeilen und den Body. Stimmt der berechnete Hash mit dem entschlüsselten Signaturwert überein, ist die Prüfung bestanden.
Beispiel: Ein Newsletter-Versender nutzt den Dienst eines externen Anbieters. Der Anbieter signiert die Mails mit seiner eigenen Domain im d=-Feld. Der empfangende Server prüft die Signatur gegen den DNS-Eintrag des Anbieters. Die Prüfung ist bestanden, obwohl die Absenderadresse eine andere Domain zeigt. DMARC regelt diesen Unterschied gesondert.
Zusammenspiel mit SPF und DMARC
DKIM allein beantwortet nur eine Frage: Wurde diese Mail von einem Server signiert, der den privaten Schlüssel der angegebenen Domain besitzt? Es sagt nichts darüber aus, ob die Absenderadresse im From-Feld mit der signierenden Domain übereinstimmt. Auch sagt es nichts darüber aus, von welcher IP-Adresse die Mail gesendet wurde.
SPF ergänzt DKIM um die IP-basierte Prüfung. Ein SPF-Record im DNS legt fest, welche Server im Namen einer Domain senden dürfen. DMARC verbindet beide Verfahren und fügt eine Richtlinie hinzu: Was soll der Empfänger tun, wenn weder DKIM noch SPF bestehen?
Beispiel: Eine Domain hat sowohl DKIM als auch SPF konfiguriert. Eine eingehende Mail besteht die DKIM-Prüfung, aber die sendende IP-Adresse steht nicht im SPF-Record. Ohne DMARC liegt die Entscheidung beim Empfänger. Mit DMARC-Richtlinie p=none wird die Mail zugestellt und ein Report erzeugt. Mit p=reject würde die Mail abgelehnt, wenn auch das DKIM-Alignment nicht stimmt.
Beispiel: Ein Unternehmen nutzt einen externen Dienstleister für Marketing-Mails. Der Dienstleister signiert mit DKIM unter einem eigenen Selektor, aber die d=-Domain in der Signatur stimmt mit der From-Domain überein (DKIM-Alignment). DMARC erkennt dies als gültig, auch wenn die IP-Adresse des Dienstleisters nicht im SPF-Record steht.
Konfiguration und häufige Fehler
Die Einrichtung von DKIM erfordert drei Schritte: Schlüsselpaar generieren, öffentlichen Schlüssel im DNS hinterlegen und den Mailserver so konfigurieren, dass er ausgehende Mails signiert. Die meisten Mailserver-Implementierungen (Postfix mit OpenDKIM, Exchange Online, Google Workspace) bieten dafür dokumentierte Verfahren.
Fehler treten häufig an drei Stellen auf:
- DNS-Propagierung: Nach dem Anlegen des TXT-Records dauert es je nach TTL-Einstellung Minuten bis Stunden, bis der Eintrag weltweit verfügbar ist. In dieser Zeit schlagen DKIM-Prüfungen fehl.
- Schlüsselrotation: Alte Selektoren müssen so lange im DNS bleiben, wie E-Mails mit der alten Signatur noch unterwegs sein können. Ein zu frühes Löschen führt zu
dkim=failfür diese Nachrichten. - Body-Modifikation durch Weiterleitungen: Mailinglisten oder Weiterleitungsdienste ändern manchmal den Body (z.B. durch angehängte Footer). Damit bricht die DKIM-Signatur. Der Parameter
l=(Body Length) kann dieses Problem mildern, birgt aber eigene Risiken.
Beispiel: Ein Administrator richtet DKIM für eine neue Domain ein. Er generiert ein 2048-Bit-RSA-Schlüsselpaar, hinterlegt den öffentlichen Schlüssel unter mail._domainkey.example.com und aktiviert die Signierung in Postfix. Ein Test mit opendkim-testkey -d example.com -s mail zeigt key OK. Erst danach aktiviert er DMARC mit p=quarantine.
Signaturalgorithmen und Schlüssellängen
DKIM unterstützt zwei Signaturalgorithmen: rsa-sha256 und ed25519-sha256. Der RSA-basierte Algorithmus ist seit der Einführung von DKIM der Standard. Ed25519 wurde 2018 mit RFC 8463 hinzugefügt.
RSA-Schlüssel für DKIM haben typischerweise eine Länge von 1024 oder 2048 Bit. 1024-Bit-Schlüssel gelten seit einigen Jahren als nicht mehr ausreichend sicher. Das BSI und vergleichbare Institutionen empfehlen mindestens 2048 Bit. Einige DNS-Provider begrenzen die Länge von TXT-Records, was bei 2048-Bit-Schlüsseln zu Problemen führen kann. Der Schlüssel muss dann auf mehrere DNS-Strings aufgeteilt werden.
Ed25519 erzeugt deutlich kürzere Signaturen und Schlüssel bei vergleichbarer Sicherheit. Die Verbreitung in der Praxis ist allerdings noch gering. Viele empfangende Mailserver unterstützen Ed25519 noch nicht. Eine Übergangsstrategie besteht darin, Mails gleichzeitig mit RSA und Ed25519 zu signieren (Dual Signing).
Beispiel: Ein DNS-TXT-Record für einen 2048-Bit-RSA-Schlüssel überschreitet die 255-Zeichen-Grenze eines einzelnen DNS-Strings. Der Eintrag wird in zwei Strings aufgeteilt: "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..." "...G9w0BAQEFAAOCAQ8A". Der empfangende Server setzt die Strings automatisch zusammen.
Grenzen und Einordnung
DKIM garantiert nicht, dass eine E-Mail erwünscht oder inhaltlich korrekt ist. Es bestätigt ausschließlich zwei Eigenschaften: Die Mail wurde von einem Server signiert, der den privaten Schlüssel der angegebenen Domain kontrolliert, und der signierte Inhalt wurde nach dem Signieren nicht verändert.
DKIM schützt nicht vor Replay-Angriffen. Eine gültig signierte Mail kann abgefangen und erneut zugestellt werden. Die Signatur bleibt gültig, weil sich weder Header noch Body geändert haben. Dieses Problem ist bekannt und wird in der Praxis durch ergänzende Maßnahmen (Rate Limiting, DMARC-Reporting) adressiert, aber nicht vollständig gelöst.
Die Sicherheit von DKIM hängt direkt von der Geheimhaltung des privaten Schlüssels ab. Wird der Schlüssel kompromittiert, kann ein Angreifer gültige Signaturen für beliebige Inhalte erzeugen. Regelmäßige Schlüsselrotation (alle 6 bis 12 Monate) ist daher empfohlene Praxis.
Fachliche Einordnung: DKIM ist neben SPF und DMARC einer der drei Pfeiler der E-Mail-Authentifizierung. Während SPF die sendende IP-Adresse prüft, verifiziert DKIM die Integrität der Nachricht selbst. DMARC verbindet beide Prüfungen mit einer Domänenrichtlinie. Die Kombination aller drei Verfahren ist heute Voraussetzung für zuverlässige E-Mail-Zustellung bei den großen Mailprovidern (Google, Microsoft, Yahoo). Seit Februar 2024 verlangen Google und Yahoo DKIM-Signaturen für Absender mit mehr als 5.000 Nachrichten pro Tag.