DKIM (DomainKeys Identified Mail)
DKIM ist ein E-Mail-Authentifizierungsverfahren, das mithilfe kryptographischer Signaturen die Integrität und Herkunft von E-Mails verifiziert.
DKIM (DomainKeys Identified Mail) ist ein E-Mail-Authentifizierungsstandard (RFC 6376), der sicherstellt, dass eine E-Mail tatsächlich vom angegebenen Absender stammt und auf dem Transportweg nicht manipuliert wurde. Im Gegensatz zu SPF, das auf IP-Adressen basiert, arbeitet DKIM mit asymmetrischer Kryptographie und schützt damit auch gegen bestimmte Weiterleitungsszenarien.
Wie funktioniert DKIM
DKIM nutzt ein asymmetrisches Schlüsselpaar: Der sendende Mailserver signiert ausgehende E-Mails mit einem privaten Schlüssel. Der empfangende Mailserver prüft die Signatur anhand des öffentlichen Schlüssels, der im DNS der sendenden Domain hinterlegt ist.
DKIM-Ablauf:
1. Schlüsselgenerierung:
Sendende Domain generiert RSA- oder Ed25519-Schlüsselpaar
→ Privater Schlüssel: verbleibt sicher auf dem Mailserver
→ Öffentlicher Schlüssel: wird als DNS TXT-Record veröffentlicht
2. Signierung (ausgehend):
Mailserver berechnet Hash über definierte E-Mail-Header + Body
→ Algorithmen: rsa-sha256 (Standard) oder ed25519-sha256 (moderner)
→ Hash wird mit privatem Schlüssel verschlüsselt → Signatur
→ Signatur wird als DKIM-Signature-Header der E-Mail beigefügt
3. Validierung (eingehend):
Empfangender Mailserver liest DKIM-Signature-Header
→ Extrahiert Selektor (s=) und Domain (d=)
→ DNS-Lookup: [selektor]._domainkey.[domain] → öffentlicher Schlüssel
→ Berechnet Hash über dieselben Header + Body neu
→ Entschlüsselt Signatur mit öffentlichem Schlüssel
→ Vergleich: Hash stimmt überein → DKIM pass | stimmt nicht → DKIM failDKIM-Signature-Header im Detail
Wenn eine E-Mail mit DKIM signiert ist, enthält sie einen Header wie diesen:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=beispiel.de; s=mail2024;
h=from:to:subject:date:message-id:mime-version:content-type;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=mFN3KcZj8Qh4...langer-base64-string...==Parameter-Erklärung:
v=1 DKIM-Version (immer 1)
a=rsa-sha256 Signaturalgorithmus (RSA mit SHA-256)
c=relaxed/relaxed
Canonicalization: Header/Body-Normalisierung
relaxed: toleriert kleinere Formatänderungen (empfohlen)
simple: strikte Prüfung (sensitiver bei Weiterleitungen)
d=beispiel.de
Signing Domain: muss mit From:-Header übereinstimmen (für DMARC)
s=mail2024 Selektor: Zeiger auf den richtigen DNS-Eintrag
Erlaubt mehrere Schlüssel für eine Domain (Rotation!)
h=from:to:subject:date:...
Signierte Header: mindestens From muss enthalten sein
bh= Body Hash: SHA-256-Hash des E-Mail-Bodys
b= Die eigentliche Signatur (Base64-kodiert)DNS-Record Aufbau
Der öffentliche Schlüssel wird unter folgendem DNS-Namen veröffentlicht:
[selektor]._domainkey.[domain]
Beispiel:
mail2024._domainkey.beispiel.de IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."DNS TXT-Record Parameter:
v=DKIM1 Protokollversion (zwingend)
k=rsa Schlüsseltyp: rsa (Standard) oder ed25519
p= Öffentlicher Schlüssel (Base64-kodiert)
Leer lassen (p=) = Schlüssel zurückgezogen → alle Signaturen ungültig
Optionale Parameter:
h=sha256 Hash-Algorithmus-Beschränkung
s=email Service-Typ-Beschränkung (email oder *)
t=y Test-Modus: DKIM-Fehler werden nicht durchgesetzt
t=s Subdomains nicht erlaubt (strikt)Vollständiges Beispiel mit Ed25519 (moderner, kürzere Keys):
# Ed25519 DKIM-Record (empfohlen für neue Deployments):
selector2024._domainkey.beispiel.de IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="Selektoren und Schlüsselrotation
Ein wesentlicher Vorteil von DKIM gegenüber anderen Verfahren ist die Unterstützung mehrerer Schlüssel gleichzeitig durch sogenannte Selektoren:
Selektor-Strategie:
Mehrere Mailsysteme:
smtp._domainkey.beispiel.de → Haupt-Mailserver (Postfix)
crm._domainkey.beispiel.de → CRM-System (Salesforce)
newsletter._domainkey.beispiel.de → E-Mail-Marketing (Mailchimp)
Schlüsselrotation (Best Practice: alle 6-12 Monate):
Schritt 1: Neuen Schlüssel generieren, als "mail-neu" im DNS veröffentlichen
Schritt 2: Mailserver auf neuen privaten Schlüssel umschalten
Schritt 3: Alten DNS-Record noch 72h behalten (TTL-Ausläufer abwarten)
Schritt 4: Alten DNS-Record entfernen oder p= leeren (Revocation)
Warum Rotation?
→ Gestohlener privater Schlüssel kann für Signierung missbraucht werden
→ Rotation begrenzt das Zeitfenster eines kompromittierten SchlüsselsDKIM Alignment
Für DMARC ist DKIM-Alignment entscheidend: Die Domain im d=-Tag der DKIM-Signatur muss mit der Domain im From:-Header übereinstimmen (zumindest auf Organizational-Domain-Ebene bei relaxed Alignment).
DKIM Alignment Beispiele:
Relaxed Alignment (Standard):
From: absender@beispiel.de
DKIM d=mail.beispiel.de → PASS (gleiche Org-Domain: beispiel.de)
DKIM d=anderedomain.de → FAIL
Strict Alignment:
From: absender@beispiel.de
DKIM d=beispiel.de → PASS (exakt gleich)
DKIM d=mail.beispiel.de → FAIL (Subdomain reicht nicht)
Typisches DMARC-Szenario:
E-Mail-Marketing über Drittanbieter:
From: newsletter@beispiel.de
DKIM signiert von: mailchimp.com → DKIM-Alignment FAIL für DMARC!
Lösung: Custom Domain Signing beim Anbieter einrichten
→ DKIM signiert von: k2._domainkey.beispiel.de (via CNAME)Grenzen von DKIM
DKIM ist kein Allheilmittel und hat bekannte Schwachstellen:
Was DKIM NICHT schützt:
Replay-Angriffe:
→ Eine gültig signierte E-Mail kann erneut versendet werden
→ DKIM prüft nicht, ob die E-Mail bereits zugestellt wurde
→ Gegenmaßnahme: DMARC + sehr kurze Signatur-Gültigkeit (t=)
Kompromittierter Mailserver:
→ Wenn der sendende Server kompromittiert ist, kann der Angreifer
beliebige E-Mails mit dem privaten Schlüssel signieren
→ DKIM beweist nur: "Dieser Server hat signiert" - nicht: "Kein Missbrauch"
Forwarding-Probleme (DKIM bleibt meist intakt):
→ Im Gegensatz zu SPF überlebt DKIM meist Weiterleitungen
→ Ausnahme: Mailing-Listen die Subject oder Body modifizieren
→ DKIM fail wegen verändertem Body-Hash
Header-Injection über unsignierte Header:
→ Angreifer kann zusätzliche From:-Header einfügen (über signierten)
→ Empfang zeigt zweiten From: an → Social Engineering
→ Gegenmaßnahme: alle wichtigen Header in h= aufnehmenDKIM und DMARC
DKIM allein hat keine Policy-Wirkung: Ein DKIM-Fail führt nicht automatisch zur Ablehnung einer E-Mail. Erst in Kombination mit DMARC erhält DKIM eine durchsetzbare Wirkung.
DKIM im DMARC-Kontext:
DMARC-Prüfung (vereinfacht):
Besteht die E-Mail SPF UND/ODER DKIM mit korrektem Alignment?
→ Ja: DMARC pass (unabhängig von der p=-Policy)
→ Nein: DMARC fail → Policy anwenden (none/quarantine/reject)
Warum DKIM besser als SPF für DMARC:
→ SPF bricht bei Weiterleitungen (Return-Path ändert sich)
→ DKIM-Signatur bleibt beim Weiterleiten erhalten
→ Best Practice: DMARC über DKIM absichern, SPF als zusätzliche Schicht
Vollständiger E-Mail-Authentifizierungsstack:
SPF: "Welche Server dürfen für diese Domain senden?" (IP-basiert)
DKIM: "Ist diese E-Mail unverändert und korrekt signiert?" (Krypto-basiert)
DMARC: "Was passiert bei Authentifizierungsfehlern?" (Policy-basiert)DKIM ist heute ein unverzichtbarer Bestandteil jeder professionellen E-Mail-Infrastruktur. Große E-Mail-Provider wie Google und Microsoft werten DKIM-Signierung aktiv bei der Spam-Bewertung und Zustellbarkeit ein - fehlende DKIM-Signaturen erhöhen das Risiko, dass legitime E-Mails im Spam-Ordner landen.
