Was ist DKIM?

Diese Anleitung ist Teil unseres vollständigen Leitfadens zu DKIM. Verwandt: der DKIM-Record und wie DKIM-Signaturen funktionieren.

DKIM - DomainKeys Identified Mail - ist die zweite Säule der modernen E-Mail-Authentifizierung. Während SPF überprüft, dass eine Nachricht von einem autorisierten Server gesendet wurde, geht DKIM weiter: Es signiert die Nachricht selbst kryptografisch und beweist damit, dass der Inhalt nicht manipuliert wurde und dass die angegebene Absenderdomain die Nachricht tatsächlich autorisiert hat.

RFC 6376 definiert DKIM als eine Methode, um einen Domainnamen mit einer E-Mail-Nachricht zu verknüpfen, sodass eine Person, Rolle oder Organisation eine gewisse Verantwortung für die Nachricht übernehmen kann. Die Signatur übersteht die E-Mail-Weiterleitung, was ein entscheidender Vorteil gegenüber SPF ist.

DKIM zu verstehen ist für jeden, der E-Mail-Infrastruktur verwaltet, unerlässlich, denn das DKIM-Alignment ist einer der beiden Wege, die DMARC-Authentifizierung zu bestehen - und für weitergeleitete E-Mails ist es oft der einzige Weg.

Wie DKIM funktioniert: Das große Ganze

DKIM beruht auf einem einfachen kryptografischen Prinzip: Der sendende Server signiert die Nachricht mit einem privaten Schlüssel, und der empfangende Server überprüft die Signatur mit einem im DNS veröffentlichten öffentlichen Schlüssel.

Der Signiervorgang (ausgehend)

1. Der sendende Mailserver erzeugt einen Hash bestimmter E-Mail-Header und des Nachrichtentexts
2. Der Server verschlüsselt diesen Hash mit dem privaten DKIM-Schlüssel der Domain
3. Der Server fügt der Nachricht einen DKIM-Signature-Header hinzu, der den verschlüsselten Hash, den Selector-Namen, die signierende Domain und Metadaten darüber enthält, welche Header signiert wurden
4. Die Nachricht wird an den empfangenden Server übertragen

Der Überprüfungsvorgang (eingehend)

1. Der empfangende Server extrahiert den DKIM-Signature-Header aus der Nachricht
2. Er liest die Werte d= (Domain) und s= (Selector) aus der Signatur
3. Er führt einen DNS-Lookup für <selector>._domainkey.<domain> durch, um den öffentlichen Schlüssel abzurufen
4. Er verwendet den öffentlichen Schlüssel, um die Signatur zu entschlüsseln und den ursprünglichen Hash wiederherzustellen
5. Er hasht unabhängig davon dieselben Header und denselben Text mit dem angegebenen Algorithmus
6. Wenn die beiden Hashes übereinstimmen, ist die Signatur gültig - die Nachricht ist authentisch und unverändert

Für eine ausführliche technische Beschreibung dieses Vorgangs siehe Wie DKIM funktioniert: Ein umfassender Leitfaden zur E-Mail-Authentifizierung.

Für die Details des Überprüfungsalgorithmus auf RFC-Ebene siehe Ein Blick in RFC 6376: Wie die DKIM-Überprüfung tatsächlich funktioniert.

Der DKIM-Signature-Header

Ein DKIM-Signature-Header sieht so aus:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    c=relaxed/relaxed; q=dns/txt; t=1618884473;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

Tag	Bedeutung
v=1	DKIM-Version (immer 1)
a=rsa-sha256	Signieralgorithmus
d=example.com	Signierende Domain (für DMARC-Alignment verwendet)
s=selector1	Selector - gibt an, welcher öffentliche Schlüssel zu verwenden ist
c=relaxed/relaxed	Kanonisierungsmethode für Header/Text
q=dns/txt	Abfragemethode für den öffentlichen Schlüssel
t=1618884473	Zeitstempel der Signierung
h=from:to:subject:...	Liste der in der Signatur enthaltenen Header
bh=...	Body-Hash
b=...	Die Signatur selbst

DKIM-Schlüssel: Öffentlich und privat

DKIM verwendet asymmetrische Kryptografie. Der Domaininhaber erzeugt ein Schlüsselpaar:

• Privater Schlüssel - Sicher auf dem sendenden Mailserver gespeichert. Niemals geteilt oder veröffentlicht. Wird zum Signieren ausgehender Nachrichten verwendet.
• Öffentlicher Schlüssel - Im DNS als TXT-Record unter <selector>._domainkey.<domain> veröffentlicht. Wird von empfangenden Servern zur Überprüfung von Signaturen verwendet.

DNS-Record-Format

Ein DKIM-DNS-Record sieht so aus:

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Tag	Bedeutung
v=DKIM1	Version
k=rsa	Schlüsseltyp (RSA ist der Standard; Ed25519 kommt auf)
p=...	Der öffentliche Schlüssel, base64-kodiert

Sie können den öffentlichen DKIM-Schlüssel jeder Domain mit dem DKIM-Lookup-Tool nachschlagen.

Schlüssellängen

• 1024-Bit-RSA - Die empfohlene Mindestschlüssellänge. Noch weit verbreitet, aber nach modernen Maßstäben als schwach eingestuft.
• 2048-Bit-RSA - Der aktuell empfohlene Standard. Bietet starke Sicherheit, erzeugt aber längere DNS-Records, die möglicherweise eine Aufteilung des TXT-Records erfordern.
• Ed25519 - Ein neuerer, effizienterer Algorithmus, der kürzere Signaturen und Schlüssel erzeugt. Wird von einer wachsenden Zahl von Mailservern unterstützt, aber noch nicht universell.

Ausführliche Anleitung: Die kryptografischen Algorithmen von DKIM verstehen: RS256 vs. RS512 und aufkommende Trends

Selectoren: Mehrere Schlüssel verwalten

DKIM-Selectoren ermöglichen es einer Domain, mehrere DKIM-Schlüssel gleichzeitig zu veröffentlichen. Jeder Schlüssel wird durch eine Selector-Zeichenkette identifiziert, und das s=-Tag im DKIM-Signature-Header teilt dem Empfänger mit, welcher Selector (und damit welcher öffentliche Schlüssel) zur Überprüfung zu verwenden ist.

Selectoren erfüllen mehrere Zwecke:

• Mehrere Versanddienste - Ihr primärer Mailserver und jeder Drittanbieterdienst (SendGrid, Mailchimp usw.) können jeweils ihr eigenes DKIM-Schlüsselpaar mit einem eindeutigen Selector haben
• Schlüsselrotation - Beim Rotieren von Schlüsseln können Sie den neuen Schlüssel unter einem neuen Selector veröffentlichen, während der alte Selector während der Übergangsphase aktiv bleibt
• Abteilungstrennung - Verschiedene Teams oder Bereiche können zu Nachverfolgungs- und Verwaltungszwecken unterschiedliche Selectoren verwenden

Übliche Selector-Namenskonventionen sind s1, s2, google, sendgrid, k1 oder datumsbasierte Namen wie 202604.

Kanonisierung: Umgang mit Nachrichtenänderungen

E-Mail-Nachrichten werden unterwegs häufig verändert - Leerzeichen werden hinzugefügt oder entfernt, Header werden umgeschrieben, und Zeilenumbrüche können sich ändern. Die Kanonisierung legt fest, wie der Signier- und Überprüfungsvorgang die Nachricht vor dem Hashen normalisiert, sodass geringfügige Änderungen die Signatur nicht zerstören.

Es gibt zwei Kanonisierungsmodi, die unabhängig voneinander auf Header und Text angewendet werden:

• simple - Fast keine Änderungstoleranz. Header müssen exakt übereinstimmen (außer bei nachgestelltem Leerraum). Der Text wird nur für nachgestellte Leerzeilen normalisiert. Verwenden Sie dies, wenn Sie den gesamten Zustellweg kontrollieren und keine Zwischenstelle die Nachricht verändert.
• relaxed - Toleranter. Header-Namen werden in Kleinbuchstaben umgewandelt, Leerraum wird normalisiert, und mehrere Leerzeichen werden zu einem zusammengefasst. Im Text wird nachgestellter Leerraum aus jeder Zeile entfernt. Verwenden Sie dies für die meisten realen Bereitstellungen.

Die Einstellung c=relaxed/relaxed (relaxed für Header und Text) ist die häufigste und empfohlene Konfiguration.

DKIM-Alignment

Das DKIM-Alignment ist ein DMARC-Konzept, das bestimmt, ob die Domain in der DKIM-Signatur (d=-Wert) mit der Domain im sichtbaren From-Header übereinstimmt. Dies ist entscheidend, weil DMARC verlangt, dass mindestens eines von SPF oder DKIM sowohl gültig als auch ausgerichtet ist.

Relaxed-Alignment

Die organisatorischen Domains müssen übereinstimmen, aber Subdomains sind erlaubt. Zum Beispiel:

• From: user@example.com mit d=mail.example.com - Besteht das Relaxed-Alignment (dieselbe organisatorische Domain)
• From: user@example.com mit d=example.com - Besteht das Relaxed-Alignment

Strict-Alignment

Die Domains müssen exakt übereinstimmen:

• From: user@example.com mit d=example.com - Besteht das Strict-Alignment
• From: user@example.com mit d=mail.example.com - Scheitert am Strict-Alignment

Ausführliche Anleitung: DKIM-Alignment meistern: Schlüssel, Signaturen und warum E-Mails die Überprüfung nicht bestehen

DKIM-Schlüsselrotation

Private DKIM-Schlüssel sollten regelmäßig rotiert werden, um den Schaden zu begrenzen, falls ein Schlüssel kompromittiert wird. Der Rotationsvorgang umfasst:

1. Erzeugen eines neuen Schlüsselpaars mit einem neuen Selector
2. Veröffentlichen des neuen öffentlichen Schlüssels im DNS
3. Konfigurieren des sendenden Servers, mit dem neuen privaten Schlüssel zu signieren
4. Abwarten der DNS-Propagierung und Überprüfen der Signaturen mit dem neuen Schlüssel
5. Entfernen des alten öffentlichen Schlüssels aus dem DNS nach einer Übergangsphase

Wie oft sollten Sie rotieren? Es gibt keinen allgemeingültigen Standard, aber übliche Empfehlungen reichen von alle 6 Monate bis jährlich. Umgebungen mit hohen Sicherheitsanforderungen rotieren möglicherweise häufiger.

Ausführliche Anleitung: Wann sollten Sie Ihre DKIM-Schlüssel rotieren?

Warum DKIM fehlschlägt

Die DKIM-Überprüfung kann aus mehreren Gründen fehlschlagen:

Nachrichtenänderung unterwegs

Wenn ein signierter Header oder der Nachrichtentext nach der Signierung verändert wird, stimmt der Hash nicht überein und die Überprüfung schlägt fehl. Häufige Übeltäter sind:

• Mailinglisten, die Fußzeilen hinzufügen oder die Betreffzeile ändern
• E-Mail-Gateways, die Header für Compliance- oder Sicherheitsscans umschreiben
• Weiterleitungsdienste, die Nachrichten-Header verändern

DNS-Probleme

• Der öffentliche DKIM-Schlüssel-Record existiert nicht oder ist nicht erreichbar
• Der Selector in der Signatur passt zu keinem veröffentlichten Schlüssel
• DNS-Propagierungsverzögerungen nach einer Schlüsselrotation

Konfigurationsfehler

• Der private Schlüssel passt nicht zum veröffentlichten öffentlichen Schlüssel
• Der in der Signatur angegebene Signieralgorithmus passt nicht zum Schlüsseltyp
• Im h=-Tag aufgeführte Header wurden nicht in die tatsächliche Signaturberechnung einbezogen

Ausführliche Anleitungen:

• Warum schlägt DKIM fehl? Was können Sie dagegen tun?
• Fehler „Ungültige DKIM-Signatur”: So beheben Sie ihn
• Die häufigen SPF- und DKIM-Fehler im Jahr 2026 vermeiden

DKIM vs. SPF: Ergänzend, nicht konkurrierend

DKIM und SPF dienen unterschiedlichen Zwecken und haben unterschiedliche Stärken:

Merkmal	SPF	DKIM
Was es überprüft	IP-Adresse des sendenden Servers	Nachrichtenintegrität und -herkunft
Wie es funktioniert	DNS-Lookup autorisierter IPs	Überprüfung der kryptografischen Signatur
Übersteht Weiterleitung	Nein - Weiterleitung ändert die sendende IP	Ja - Signatur reist mit der Nachricht
Schützt Inhaltsintegrität	Nein	Ja - erkennt Manipulation
DNS-Record-Typ	TXT auf der Domain	TXT unter selector._domainkey.domain
Grundlage des DMARC-Alignments	Return-Path-Domain	d=-Domain in der Signatur

Da SPF bei der E-Mail-Weiterleitung zusammenbricht (die IP des weiterleitenden Servers steht nicht im SPF-Record der ursprünglichen Domain), ist DKIM oft die einzige Authentifizierungsmethode, die bei weitergeleiteten Nachrichten besteht. Das macht das DKIM-Alignment für Domains unverzichtbar, die Mailinglisten, Weiterleitungsregeln oder eine beliebige Relay-Infrastruktur nutzen.

Ausführliche Anleitungen:

• Wie sich SPF von DKIM und DMARC unterscheidet
• Sind Ihre SPF- und DKIM-Identifikatoren ausgerichtet?
• Wie man SPF-Tests, DKIM und DMARC für die Sicherheit kombiniert

DKIM für weitergeleitete und weitergereichte E-Mails

Einer der wichtigsten praktischen Vorteile von DKIM gegenüber SPF ist sein Verhalten bei der E-Mail-Weiterleitung. Wenn eine Nachricht über einen zwischengeschalteten Server weitergeleitet wird (eine Mailingliste, eine Auto-Weiterleitungsregel oder ein Relay-Dienst), bricht SPF zusammen, weil die IP-Adresse des weiterleitenden Servers nicht im SPF-Record der ursprünglichen Domain aufgeführt ist. DKIM hingegen übersteht die Weiterleitung, solange der Nachrichteninhalt nicht verändert wird. Wenn Sie neu darin sind, dies zu konfigurieren, beantwortet die AutoSPF-FAQ die häufigsten Einrichtungsfragen.

Deshalb ist DKIM für die DMARC-Konformität in Umgebungen mit folgenden Merkmalen entscheidend:

• Mailinglisten - Organisationen, die an Branchen-Mailinglisten oder internen Verteilergruppen teilnehmen
• E-Mail-Weiterleitung - Nutzer, die E-Mails von einem Anbieter an einen anderen weiterleiten (z. B. eine Universitätsadresse an Gmail weiterleiten)
• Shared Hosting - Umgebungen, in denen E-Mails über gemeinsam genutzte Relay-Server laufen
• E-Mail-Gateways - Sicherheitsgeräte, die E-Mails weiterleiten, ohne den Inhalt zu verändern

DKIM bricht jedoch zusammen, wenn die Zwischenstelle die signierten Teile der Nachricht verändert. Häufige Änderungen, die DKIM zerstören, sind das Hinzufügen von Fußzeilen, das Umschreiben der Betreffzeile oder das Entfernen von Anhängen. Mailinglisten-Software wie Mailman und LISTSERV fügt oft Listen-Header und -Fußzeilen hinzu, was textbasierte DKIM-Signaturen zerstören kann.

Die Lösung besteht darin, DKIM mit c=relaxed/relaxed-Kanonisierung zu konfigurieren (die geringfügige Leerraumänderungen toleriert) und sicherzustellen, dass jede von Ihnen betriebene Mailinglisten-Software so konfiguriert ist, dass sie DKIM-Signaturen nach Möglichkeit erhält.

Häufige DKIM-Konfigurationsmuster

Unterschiedliche E-Mail-Infrastruktur-Setups erfordern unterschiedliche DKIM-Konfigurationsansätze:

Einzelner Anbieter

Wenn Ihre gesamte E-Mail über einen einzigen Anbieter läuft (z. B. Google Workspace), übernimmt dieser Anbieter die DKIM-Signierung automatisch. Sie müssen lediglich den bereitgestellten öffentlichen Schlüssel in Ihrem DNS veröffentlichen.

Mehrere Anbieter mit separaten Selectoren

Wenn mehrere Dienste in Ihrem Namen E-Mails versenden, erhält jeder Dienst sein eigenes DKIM-Schlüsselpaar mit einem eindeutigen Selector. Zum Beispiel:

• google._domainkey.example.com - DKIM-Schlüssel von Google Workspace
• s1._domainkey.example.com - DKIM-Schlüssel von SendGrid
• k1._domainkey.example.com - DKIM-Schlüssel von Mailchimp

Jeder Dienst signiert Nachrichten mit seinem eigenen privaten Schlüssel, und Empfänger schlagen den korrekten öffentlichen Schlüssel anhand des Selectors im DKIM-Signature-Header nach.

Signierung vor Ort (On-Premises)

Organisationen, die ihre eigenen Mailserver betreiben (Exchange, Postfix, Exim), müssen ihre eigenen Schlüsselpaare erzeugen, den privaten Schlüssel auf dem Mailserver installieren und den öffentlichen Schlüssel im DNS veröffentlichen. Sie können ein Schlüsselpaar mit unserem kostenlosen DKIM-Generator erstellen. Das gibt Ihnen die volle Kontrolle über den Signiervorgang, erfordert aber, dass Sie die Schlüsselerzeugung, -rotation und -speicherung selbst verwalten.

DKIM und TLS: Verschiedene Sicherheitsebenen

DKIM und TLS (Transport Layer Security) tragen beide zur E-Mail-Sicherheit bei, arbeiten aber auf unterschiedlichen Ebenen:

• TLS verschlüsselt die Verbindung zwischen Mailservern während der Übertragung und verhindert so das Abhören unterwegs. Es überprüft nicht die Identität des Absenders und schützt nicht vor Spoofing.
• DKIM überprüft die Identität des Absenders und die Nachrichtenintegrität, verschlüsselt aber nicht den Nachrichteninhalt.

Beide sind für eine umfassende E-Mail-Sicherheit notwendig.

Ausführliche Anleitung: TLS und DKIM: Warum Sie beide für starke E-Mail-Sicherheit benötigen

DKIM für Ihre Plattform einrichten

Die DKIM-Konfiguration variiert je nach E-Mail-Plattform. Der allgemeine Vorgang ist:

1. Ein DKIM-Schlüsselpaar erzeugen (Ihre E-Mail-Plattform erledigt dies in der Regel)
2. Den öffentlichen Schlüssel als DNS-TXT-Record an der korrekten Selector-Position veröffentlichen
3. Die DKIM-Signierung auf der sendenden Plattform aktivieren
4. Die Konfiguration mit einem DKIM-Lookup überprüfen

Für plattformspezifische Anweisungen siehe diese Anleitungen:

• Der definitive Leitfaden zur SPF- und DKIM-Konfiguration in Microsoft 365
• DKIM-Authentifizierung: Ein vollständiger Leitfaden für sichere E-Mail-Zustellbarkeit
• SPF und DKIM für Salesforce einrichten
• SPF und DKIM für SendGrid meistern
• Vollständiger Leitfaden zur Einrichtung von SPF und DKIM für Mailgun
• Wie AutoSPF SPF und DKIM in cPanel ermöglicht

DKIM im Authentifizierungs-Stack

DKIM ist eines von drei Protokollen, die zusammenarbeiten, um E-Mails zu authentifizieren:

• SPF - Überprüft, dass der sendende Server autorisiert ist
• DKIM - Überprüft die Nachrichtenintegrität und stellt eine Signatur auf Domainebene bereit (diese Anleitung)
• DMARC - Verknüpft SPF und DKIM mit Alignment-Anforderungen, definiert die Durchsetzungsrichtlinie und ermöglicht die Berichterstattung

DMARC verlangt, dass mindestens eines von SPF oder DKIM besteht und mit der From-Header-Domain ausgerichtet ist. In der Praxis maximiert die Konfiguration von SPF und DKIM Ihre Chancen, DMARC zu bestehen, denn wenn eine Methode fehlschlägt (z. B. SPF aufgrund von Weiterleitung), kann die andere immer noch ein gültiges ausgerichtetes Ergebnis liefern.

Ausführliche Anleitungen:

• Wie SPF, DKIM und DMARC bei Authentifizierungsfehlern zusammenarbeiten
• E-Mail-Authentifizierungsprotokolle: SPF, DKIM, DMARC erklärt
• Wie man die Kompatibilität eines SPF-Flatteners mit DMARC und DKIM testet

Diagnosewerkzeuge

• DKIM-Lookup-Tool - Öffentliche DKIM-Schlüssel für jede Domain und jeden Selector nachschlagen und validieren
• Domain-Auth-Checker - SPF, DKIM und DMARC in einem einzigen Lookup prüfen
• SPF-Checker - Ihren SPF-Record neben DKIM validieren
• DMARC-Checker - Ihre DMARC-Richtlinie und Alignment-Einstellungen überprüfen

Nächste Schritte

1. Überprüfen Sie Ihr aktuelles DKIM-Setup - Verwenden Sie das DKIM-Lookup-Tool, um zu prüfen, ob Ihre Domain gültige DKIM-Schlüssel veröffentlicht hat
2. Prüfen Sie das Alignment - Stellen Sie sicher, dass die d=-Domain in Ihren DKIM-Signaturen mit Ihrer From-Header-Domain übereinstimmt
3. Überprüfen Sie die Schlüsselstärke - Bestätigen Sie, dass Sie mindestens 2048-Bit-RSA-Schlüssel verwenden
4. Planen Sie die Schlüsselrotation - Legen Sie einen Rotationsplan fest und dokumentieren Sie den Vorgang
5. Setzen Sie DMARC ein - Falls noch nicht geschehen, richten Sie DMARC ein, um das SPF- und DKIM-Alignment zu erzwingen und aggregierte Berichte zu erhalten
6. Überwachen Sie mit DMARC-Berichten - Verwenden Sie aggregierte DMARC-Berichte, um DKIM-Fehler über alle empfangenden Server hinweg zu identifizieren