DKIM signiert jede ausgehende E-Mail digital mit einem privaten Schlüssel, den nur Ihr Mailserver kennt. Der passende öffentliche Schlüssel liegt im DNS Ihrer Domain – damit kann jeder Empfänger prüfen, ob eine Nachricht tatsächlich unverändert von Ihnen stammt. Anders als SPF interessiert sich DKIM nicht dafür, welcher Server die Mail verschickt hat, sondern ob die Nachricht selbst echt ist.
Was die Signatur tatsächlich beweist
Jede DKIM-signierte E-Mail trägt einen unsichtbaren Header mit einer digitalen Signatur, erzeugt aus dem Inhalt der Nachricht und ausgewählten Header-Feldern. Der Empfänger holt sich den öffentlichen Schlüssel aus dem DNS und prüft damit zwei Dinge: Stammt die Signatur tatsächlich vom privaten Schlüssel dieser Domain, und stimmt der signierte Inhalt noch mit dem exakt überein, was ankam? Wurde auch nur ein Zeichen im Betreff oder Text nachträglich verändert, schlägt die Prüfung fehl.
Das ist ein reiner Integritäts- und Herkunftsnachweis für die technische Absender-Domain im Signatur-Header (d=) – nicht für die Adresse, die im Postfach als Absender angezeigt wird. Diese Verknüpfung stellt erst DMARC her.
Der Aufbau in Kürze
Der DKIM-Header und der zugehörige DNS-Eintrag bestehen aus wenigen Feldern:
| Feld | Bedeutung |
|---|---|
d= | Die Domain, die signiert hat |
s= | Der Selector – erlaubt mehrere Schlüssel pro Domain gleichzeitig |
bh= | Hash-Wert des Nachrichtentexts (Integritätsprüfung) |
b= | Die eigentliche Signatur |
Der öffentliche Schlüssel liegt im DNS unter selector._domainkey.ihredomain.ch als TXT-Eintrag, etwa v=DKIM1; k=rsa; p=MIGfMA0.... Der Selector-Name (s=) macht es möglich, dass Ihr eigener Mailserver und ein externer Newsletter-Dienst gleichzeitig mit unterschiedlichen Schlüsseln unter derselben Domain signieren, ohne sich zu stören.
Warum jeder Drittversender einen eigenen Selector braucht
Newsletter-Tools, CRM-Systeme oder Buchhaltungssoftware, die in Ihrem Namen E-Mails verschicken, müssen für DKIM einen eigenen Schlüssel und Selector bei Ihnen im DNS hinterlegt bekommen. Fehlt dieser Schritt, verlässt die Mail den Drittdienst unsigniert oder mit einer fremden Signatur – die DKIM-Prüfung schlägt fehl, selbst wenn SPF für diesen Dienst korrekt eingerichtet ist.
Ein Beispiel: Ein Treuhandbüro nutzt eine Buchhaltungssoftware, die Rechnungen direkt per E-Mail im Namen der Kanzlei verschickt. SPF wurde beim Onboarding korrekt ergänzt, der DKIM-Selector des Anbieters aber nie eingetragen. Die Rechnungsmails werden zugestellt – SPF genügt vielen Filtern noch – landen bei zunehmend mehr Empfängern aber im Spam-Ordner, weil die DKIM-Prüfung fehlschlägt und das Gesamtbild der Authentifizierung lückenhaft wirkt.
Was DKIM ausdrücklich nicht leistet
- Es prüft nicht den Inhalt der Nachricht auf Spam oder Phishing-Merkmale.
- Es garantiert nicht, dass die im Posteingang sichtbare Absenderadresse mit der signierenden Domain übereinstimmt – eine gültige Signatur kann auch von einer ganz anderen Domain stammen als der, die der Empfänger liest.
- Es verhindert nicht, dass jemand ohne jede Signatur in Ihrem Namen versendet – das schliesst erst DMARC.
DKIM beweist, dass eine Nachricht unterwegs nicht verändert wurde. Es beweist nicht, dass ihr Inhalt vertrauenswürdig ist oder dass die angezeigte Absenderadresse stimmt.
Wo DKIM hält und SPF bricht — vier typische Transportwege
SPF und DKIM fallen nicht in denselben Situationen aus. Das ist kein Zufall, sondern der Grund, warum beide nebeneinander stehen sollen: Sie decken die Schwäche des jeweils anderen ab.
| Was mit der Mail passiert | SPF-Ergebnis beim Empfänger | DKIM-Ergebnis beim Empfänger |
|---|---|---|
| Direkter Versand vom eigenen Mailserver | pass, sofern die IP im Record steht | pass, sofern der Selector im DNS liegt |
| Automatische Weiterleitung durch den Empfänger | fail – der weiterleitende Server sendet mit eigener IP | pass, solange die Nachricht unverändert bleibt |
| Mailingliste, die Betreff-Präfix oder Fusszeile anhängt | fail – die Liste sendet unter eigener Adresse | fail – der signierte Inhalt wurde verändert |
| Drittversender ohne hinterlegten Selector | pass, wenn der Dienst im SPF-Record steht | fail – es liegt gar keine gültige Signatur vor |
Die dritte Zeile ist der Grund, warum auch ein sauber eingerichtetes Setup an Mailinglisten scheitern kann – und warum DMARC schon dann greift, wenn eines der beiden Verfahren besteht.
Wie Sie Ihre DKIM-Signatur selbst prüfen und einen Selector einrichten
DKIM lässt sich ohne Spezialwerkzeug verifizieren – die Beweismittel stehen in jeder Mail, die Sie sich selbst schicken:
- Eine Testmail an ein externes Postfach senden, von jedem produktiven Versandweg einzeln: Mailserver, Newsletter-Tool, CRM, Buchhaltung, Formular der Website. Ein einziger Test vom Hauptserver aus sagt nichts über die anderen Wege.
- Den Quelltext der Nachricht öffnen und den Header
Authentication-Resultssuchen. Dort stehtdkim=passoderdkim=fail, dazu die signierende Domain (header.d=) und der verwendete Selector. - Den öffentlichen Schlüssel gegenprüfen:
dig TXT selector._domainkey.ihredomain.ch +short. Kommt nichts zurück, ist der DNS-Eintrag nicht (oder falsch) gesetzt – dann kann keine Signatur bestehen, egal wie korrekt der Versender signiert. - Prüfen, ob
d=zur sichtbaren Absenderdomain passt. Signiert ein Dienstleister mit seiner eigenen Domain (d=mailtool.example), während Ihre Kundenihrefirma.chsehen, besteht DKIM zwar – für DMARC ist es aber wertlos, weil das Alignment fehlt. Erst ein Selector unter Ihrer Domain löst das. - Alte Selectoren aufräumen. Jeder DNS-Eintrag unter
_domainkey, dessen Dienst Sie nicht mehr nutzen, gehört gelöscht.
Zwei Fallstricke, an denen es in der Praxis scheitert:
- Der Schlüssel passt nicht in einen TXT-String. Ein DNS-TXT-String darf maximal 255 Zeichen lang sein. Ein 2048-Bit-RSA-Schlüssel ist länger – er muss deshalb in mehrere aneinandergehängte Strings aufgeteilt werden. Viele DNS-Oberflächen erledigen das automatisch, manche nicht, und einzelne schneiden den Wert stillschweigend ab. Das Ergebnis ist ein Eintrag, der vorhanden aussieht und trotzdem jede Prüfung scheitern lässt. Nach dem Eintragen also immer per
diggegenlesen, ob der zurückgegebene Schlüssel vollständig ist. - Schlüsselrotation ohne Überlappungsfrist. Wird der alte Selector im DNS gelöscht, sobald der neue aktiv ist, scheitert die Prüfung für alle Mails, die noch unterwegs sind oder verzögert zugestellt werden – sie tragen die alte Signatur, deren Schlüssel gerade verschwunden ist. Korrekt ist die Reihenfolge: neuen Selector im DNS anlegen, dann den Versender auf den neuen Schlüssel umstellen, den alten Eintrag erst nach einigen Tagen entfernen. Dafür existieren Selectoren überhaupt.
Eine Signatur beweist, dass die Nachricht echt ist — nicht, dass der Absender stimmt
Wenn eine Firma feststellt, dass ihre Rechnungen im Spam-Ordner der Kunden landen, ist die erste Reaktion meist Ratlosigkeit: Der Text ist derselbe wie immer, der Absender auch, und trotzdem wird die Mail aussortiert. Was sich geändert hat, ist selten die Mail – es ist die Strenge, mit der die grossen Mail-Anbieter prüfen.
Eine digitale Signatur ist dabei so etwas wie ein Siegel auf einem Couvert. Ihr Mailserver drückt es beim Versand auf jede Nachricht. Der Empfänger kann nachschlagen, ob das Siegel zu Ihrer Firma gehört und ob unterwegs jemand das Couvert geöffnet und den Inhalt verändert hat. Fehlt das Siegel oder ist es gebrochen, wird die Mail misstrauisch beäugt – nicht abgewiesen, aber schlechter bewertet.
Der Haken ist derselbe wie bei einem echten Siegel: Es sagt nichts darüber aus, was im Brief steht. Eine sauber signierte Nachricht kann trotzdem Unsinn enthalten. Und es sagt auch nichts über den Namen, der aussen auf dem Couvert steht – die Verbindung zwischen Siegel und sichtbarem Absender stellt erst der nächste Baustein her.
Warum das Siegel bricht, sobald jemand die Nachricht anfasst
DKIM
DKIM steht für «DomainKeys Identified Mail» – ein Verfahren, das jede ausgehende E-Mail mit einer digitalen Signatur versieht, aus der ein Empfänger zwei Dinge ablesen kann: dass die Nachricht von Ihrer Domain stammt und dass sie unterwegs nicht verändert wurde. Was DKIM nicht prüft: den Inhalt der Nachricht und die Absenderadresse, die Sie im Postfach sehen.
Selector
Ein Name, der einen bestimmten Schlüssel bezeichnet. Weil oft mehrere Dienste in Ihrem Namen Mails verschicken – der eigene Mailserver, das Newsletter-Tool, die Buchhaltungssoftware –, bekommt jeder von ihnen einen eigenen Schlüssel unter einem eigenen Selector. So stören sie sich nicht gegenseitig, und Sie können einen einzelnen Dienst abschalten, ohne die anderen zu beeinträchtigen.
Öffentlicher Schlüssel
Die Hälfte des Schlüsselpaares, die jeder abrufen darf. Sie liegt öffentlich in Ihrer Domain-Verwaltung und dient Empfängern dazu, die Signatur zu überprüfen. Die andere Hälfte, der private Schlüssel, verlässt Ihren Mailserver nie – nur er kann Signaturen erzeugen. Deshalb ist es unbedenklich, dass der öffentliche Teil für alle sichtbar ist.
Warum DKIM mehr Aufmerksamkeit braucht als SPF
Wenn ich mir das Mail-Setup eines Betriebs ansehe, ist SPF fast immer schon da – das älteste und bekannteste der drei Verfahren, das praktisch jeder Hoster beim Einrichten anlegt. Ob der Eintrag noch zum heutigen Versand passt, ist eine andere Frage; vorhanden ist er. DKIM ist jünger und weniger vertraut, und wo es läuft, läuft es oft mit den Standardwerten des Providers: ein Selector für den Hausserver, während die halbe Firma über Systeme versendet, die nie signiert haben. Meine Aufmerksamkeit liegt deshalb zuerst dort – nicht weil SPF unwichtig wäre, sondern weil SPF meist schon jemand angefasst hat und DKIM meist niemand.
Dazu kommt, dass die Signatur das einzige der drei Verfahren ist, das eine Weiterleitung übersteht: Leitet Ihr Kunde die Rechnungsmail an seinen Buchhalter weiter, sendet dessen Server – und SPF, das nur den sendenden Server prüft, schlägt fehl. Die Signatur reist mit der Nachricht mit und hält.
Der teuerste Fehler ist ohnehin kein fehlender Eintrag, sondern ein unvollständiges Inventar. Fast jeder Betrieb hat ein System, das im Firmennamen versendet, ohne je auf einer Liste gestanden zu haben – Buchhaltung, Ticketsystem, Kontaktformular der Website. Solange die nicht signieren, ist jede Verschärfung eine Wette darauf, dass sie niemandem auffallen. Und sie fliegen genau dann auf, wenn eine Rechnung nicht ankommt.
Die ehrliche Grenze: DKIM macht Ihre Mails nicht vertrauenswürdig, nur nachprüfbar. Wer Ihren Firmennamen fälschen will, kann eine fremde Domain sauber signieren und trotzdem Ihren Namen ins sichtbare Absenderfeld schreiben. Diese Lücke schliesst erst DMARC, das Signatur und sichtbaren Absender miteinander verknüpft.
Häufige Fragen
Ersetzt DKIM den SPF-Eintrag?
Nein, beide prüfen unterschiedliche Dinge und ergänzen sich. SPF autorisiert Server, DKIM signiert Inhalte. Erst DMARC verknüpft beide Ergebnisse mit der sichtbaren Absenderdomain.
Muss ich für jeden Versanddienst einen eigenen Selector einrichten?
Ja, sobald ein Dienst in Ihrem Namen signieren soll. Der Anbieter liefert dafür üblicherweise den öffentlichen Schlüssel und den gewünschten Selector-Namen, den Sie als DNS-TXT-Eintrag hinterlegen.
Was passiert, wenn eine DKIM-Prüfung fehlschlägt?
Die Mail wird nicht automatisch abgelehnt – ohne DMARC-Policy entscheidet allein der Empfänger, wie streng er reagiert. Häufig landet sie im Spam-Ordner oder wird niedriger bewertet, statt hart abgewiesen zu werden.
Warum scheitert DKIM ausgerechnet bei Mailinglisten?
Weil viele Listen die Nachricht verändern, bevor sie sie weiterschicken – ein Präfix im Betreff, eine Abmelde-Fusszeile im Text. Die Signatur bezieht sich auf den ursprünglichen Inhalt und passt danach nicht mehr. Das ist kein Fehler in Ihrem Setup, sondern eine bekannte Eigenschaft des Verfahrens.
Muss ich den DKIM-Schlüssel irgendwann erneuern?
Ein Rotieren des Schlüsselpaares in grösseren Abständen (z. B. jährlich) gilt als gute Praxis, ist aber weniger dringlich als bei SPF, verwaiste Einträge zu entfernen. Wichtig ist die Reihenfolge: erst den neuen Selector im DNS anlegen, dann den Versand umstellen, den alten Eintrag erst nach einigen Tagen löschen – sonst scheitern Mails, die noch mit der alten Signatur unterwegs sind.
