Was ist DKIM? E-Mail-Signatur, DNS-Schlüssel, Selector und typische Fehler

Vom sendenden Mailserver bis zur empfangsseitigen Prüfung

Im ersten Schritt verarbeitet der sendende Mailserver ausgewählte Header sowie den Nachrichtentext. Er bildet daraus kryptografische Prüfwerte und erzeugt mit einem privaten Schlüssel die DKIM-Signatur. Dieser private Schlüssel muss geheim bleiben. Bei einem gehosteten Maildienst liegt er gewöhnlich in der Infrastruktur des Anbieters und wird nicht in die öffentliche DNS-Zone kopiert.

Im zweiten Schritt fügt der Mailserver der Nachricht das Header-Feld DKIM-Signature hinzu. Darin stehen unter anderem die signierende Domain, der verwendete Selector, die erfassten Header, der Body-Hash und der eigentliche Signaturwert. Diese Angaben verraten dem empfangenden Server, welchen öffentlichen Schlüssel er suchen und welche Nachrichtenteile er prüfen muss.

Im dritten Schritt bildet der Empfänger die DNS-Abfrage aus Domain und Selector. Mit dem dort veröffentlichten öffentlichen Schlüssel prüft er die Signatur. Passen Schlüssel, Signatur und erfasste Nachrichtendaten zusammen, lautet das Ergebnis typischerweise dkim=pass. Fehlt eine Signatur, kann dkim=none erscheinen; eine vorhandene, aber nicht erfolgreich verifizierte Signatur führt je nach Ursache und System etwa zu dkim=fail, temperror oder permerror.

Domain, Schlüssel, Selector und Signatur verständlich erklärt

• Domain: Die DKIM-Signatur nennt im Tag d= die Domain, die technisch die Verantwortung für die Signatur übernimmt. Sie muss nicht zwangsläufig identisch mit der sichtbaren Absenderdomain sein.
• Privater Schlüssel: Mit ihm signiert der sendende Mailserver die Prüfwerte der Nachricht. Er gehört ausschließlich in die kontrollierte Versandumgebung und darf nicht im DNS veröffentlicht werden.
• Öffentlicher Schlüssel: Mit diesem Gegenstück prüft der empfangende Mailserver die Signatur. Der Schlüssel darf öffentlich zugänglich sein, weil sich mit ihm allein keine gültige DKIM-Signatur erzeugen lässt.
• DNS-TXT-Eintrag: Der DKIM-Standard sieht den öffentlichen Schlüssel in einem TXT-Record vor. Manche Mailanbieter verlangen stattdessen eine CNAME-Delegation zu einem von ihnen verwalteten Schlüssel.
• Selector: Der Selector bezeichnet das konkrete Schlüsselpaar innerhalb einer Domain. Er steht im Tag s= und ermöglicht mehrere parallel nutzbare DKIM-Schlüssel.
• Header: Header sind die Steuer- und Metadaten einer E-Mail, etwa From, Subject, Date und MIME-Angaben. Die DKIM-Signatur nennt im Tag h=, welche Header sie erfasst.
• Signatur: Sie ist der kryptografische Prüfwert im b=-Tag des DKIM-Signature-Headers. Der Tag bh= enthält separat den Hash des kanonisierten Nachrichtentexts.

Welche Nachrichtenteile DKIM erfasst und wann Änderungen stören

DKIM signiert nicht automatisch jeden vorhandenen Header. Der From-Header muss von einer gültigen Signatur erfasst sein. Häufig kommen Date, Subject, Reply-To, Sender sowie MIME-bezogene Header hinzu. Welche Felder eine konkrete Nachricht schützt, erkennen Sie am h=-Tag. Der Textkörper fließt über den Body-Hash in die Prüfung ein.

Vor dem Berechnen der Prüfwerte vereinheitlicht DKIM die Nachricht nach einer sogenannten Kanonisierung. simple reagiert strenger auf Formatänderungen. relaxed toleriert begrenzte Unterschiede, beispielsweise bestimmte Änderungen an Leerzeichen oder der Faltung von Headerzeilen. Beliebige inhaltliche Änderungen bleiben jedoch nicht folgenlos.

Eine reine Weiterleitung kann eine DKIM-Signatur erhalten, solange die geschützten Daten unverändert bleiben. Gateways, Mailinglisten oder Disclaimer-Systeme ändern dagegen mitunter den Betreff, den Nachrichtentext, MIME-Grenzen oder die Kodierung. Dadurch kann eine ursprünglich gültige Signatur scheitern. DKIM verschlüsselt die Nachricht außerdem nicht: Inhalt und Transportweg benötigen bei entsprechendem Schutzbedarf separate Verfahren.

Warum ein DKIM-Name wie selector1._domainkey aussieht

Der vollständige DNS-Name entsteht nach dem Muster <selector>._domainkey.<signierende-domain>. Trägt eine Signatur beispielsweise s=selector1 und d=example.com, fragt der Empfänger selector1._domainkey.example.com ab. _domainkey kennzeichnet dabei den für DKIM reservierten Namensbereich; selector1 bezeichnet den konkreten Schlüssel.

Viele DNS-Oberflächen erwarten im Feld für den Hostnamen lediglich selector1._domainkey und ergänzen die verwaltete Zonendomain automatisch. Tragen Sie dort zusätzlich example.com ein, kann unbeabsichtigt ein Name wie selector1._domainkey.example.com.example.com entstehen. Prüfen Sie deshalb nach dem Speichern den vollständigen öffentlich aufgelösten Namen und nicht nur die Darstellung im Kundenmenü.

Eine Domain darf mehrere Selector besitzen. Verschiedene Mailanbieter, Transaktionssysteme, Newsletterdienste oder Schlüsselgenerationen können jeweils einen eigenen Namen verwenden. Das ist kein Konflikt: Jede Signatur nennt über s= genau den Schlüssel, den der Empfänger abrufen soll. Problematisch sind dagegen mehrere konkurrierende Schlüssel-Records unter demselben vollständigen Selector-Namen, weil die Zuordnung dadurch uneindeutig oder nicht standardkonform wird.

Auch ein langer TXT-Wert darf innerhalb eines einzelnen TXT-Records aus mehreren Zeichenketten bestehen. DNS-Werkzeuge setzen diese ohne zusätzliches Leerzeichen zusammen. Ein sichtbarer Umbruch oder mehrere Anführungszeichen sind daher nicht automatisch ein Fehler. Auch RFC-konformes Folding White Space innerhalb des p=-Werts kann zulässig sein; übernehmen Sie den Anbieterwert aus praktischen Gründen dennoch unverändert. Belastbare Fehlermerkmale sind fehlende oder abgeschnittene Fragmente, zusätzliche Nicht-Whitespace-Zeichen, eine beschädigte Tag-Struktur oder mehrere konkurrierende TXT-Records am identischen Selector-Namen.

TXT-Schlüssel und CNAME-Delegation nicht verwechseln

Im Standardfall enthält ein DNS-TXT-Record Angaben wie die DKIM-Version und den öffentlichen Schlüssel. Google Workspace stellt Administratoren typischerweise einen solchen TXT-Namen und TXT-Wert bereit. Andere Plattformen delegieren die Schlüsselverwaltung per CNAME. Microsoft 365 verwendet für benutzerdefinierte Domains typischerweise zwei providerseitig erzeugte Selector-CNAMEs, zwischen denen der Dienst bei einer Rotation wechseln kann.

Legen Sie daher nicht pauschal einen TXT-Record an. Übernehmen Sie Record-Typ, Hostname und Zielwert aus dem Administrationsbereich Ihres konkreten Mailanbieters. Beispielwerte aus Anleitungen eignen sich nur zur Erklärung des Prinzips. Bei RSA-Schlüsseln sind 2048 Bit eine übliche sinnvolle Auswahl, sofern Maildienst und DNS-Anbieter diese Schlüssellänge unterstützen.

Schlüssel mit zwei Selectors ohne Zustellungsunterbrechung wechseln

Angenommen, Ihr Mailserver signiert bisher mit mail2026a. Für die Rotation veröffentlichen Sie zusätzlich den neuen öffentlichen Schlüssel unter mail2026b._domainkey. Sobald dieser öffentlich erreichbar ist, schaltet der Signierer auf den privaten Schlüssel von mail2026b um. Neue Nachrichten tragen danach s=mail2026b.

Der alte Record mail2026a bleibt während einer Übergangsfrist bestehen. Dadurch können Empfänger ältere Nachrichten oder verzögert zugestellte E-Mails weiterhin mit dem alten öffentlichen Schlüssel prüfen. Entfernen Sie ihn erst, wenn der alte Selector nicht mehr für legitime Nachrichten benötigt wird. Ein neuer Selector ist meist klarer als der sofortige Austausch des Schlüssels unter demselben Namen, weil sich alte und neue Signaturen eindeutig unterscheiden lassen.

SPF, DKIM und DMARC prüfen unterschiedliche Ebenen

SPF bewertet die Versandquelle. Der empfangende Server prüft anhand der verbindenden IP-Adresse und des SPF-Records, ob der sendende Host eine bestimmte Domain aus dem SMTP-Umschlag verwenden darf. SPF prüft keine kryptografische Nachrichtensignatur und nicht unmittelbar die sichtbare Adresse im From-Header.

DKIM bewertet die Signatur. Die Prüfung bezieht sich auf die im d=-Tag genannte Domain und auf die erfassten Nachrichtendaten. Sie kann Weiterleitungen besser überstehen als SPF, solange zwischengeschaltete Systeme die signierten Bestandteile nicht verändern.

DMARC verbindet Authentifizierung, Alignment, Richtlinie und Berichte. Für einen DMARC-Erfolg muss mindestens ein erfolgreiches SPF- oder DKIM-Ergebnis zur sichtbaren Absenderdomain ausgerichtet sein. Bei DKIM wird die Domain aus d= mit der Domain des sichtbaren From-Headers verglichen. Je nach Richtlinie genügt dieselbe organisatorische Domain oder es wird eine exakte Übereinstimmung verlangt.

Deshalb können die Ergebnisse dkim=pass und dmarc=fail gleichzeitig auftreten. Signiert ein Versanddienst gültig mit d=provider.example, während die sichtbare Absenderadresse zu firma.example gehört, fehlt das DKIM-Alignment. Eine benutzerdefinierte DKIM-Konfiguration soll in solchen Fällen dafür sorgen, dass der Dienst mit einer zur Absenderdomain passenden Domain signiert.

Eine Nachricht kann mehrere DKIM-Signaturen tragen, etwa vom ursprünglichen Versanddienst und einem nachgelagerten Gateway. Für DMARC kann eine einzige erfolgreiche und aligned Signatur genügen, auch wenn eine andere Signatur scheitert. Trotzdem garantiert weder DKIM noch DMARC eine Posteingangsplatzierung. Beide prüfen technische Domainbeziehungen, nicht die Qualität des Inhalts und nicht die Vertrauenswürdigkeit einer natürlichen Person.

Häufige Fragen zu DKIM

Was bedeutet DKIM?

DKIM bedeutet DomainKeys Identified Mail. Das Verfahren versieht ausgehende E-Mails mit einer Domain-Signatur, die Empfänger mithilfe eines öffentlichen DNS-Schlüssels prüfen. Es belegt keine persönliche Identität und bewertet nicht die Seriosität des Inhalts.

Was ist ein DKIM-Selector?

Der Selector ist der Name eines bestimmten DKIM-Schlüssels innerhalb der signierenden Domain. Er steht im s=-Tag. Zusammen mit der Domain aus d= bildet er den DNS-Namen nach dem Muster selector._domainkey.domain.

Wo wird DKIM eingetragen?

Der öffentliche Schlüssel oder die providerabhängige Delegation wird in der DNS-Zone der signierenden Domain eingetragen. Übernehmen Sie den vorgegebenen Record-Typ, Namen und Wert aus Ihrem Maildienst. Die Signierung selbst muss zusätzlich im sendenden System aktiviert sein.

Was ist ein öffentlicher Schlüssel?

Der öffentliche Schlüssel ist der frei abrufbare Teil eines kryptografischen Schlüsselpaars. Empfänger verwenden ihn zur Prüfung der DKIM-Signatur. Der zugehörige private Schlüssel bleibt beim signierenden Mailserver und darf nicht veröffentlicht werden.

Ist DKIM ein Spamfilter?

Nein. DKIM liefert ein Authentifizierungssignal, filtert aber nicht selbst nach Spam, Schadsoftware oder betrügerischem Inhalt. Ein Spammer kann die eigene Domain ebenfalls korrekt signieren. Empfänger beziehen DKIM deshalb in umfassendere Filter- und Reputationssysteme ein.

Was ist der Unterschied zwischen SPF und DKIM?

SPF prüft, ob die verbindende Versandquelle für eine Domain aus dem SMTP-Umschlag autorisiert ist. DKIM prüft eine kryptografische Signatur über ausgewählte Nachrichtendaten. Beide Ergebnisse können unabhängig voneinander erfolgreich sein oder scheitern.

Warum schlägt DKIM fehl?

Häufig fehlen Signatur oder DNS-Schlüssel, Selector und Domain stimmen nicht überein, der Schlüssel wurde beschädigt kopiert oder ein alter Record ist aktiv. Auch nachträgliche Änderungen durch Gateways, Weiterleitungen und Mailinglisten können eine zuvor gültige Signatur brechen.

Kann eine Domain mehrere DKIM-Einträge haben?

Ja. Mehrere Selector für verschiedene Anbieter oder Schlüsselgenerationen sind regulär und unterstützen sichere Rotationen. Vermeiden Sie dagegen mehrere konkurrierende Schlüssel-Records unter demselben vollständigen Selector-Namen. Jede Signatur muss eindeutig zum veröffentlichten Schlüssel ihres Selectors passen.