Was ist DKIM? E-Mail-Authentifizierungsstandard erklärt

DKIM (DomainKeys Identified Mail) ist ein kryptografisches E-Mail-Authentifizierungsprotokoll. Was ist DKIM in der Praxis: Es hängt an jede ausgehende Nachricht eine RSA-Signatur an, die dein Mailserver erstellt. Der empfangende MTA ruft deinen öffentlichen Schlüssel aus dem DNS ab, verifiziert diese Signatur und meldet das Ergebnis als dkim=pass oder dkim=fail. Dieses Ergebnis fließt in das Reputationsmodell deiner Domain ein und bestimmt, ob die DMARC-Ausrichtung gilt. Ohne gültige Signatur hat der empfangende MTA keine kryptografische Bestätigung, dass die Nachricht von deiner Infrastruktur stammt.

DKIM ist ein Signierprotokoll, kein Filter

Der Name lädt zu einem häufigen Missverständnis ein. DKIM blockiert keine E-Mails. Es stellt keine Nachrichten in Quarantäne und setzt allein keine Richtlinien durch. Was es tut: Es versieht jede ausgehende Nachricht mit einer verifizierbaren Aussage. Diese Nachricht wurde vom Domain im Feld d= signiert, mit dem privaten Schlüssel, der zum Selektor s= gehört.

Der empfangende MTA nimmt diese Aussage, erstellt eine DNS-Anfrage an <Selektor>._domainkey.<Domain>, ruft den TXT-Eintrag mit dem öffentlichen Schlüssel ab und führt die kryptografische Verifizierung durch. Wenn die Verifizierung erfolgreich ist, zeigt der Authentifizierungsergebnis-Header dkim=pass. Schlägt sie fehl, siehst du dkim=fail oder dkim=temperror.

Keines dieser Ergebnisse verursacht allein eine Ablehnung. Das Signal fließt in das Reputationsmodell des Empfangsservers ein und, entscheidend, in die DMARC-Auswertung. DKIMs Aufgabe ist es, ein verifizierbares Ergebnis zu liefern, nicht darauf zu handeln.

Was DKIM signiert und was die Signatur abdeckt

DKIM signiert zwei Dinge: ausgewählte Nachrichtenheader und den Nachrichtenrumpf. Der Signierungsalgorithmus hasht beides und speichert das Ergebnis im Header-Feld DKIM-Signature.

Die Headerliste wird durch den Tag h= in der Signatur gesteuert. Ein typisches Produktions-Setup enthält from:subject:date:message-id:content-type. Der from-Header ist das Feld, das für die DMARC-Ausrichtung zählt. Der Body-Hash deckt den vollständigen Nachrichtenrumpf ab, kanonisiert via simple- oder relaxed-Kanonisierung.

Die relaxed-Kanonisierung ist das, was die meisten Produktions-Stacks verwenden. Sie normalisiert Leerzeichen vor dem Hashing, wodurch die Signatur kleinere Umformatierungen durch Relay-MTAs überleben kann. Die simple-Kanonisierung ist strenger: eine einzelne abschließende Leerzeichen-Änderung bricht die Signatur. Du wirst c=relaxed/relaxed im DKIM-Signature-Header praktisch jedes gut konfigurierten ESP sehen.

Was DKIM nicht signiert: den SMTP-Envelope-Absender, Routing-Header wie Received und jeden Header außerhalb der h=-Liste. Das ist beabsichtigt. Die Signierung des Envelopes würde Weiterleitungsszenarien beschädigen, und das ist genau der Vorteil von DKIM gegenüber SPF.

Der Selektor: ein Zugangskontroll-Handle, das die meisten Teams wie ein Label behandeln

Der Selektor ist der Teil von DKIM, den die meisten Teams unterschätzen, bis sie unter Druck Schlüssel rotieren müssen.

Das Feld s= in deiner DKIM-Signature zeigt auf einen spezifischen öffentlichen Schlüssel in deinem DNS. Das Lookup-Format ist <Selektor>._domainkey.<deinedomain.com>. Wenn dein Selektor mail2026 ist und deine Domain example.com, sucht der Resolver nach einem TXT-Eintrag bei mail2026._domainkey.example.com.

Eine Domain kann mehrere Selektoren gleichzeitig aktiv haben. Jeder Versanddienst, jeder ESP, jeder interne MTA sollte seinen eigenen Selektor verwenden. Das gibt dir drei konkrete operationale Fähigkeiten:

• Unabhängige Schlüsselrotation pro Dienst, ohne andere Absender zu beeinflussen.

• Nachverfolgbare Attribution in Authentifizierungsprotokollen: der Selektor sagt dir, welcher Signierschlüssel für eine bestimmte Nachricht verwendet wurde.

• Sauberes Offboarding: lösche den DNS-Eintrag des Selektors und dieser ESP kann unabhängig davon, was er auf seiner Seite tut, nicht mehr als deine Domain signieren.

À l'usage, voilà ce qu'on observe dans les traces: Teams, die einen gemeinsamen Selektor für alle ihre Sendedienste konfigurieren, können den Zugang für einen Absender nicht widerrufen, ohne alle anderen zu stören. Der Selektor ist nicht kosmetisch. Er ist ein Zugangskontroll-Handle.

DKIM und DMARC-Ausrichtung: wie die Durchsetzungsschicht wirklich funktioniert

DKIM zu bestehen ist eine Voraussetzung für eine bestimmte Art von DMARC-Erfolg, die als DKIM-Ausrichtung bezeichnet wird.

DMARC erfordert mindestens eine von zwei Ausrichtungsbedingungen: SPF-Ausrichtung oder DKIM-Ausrichtung. DKIM-Ausrichtung bedeutet, dass die Domain im From:-Header mit dem d=-Wert in der DKIM-Signatur übereinstimmt und die Signatur verifiziert wird. Wenn beide Bedingungen erfüllt sind, betrachtet DMARC die Nachricht als authentifiziert.

Das ist der Grund, warum DKIM das dauerhaftere Authentifizierungssignal ist. SPF-Ausrichtung bricht bei der Weiterleitung: wenn eine Nachricht weitergeleitet wird, ändert sich der SMTP-Envelope-Absender und die SPF-Auswertung schlägt gegenüber der neuen Versand-IP fehl. DKIM-Ausrichtung überlebt die Weiterleitung, weil die Signatur und der From:-Header mit dem Nachrichtenrumpf mitreisen und nicht von Relay-MTAs umgeschrieben werden, vorausgesetzt, der Rumpf wird nicht im Transit modifiziert.

Für Domains mit einer DMARC-Richtlinie p=reject wird eine Nachricht, die sowohl SPF- als auch DKIM-Ausrichtung fehlschlägt, vom empfangenden MTA abgelehnt. Das ist der Mechanismus, der gefälschte E-Mails von deiner Domain daran hindert, Posteingänge in großem Maßstab zu erreichen. DKIM ist hier nicht die letzte Verteidigungslinie. Aber es ist die Linie, die hält, wenn Weiterleitung im Pfad liegt.

Seit 2024 verlangen Google, Yahoo und Microsoft DKIM für Massenversender, die 5.000 oder mehr Nachrichten pro Tag an ihre MX senden. Nachrichten von unsignierten Domains werden standardmäßig in den Spam-Ordner weitergeleitet oder abgelehnt.

Ce n'est pas une feature marketing. C'est une contrainte d'infrastructure.

Schlüssellänge und Rotation: praktische Entscheidungen für 2026

Die meisten DKIM-Implementierungen verwenden RSA-SHA256. Die entscheidende Frage ist die Schlüssellänge.

1024-Bit-RSA-Schlüssel erscheinen noch in Legacy-Konfigurationen. Das NIST hat RSA mit 1024 Bit für die meisten Anwendungsfälle 2015 als veraltet eingestuft. Ein 2048-Bit-Schlüssel bietet erheblich größere Sicherheitsmarge und wird von allen wichtigen MTAs und Empfangsanbietern unterstützt. Wenn du heute einen neuen Schlüssel generierst, verwende 2048 Bit.

Einige Teams haben ihren aktiven Signierschlüssel auf 2048 Bit migriert, aber alte 1024-Bit-Selektoren im DNS veröffentlicht gelassen, weil niemand das Inventar geprüft hat. Trois signaux qui changent le comportement du moteur: wenn du k=rsa mit einem 1024-Bit-Schlüssel in einem alten Selektor siehst, ist dieser Selektor eine Schwachstelle, auch wenn deine aktuelle Signierinfrastruktur bereits umgestellt hat. Ein gültiger, aber veralteter Selektor ist ausnutzbar.

Schlüsselrotationsplan: die meisten Infrastruktur-Teams rotieren jährlich, einige vierteljährlich für Domains mit höherer Sensibilität. Die Reihenfolge ist entscheidend:

1. Ein neues Schlüsselpaar generieren.

2. Den neuen öffentlichen Schlüssel unter einem neuen Selektornamen im DNS veröffentlichen.

3. Auf TTL-Propagierung warten, typischerweise 24 bis 48 Stunden für Einträge mit niedrigem TTL.

4. Den Signierschlüssel in der MTA-Konfiguration auf den neuen Selektor umstellen.

5. dkim=pass auf ausgehenden Nachrichten via ein E-Mail-Test-Tool oder durch Inspektion der Authentifizierungsergebnis-Header einer Testnachricht verifizieren.

6. Nach Bestätigung, dass der neue Schlüssel aktiv ist und korrekt signiert, den alten DNS-Eintrag löschen.

Die Rotation ist unterbrechungsfrei, wenn du die Reihenfolge einhältst: DNS zuerst, Schlüsselumstellung danach, Löschung des alten Eintrags zuletzt. Das Vertauschen von Schritt 4 und 6 erzeugt ein dkim=fail-Fenster.

Operative Signale nach der DKIM-Einrichtung überwachen

DKIM ist keine einmalige Konfigurationsaufgabe. Die folgenden Signale zeigen an, dass etwas abgedriftet oder ausgefallen ist.

dkim=temperror in empfangenen Headern. Temporäre Fehler weisen in der Regel auf DNS-Lookup-Probleme auf der Empfängerseite hin oder auf eine TTL-Diskrepanz während der Schlüsselrotation. Wenn du dies auf ausgehenden Nachrichten kurz nach einer Schlüsselrotation siehst, warte auf die vollständige Propagierung, bevor du schlussfolgern, dass der Schlüssel selbst falsch konfiguriert ist.

dkim=fail auf von dir gesendeten Nachrichten. Körpermodifikation durch einen zwischengeschalteten Relay ist die häufigste Ursache. Prüfe, ob ein Weiterleitungs-Hop, ein Mailinglisten-Prozessor oder ein Relay, das Fußzeilen einfügt, im Zustellpfad liegt. Wenn der Fehler bei einem einzigen Flow konsistent ist, kartiere die Relay-Kette Hop für Hop.

DKIM-Signature-Header vollständig fehlend. Der Signierdaemon auf deinem MTA läuft nicht, der Pfad zum Signierschlüssel ist falsch, oder das Domain-Selektor-Mapping ist in deiner MTA-Konfiguration falsch konfiguriert. Das ist ein vollständiger DKIM-Ausfall für die betroffenen Nachrichtenflows.

Selektor-TXT-Eintrag fehlt im DNS. Die DNS-Zone wurde bearbeitet oder migriert, ohne den DKIM-Selektoreintrag zu erhalten. Verifiziere mit dig TXT <Selektor>._domainkey.<Domain> von einem externen Resolver.

Bei einem Multi-Region-Versand-Setup werden inkonsistente DKIM-Ergebnisse zwischen Knoten häufig durch Knoten verursacht, die unterschiedliche Selektorkonfigurationen verwenden. Bestätige, dass die Signierschlüsselkonfiguration über alle Sendeknoten synchronisiert ist, bevor du eine Rotation einführst.

Wogegen DKIM nicht schützt

DKIM ist kein Spam-Filter. Ein Absender kann eine neue Domain registrieren, gültiges DKIM konfigurieren und vollständig authentifizierten Spam versenden. Die Signatur wird sauber verifiziert. Authentifizierung bestätigt Herkunft, nicht Absicht oder Inhaltsqualität.

DKIM adressiert auch nicht das Spoofing von Anzeigenamen, wo der From:-Header einen vertrauenswürdigen Namen wie "Gehaltsabrechnung-Team" zeigt, der mit einer vom Angreifer kontrollierten Domain gepaart ist. Die kryptografische Verifizierung operiert auf der Domain, nicht auf der visuellen Darstellung im MUA. Die meisten Phishing-Versuche auf MUA-Ebene basieren auf Täuschung durch Anzeigenamen statt auf exaktem Domain-Spoofing.

Wogegen DKIM schützt: exaktes Domain-Spoofing, bei dem ein Angreifer versucht, von deiner Domain zu senden, ohne deinen privaten Schlüssel zu besitzen. In Kombination mit einer DMARC-Richtlinie p=reject, die DKIM-Ausrichtung erzwingt, verhindert dies, dass diese Klasse gefälschter Nachrichten Posteingänge bei den empfangenden Anbietern erreicht, die DMARC durchsetzen.

Praktisch gesehen: DKIM allein reicht nicht aus. Das Schutzmodell erfordert die DMARC-Richtliniendurchsetzung durch den empfangenden MTA. DKIM ist die Authentifizierungsschicht, die DMARC sinnvoll macht. SPF ist die andere Authentifizierungsschicht und behandelt die Envelope-Absender-Verifizierung. Alle drei arbeiten zusammen. Das Fehlen einer von ihnen hinterlässt eine Lücke in der Durchsetzungskette. Ce n'est pas une feature marketing. C'est une contrainte d'infrastructure.

Wenn du bereits DKIM und SPF eingerichtet hast, aber noch keinen DMARC-Eintrag veröffentlicht hast, existieren die Signaturen, aber keine Durchsetzungsrichtlinie ist aktiv. Der Monitoring-Modus (p=none mit rua-Reporting) ist ein vernünftiger erster Schritt: Du erhältst aggregierte Berichte, die Authentifizierungserfolgsraten über deine Sendedomain anzeigen, bevor du dich auf p=quarantine oder p=reject festlegst.

Auf einem Multi-Region-Produktions-Stack bedeutet das in der Praxis: Bevor du eine neue DMARC-Richtlinie aktivierst, solltest du die Berichte über mindestens vier Wochen hinweg beobachten. Nur so erkennst du, welche Sendeinfrastruktur noch nicht korrekt signiert oder welcher Drittanbieter noch nicht auf deinen Selektor aufgeschaltet ist.