DKIM verstehen — was tun Signaturen, was nicht

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. Euer Mailserver drückt es beim Versand auf jede Nachricht. Der Empfänger kann nachschlagen, ob das Siegel zu eurer 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 eurer Domain stammt und dass sie unterwegs nicht verändert wurde. Was DKIM nicht prüft: den Inhalt der Nachricht und die Absenderadresse, die ihr im Postfach seht.

Selector

Ein Name, der einen bestimmten Schlüssel bezeichnet. Weil oft mehrere Dienste in eurem 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 ihr könnt 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 eurer Domain-Verwaltung und dient Empfängern dazu, die Signatur zu überprüfen. Die andere Hälfte, der private Schlüssel, verlässt euren 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 euer 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 eure Mails nicht vertrauenswürdig, nur nachprüfbar. Wer euren Firmennamen fälschen will, kann eine fremde Domain sauber signieren und trotzdem euren Namen ins sichtbare Absenderfeld schreiben. Diese Lücke schliesst erst DMARC, das Signatur und sichtbaren Absender miteinander verknüpft.

DKIM signiert jede ausgehende E-Mail digital mit einem privaten Schlüssel, den nur euer Mailserver kennt. Der passende öffentliche Schlüssel liegt im DNS eurer Domain – damit kann jeder Empfänger prüfen, ob eine Nachricht tatsächlich unverändert von euch 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.euredomain.ch als TXT-Eintrag, etwa v=DKIM1; k=rsa; p=MIGfMA0.... Der Selector-Name (s=) macht es möglich, dass euer 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 eurem Namen E-Mails verschicken, müssen für DKIM einen eigenen Schlüssel und Selector bei euch 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 eurem 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 — fünf 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
Sicherheitsfilter beim Empfänger, der die Mail nach dem Eingang verändert und zurückgibt	fail – der Filter liefert mit eigener IP neu ein	fail – der signierte Inhalt wurde verändert

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.

Die letzte Zeile sieht in den DMARC-Berichten aus wie ein Fehler bei euch, liegt aber beim Empfänger: Dieselbe Mail erscheint dort zweimal, einmal bestanden beim Eingang, einmal fehlgeschlagen nach dem Filter. Ob sie trotzdem zugestellt wird, hängt davon ab, ob der Empfänger seinen Filter als vertrauenswürdige Station für ARC eingetragen hat. Die IP-Adresse des Filters gehört nie in euren SPF-Record.

Wie ihr eure DKIM-Signatur selbst prüft und einen Selector einrichtet

DKIM lässt sich ohne Spezialwerkzeug verifizieren – die Beweismittel stehen in jeder Mail, die ihr euch selbst schickt:

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-Results suchen. Dort steht dkim=pass oder dkim=fail, dazu die signierende Domain (header.d=) und der verwendete Selector.
Den öffentlichen Schlüssel gegenprüfen: dig TXT selector._domainkey.euredomain.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 eure Kunden eurefirma.ch sehen, besteht DKIM zwar – für DMARC ist es aber wertlos, weil das Alignment fehlt. Erst ein Selector unter eurer Domain löst das.
Alte Selectoren aufräumen. Jeder DNS-Eintrag unter _domainkey, dessen Dienst ihr nicht mehr nutzt, gehört gelöscht.

Drei Fallstricke, an denen es in der Praxis scheitert:

Einträge gesetzt, Signierung nie eingeschaltet. Bei Microsoft 365 sind die DNS-Einträge und das Einschalten der Signierung zwei getrennte Schritte: erst die Einträge im DNS, dann der Schalter im Microsoft Defender Portal. Stehen nur die Einträge, liefert dig einen gültigen Schlüssel – signiert wird trotzdem nur mit der Hilfsdomain …onmicrosoft.com, und die zählt für DMARC nicht. Erkennbar ist das nur beim Empfänger (header.d=) oder in den DMARC-Berichten. Der Header einer Mail im eigenen Gesendet-Ordner taugt nicht als Beleg: Die Zeile ARC-Authentication-Results: … dkim=pass ist dort eine interne Bewertung von Microsoft. Massgeblich ist, ob die Mail einen Header DKIM-Signature mit d= eurer Domain trägt.
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 dig gegenlesen, 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.

Häufige Fragen

Wie sehe ich, ob unsere Mails überhaupt signiert sind?

In jeder Mail, die ihr euch selbst an ein externes Postfach schickt. In Gmail öffnet ihr dazu «Original anzeigen» und sucht die Zeile mit «DKIM»: Steht dort «PASS» und dahinter eure eigene Domain, signiert dieser Versandweg korrekt. Steht dort eine fremde Domain, etwa die eures Newsletter-Anbieters, ist die Signatur zwar gültig, hilft euch aber wenig. Macht den Test für jeden Weg einzeln – Hausserver, Newsletter, Buchhaltung, Kontaktformular.

Was frage ich meinen Newsletter- oder Buchhaltungsanbieter?

Fragt: «Signiert ihr unsere Mails mit DKIM unter unserer eigenen Domain, und welchen DNS-Eintrag müssen wir dafür setzen?» DKIM steht für DomainKeys Identified Mail, die digitale Signatur jeder Mail. Seriöse Anbieter liefern darauf einen konkreten Eintrag mit einem Selector-Namen, also dem Namen für ihren Schlüssel, den eure IT oder euer Domain-Verwalter hinterlegt. Fehlt diese Antwort, versendet der Dienst wahrscheinlich unsigniert oder unter seinem eigenen Namen.

Ersetzt DKIM den SPF-Eintrag?

Nein, beide prüfen unterschiedliche Dinge und ergänzen sich. SPF – das Sender Policy Framework – prüft, ob der sendende Server auf eurer Liste steht; DKIM prüft, ob die Nachricht unverändert von euch stammt. Erst DMARC (Domain-based Message Authentication, Reporting and Conformance) verknüpft beide Ergebnisse mit dem Absender, den euer Kunde sieht. Alle drei verlangen Google und Microsoft verbindlich von Versendern mit mehr als 5’000 Mails pro Tag; für alle anderen verlangt Google SPF oder DKIM, empfohlen sind auch dort alle drei.

Was passiert, wenn wir DKIM einfach weglassen?

Eure Mails werden nicht sofort abgewiesen, aber schlechter bewertet und landen eher im Spam-Ordner. Besonders betroffen sind Mails, die ein Kunde weiterleitet – etwa eine Rechnung an seinen Buchhalter: Dort scheitert SPF zwangsläufig, und nur die Signatur reist mit. Fehlt sie, steht die Mail ohne gültigen Nachweis da.

Ist das einmal eingerichtet, oder muss sich jemand darum kümmern?

Es braucht wenig, aber regelmässig Pflege. Jeder neue Dienst, der in eurem Namen versendet, braucht einen eigenen Eintrag, und Einträge von Diensten, die ihr nicht mehr nutzt, gehören gelöscht. Den Schlüssel in grösseren Abständen zu erneuern gilt als gute Praxis – dann in der richtigen Reihenfolge: neuen Eintrag anlegen, Versand umstellen, den alten erst nach einigen Tagen entfernen. Legt fest, wer bei euch für diese Liste zuständig ist.

Quellen

DKIM-Standard: Crocker, D.; Hansen, T.; Kucherawy, M. (Hrsg.) (2011). «RFC 6376: DomainKeys Identified Mail (DKIM) Signatures». — Die Spezifikation von DKIM: Signatur, Selector und Ablage des öffentlichen Schlüssels im DNS.
Schlüssellänge: Kitterman, S. (2018). «RFC 8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)». — Aktualisiert RFC 6376: Signierer sollen RSA-Schlüssel mit mindestens 2048 Bit verwenden, rsa-sha1 ist nicht mehr zulässig.