DKIM

Domain Keys Identified Mail

DKIM lässt sich mit einem digitalen Wachssiegel vergleichen, das die Echtheit des E-Mail-Absenders sicherstellt.

Dazu berechnet der Absender-Server aus definierten Header-Feldern und dem Nachrichteninhalt einen Hash, den er als "DKIM-Signature"-Header an die E-Mail anhängt.

Auf Empfängerseite lädt der Mailserver den zugehörigen öffentlichen Schlüssel aus dem DNS der Absenderdomain und verifiziert damit die Signatur. Wurde während des Transports auch nur ein einziges bit im signierten Bereich verändert oder manipuliert, schlägt die Prüfung fehl und der Empfänger erkennt sofort, dass die Nachricht nicht authentisch ist.

Aufbau und Parameter von DKIM

Öffentlicher Schlüssel (PublicKey)

Der im DNS veröffentlichte Public Key wird vom empfangenden Mailserver genutzt, um die DKIM-Signatur zu verifizieren. So lässt sich sicherstellen, dass die Nachricht wirklich vom angegebenen Absender stammt und unterwegs nicht manipuliert wurde.
TXT
selector._domainkey.example.com
v=DKIM1; k=rsa; p=key;
Dieser Eintrag veröffentlicht einen Schlüssel mit dem die DKIM Signatur (Wachssiegel) überprüft werden kann.
Tags Beschreibung Erforderlich
v Version des DKIM-Schlüsseldatensatzes, Standardwert ist "DKIM1" Nein
p Öffentliche Schlüssel (base64) Ja
h Akzeptierte Hash-Algorithmen Nein
k Schlüsseltyp , Standardwert ist "rsa".
rsa
ed25519
Nein
n Notizen, die für einen Menschen von Interesse sein könnten Nein

E-Mail Header

Für jede versendete E-Mail wird eine Signatur berechnet und diese als zusätzlicher Header dem E-Mail hinzugefügt.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mydkimselector;
    c=simple/simple; t=1694010285; h=from:subject:to;
    bh=d0B6ZJjzyvbX77BrlX0DcQC0i0AuJQudsHclGTFOvCA=;
    b=hKpH7bAPDcH3YNNRs19zpBRYieZvHF7YOSpW/R2GBf5YyVUYil/LrOCDqOwlfrnMQmc2FrWo3rX
    GHnOskKEggxxK80o0H2zT+IbYfeqskeqJptvR9wmmQ/GyEbHX6amWFFcbkwsPeJkTO2/K0s+woE1o
    jCn6/VbwKRmFc/3Y5w8=
Tags Beschreibung Erforderlich
v Dieses Tag definiert die Version der die für den Signatursatz gilt Ja
a Der zur Erzeugung der Signatur verwendete Algorithmus.
rsa-sha1
rsa-sha256
ed25519-sha256
Ja
d Gibt den Domainnamen an, der mit dem Selektoreintrag (s) verwendet wird, um den öffentlichen Schlüssel zu finden Ja
s Der Name des DKIM-Selektors, dieser wird benötigt um den den öffentlichen DKIM-Schlüssel abzufragen
selectorname._domainkey.example.com
Ja
h Signierte Header-Felder, eine durch Doppelpunkte getrennte Liste von Header-Feldnamen, die die Headerfelder identifizieren Ja
bh Dieses Tag steht für den Body-Hash, eine verschlüsselte Version des Inhalts Ihrer Nachricht einschließlich der Headerfelder Ja
b Die Signaturdaten (base64) Ja
c Kanonisierung der Nachricht, Standardwert ist "simple/simple".
Dadurch wird definiert wie mit Leerzeichen und Textumbrüchen in der Nachricht umgegangen wird.
simple/simple
simple/relaxed
relaxed/simple
relaxed/relaxed
Nein
t Signature Timestamp, der Zeitpunkt an dem diese Signatur erstellt wurde Nein
x Signature Expiration, der Zeitpunkt an dem diese Signatur ungültig wird Nein

Best Practices für den Einsatz von DKIM

Systembezogene DKIM-Schlüssel

Wenn du mehrere Systeme zum Versenden von E-Mails nutzt, solltest du für jedes System einen eigenen DKIM-Schlüssel erstellen und im DNS veröffentlichen. So kannst du bei Bedarf einen einzelnen Schlüssel sicher zurückziehen, ohne andere Systeme zu beeinträchtigen.

Wähle den Selector so, dass er - wenn möglich - das jeweilige System eindeutig widerspiegelt, auf dem der Schlüssel verwendet wird. Dadurch kannst du in DMARC-Reports leichter nachvollziehen, welches System bei Problemen betroffen ist und gezielt darauf reagieren.

Beispiele für sinnvolle Selector-Namen

zoho
salesforce
mailchimp
awsses
hetznerserver1

Vermeide diese Selector-Namen

default
dkim
mail
smtp

Konsistente Domain

Die in der Signatur verwendete Domain sollte mit der im sichtbaren Absender (RFC5322.From) genutzten Domain übereinstimmen. Bei der Aktivierung von DMARC ist es zwingend erforderlich, dass die Signaturdomain und der sichtbare Absender übereinstimmen.

Wie stark sollte der DKIM Schlüssel sein?

Die Schlüssellänge sollte mindestens 1024-bit betragen, kürzere Schlüssel können in kürzester Zeit geknackt werden. Die derzeitige Empfehlung für die Schlüssellänge liegt bei 2048-bit. Längere Schlüssel sind nicht zwangsläufig sicherer, da sie möglicherweise Probleme verursachen können.

TTL-Empfehlung für DKIM-Schlüssel

Die TTL (Time to Live) gibt an, wie lange ein DNS-Eintrag zwischengespeichert (cached) werden darf. Für DKIM-Schlüssel bedeutet dies, wie lange der öffentliche Schlüssel von DNS-Resolvern als gültig betrachtet wird, bevor er erneut abgefragt werden muss. Empfohlen wird eine TTL 86400 Sekunden (24 Stunden). Eine zu kurze TTL kann unnötigen DNS-Traffic verursachen, während eine zu lange TTL das Zurückziehen kompromittierter Schlüssel verzögern kann.

Muss ich den DKIM Schlüssel erneuern?

Die Erneuerung eines DKIM-Schlüssels ist nicht zwingend regelmäßig vorgeschrieben, wird aber aus Sicherheitsgründen empfohlen. Wie bei jedem kryptografischen Schlüssel kann eine zu lange Verwendung das Risiko eines Missbrauchs erhöhen. Empfohlen wird, den DKIM-Schlüssel alle 6 bis 12 Monate zu erneuern.

Dabei ist die Empfehlung, den alten Schlüssel im DNS zu belassen, bis der neue Schlüssel vollständig propagiert ist und alle E-Mails mit dem neuen Schlüssel signiert werden. Dies stellt sicher, dass E-Mails, die den alten Schlüssel verwenden, weiterhin verifiziert werden können, bis der alte Schlüssel nicht mehr benötigt wird.

DKIM-Schlüsselverwaltung per CNAME vereinfachen

Einige E-Mail-Dienstleister ermöglichen die DKIM-Einrichtung über einen CNAME-Eintrag, anstatt den öffentlichen Schlüssel direkt im DNS zu hinterlegen. Dabei verweist der CNAME-Eintrag auf einen vom Anbieter verwalteten DKIM-Schlüssel.

Vorteile
  • Kein manuelles Pflegen des DKIM-Records
  • Automatische Schlüsselrotation durch den Anbieter
  • Weniger Fehlerpotenzial bei der DNS-Konfiguration

💡Hinweis zu DNSSEC

Wenn du CNAME-Einträge für DKIM verwendest und deine Domain mit DNSSEC abgesichert ist, ist es wichtig, dass auch der E-Mail-Dienstleister DNSSEC auf seiner eigenen Domain aktiviert hat. Andernfalls kann die Vertrauenskette unterbrochen werden, und die DNSSEC-Validierung schlägt fehl. In sicherheitskritischen Umgebungen solltest du daher prüfen, ob der Anbieter DNSSEC korrekt unterstützt - insbesondere für die Ziel-Domain des CNAME-Eintrags.

Ed25519 für DKIM: Zukunftssicher, aber (noch) nicht überall einsetzbar

Ed25519 ist eine moderne, sichere und sehr effiziente Signaturalgorithmus-Variante, die im Vergleich zu RSA deutlich kürzere Schlüssel bei gleicher oder höherer Sicherheit bietet. Auch im Kontext von DKIM (DomainKeys Identified Mail) wird Ed25519 zunehmend diskutiert - allerdings gibt es dabei einige wichtige Punkte zu beachten.

✅ Vorteile von Ed25519
  • Kompaktere Schlüssel: Kürzere DNS-Einträge, was Probleme mit DNS-Längenbeschränkungen (z.B. 512-Byte-Limit) minimieren kann.
  • Höhere Sicherheit bei kürzerem Schlüssel: Ed25519 bietet mehr Sicherheit als ein 2048-Bit-RSA-Schlüssel bei nur 256 Bit.
  • Schnellere Verarbeitung: Besonders bei hoher E-Mail-Last kann die Performance spürbar besser sein.
⚠️ Einschränkungen und aktuelle Situation
  • Begrenzte Unterstützung: Viele Mailserver, Bibliotheken und insbesondere empfangende Systeme unterstützen Ed25519 noch nicht flächendeckend.
  • RFC-Status: Ed25519 für DKIM ist im RFC 8463 spezifiziert, aber im Ökosystem noch nicht vollständig verbreitet.
  • Probleme im DMARC Reporting: Beim Einsatz von Ed25519 kommt es bei manchen Anbietern zu Fehlern in der DKIM-Validierung, die sich negativ auf das DMARC-Reporting auswirken. In solchen Fällen liefern Provider oft nur eine generische Fehlermeldung zurück - ohne Angabe des betroffenen Selectors oder anderer hilfreicher Details. Das erschwert die Fehlersuche und ist im produktiven Betrieb ein klarer Nachteil.
  • Fallback erforderlich: Wenn du Ed25519 nutzen möchtest, solltest du parallel weiterhin einen klassischen RSA-Schlüssel bereitstellen, um maximale Kompatibilität zu gewährleisten.
🧭 Empfehlung

Für rein interne Systeme oder Testumgebungen kann Ed25519 eine gute Wahl sein. Für produktive E-Mail-Kommunikation mit externen Empfängern empfiehlt sich aktuell weiterhin die Verwendung von RSA (2048 Bit oder mehr), bis die Ed25519-Unterstützung breiter etabliert ist.