DKIM - DomainKeys Identified Mail

DKIM (DomainKeys Identified Mail) ist ein E-Mail-Authentifizierungsstandard, der 2011 als RFC 6376 standardisiert wurde. Es fügt jeder ausgehenden E-Mail eine kryptografische Signatur im E-Mail-Header hinzu. Der empfangende Mailserver kann diese Signatur anhand des öffentlichen Schlüssels im DNS der Absenderdomain überprüfen - und damit feststellen, ob die E-Mail tatsächlich von der angegebenen Domain stammt und ob sie auf dem Weg manipuliert wurde.

DKIM ist, zusammen mit SPF und DMARC, eine der drei Säulen moderner E-Mail-Authentifizierung.

Wie DKIM funktioniert

Signierung (Absenderseite):

1. Der Mailserver des Absenders berechnet einen kryptografischen Hash über definierte E-Mail-Header und den Body
2. Dieser Hash wird mit dem privaten DKIM-Schlüssel signiert
3. Die Signatur wird als DKIM-Signature-Header in die E-Mail eingefügt

Überprüfung (Empfängerseite):

1. Empfangender Server liest den DKIM-Signature-Header aus
2. Er fragt den DNS nach dem öffentlichen Schlüssel: selector._domainkey.example.com
3. Er verifiziert die Signatur mit dem öffentlichen Schlüssel
4. Bei Übereinstimmung: DKIM pass - die E-Mail ist unverändert und stammt von der Domain

Anatomie des DKIM-Signature-Headers

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=beispiel.de; s=mail2024;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=QjxnBMFXeOZJBj...

Tag	Bedeutung
v=1	DKIM-Version
a=rsa-sha256	Signaturalgorithmus
c=relaxed/relaxed	Canonicalization für Header und Body
d=beispiel.de	Signing Domain (muss mit From-Header übereinstimmen für DMARC-Alignment)
s=mail2024	Selector - bestimmt welcher DNS-Schlüssel verwendet wird
h=	Signierte Header-Felder
bh=	Body-Hash
b=	Signatur

Schlüsselmanagement und Selector

Der Selector ermöglicht mehrere DKIM-Schlüssel für dieselbe Domain - ein wichtiges Feature für:

• Schlüsselrotation: Neuen Schlüssel einführen ohne Betriebsunterbrechung
• Mehrere Mailquellen: Jeder Maildienstleister (Google Workspace, HubSpot, Mailchimp) bekommt eigenen Selector

DNS-Eintrag für Selector mail2024:

mail2024._domainkey.beispiel.de. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Schlüsselgröße: RSA-2048 als Mindestanforderung

RFC 8301 (2018) hat RSA-1024 als unsicher eingestuft. RSA-2048 ist der aktuelle Mindeststandard; RSA-4096 bietet höhere Sicherheit. Viele Maildienstleister bieten mittlerweile auch Ed25519 (Elliptic Curve) als Alternative an - kompaktere Schlüssel bei gleicher oder höherer Sicherheit.

Prüfen: dig TXT selector._domainkey.domain.com - prüfen ob p= mindestens 256 Zeichen (= RSA-2048) hat.

Schlüsselrotation - wie oft?

Best Practice: alle 6-12 Monate. Prozess:

1. Neuen Schlüssel generieren (z. B. Selector mail2025)
2. Neuen DNS-Eintrag mit neuem Selector veröffentlichen
3. Mailserver auf neuen Selector umstellen
4. Alten DNS-Eintrag nach 48-72h löschen (DNS-TTL abwarten)

Wichtig: Alten Schlüssel nicht sofort löschen - E-Mails, die noch unterwegs sind, werden sonst nicht mehr verifiziert.

DKIM-Limitierungen

Weiterleitungen: Bei E-Mail-Weiterleitungen (z. B. Alias-Adressen) kann der Body verändert werden (z. B. Footer-Anhang), was die DKIM-Signatur bricht. DMARC berücksichtigt dies durch relaxed-Canonicalization.

From-Header nicht zwingend: DKIM signiert die Domain im d=-Tag - diese muss nicht mit dem From-Header übereinstimmen. Erst DMARC-Alignment stellt diese Verbindung her.

Kein Schutz vor Replay-Angriffen: Eine gültig signierte E-Mail kann abgefangen und erneut versendet werden. Die Signatur bleibt gültig.

DKIM im E-Mail-Sicherheitsverbund

• SPF - Wer darf von welchem Server senden?
• DKIM - Wurde die E-Mail unterwegs manipuliert?
• DMARC - Stimmt alles überein? Was passiert wenn nicht?

Alle drei Protokolle ergänzen sich. Google und Yahoo verlangen seit Februar 2024 für Bulk-Versender (>5.000 E-Mails/Tag) alle drei. Ohne korrekte DKIM-Signierung und SPF-Eintrag werden E-Mails in Spam einsortiert oder abgelehnt.

Weiterführende Informationen: SPF Wiki-Artikel | DMARC Wiki-Artikel