DKIM einrichten: erst den Signierer finden, dann DNS und Nachricht prüfen

Was Sie vor der Einrichtung klären sollten

Die Domainregistrierung, der DNS-Betrieb und der E-Mail-Versand können bei drei unterschiedlichen Anbietern liegen. Auch der empfangende MX verrät nicht zuverlässig, welcher Dienst Ihre ausgehenden Nachrichten signiert. Ein Newsletterdienst oder eine Website kann neben Ihrem Postfachanbieter einen eigenen Versandweg verwenden.

Halten Sie für jeden tatsächlich genutzten Weg fest:

Für eine eigene Google-Workspace-Domain verwenden Sie die Google-Anleitung; für Exchange Online die Microsoft-365-Anleitung. Ein privates Gmail- oder Outlook.com-Konto ist kein entsprechender Domainverwaltungszugang.

Den richtigen Selektor ermitteln

Suchen Sie zuerst in der DKIM-Konfiguration des zuständigen Versanddienstes. Liegt bereits eine darüber versandte Nachricht vor, finden Sie den Selektor in s= und die Signierdomain in d= des zugehörigen DKIM-Signature-Headers. Bei mehreren Signaturen betrachten Sie jede Kombination getrennt. Das Vorhandensein des Headers beweist noch keine gültige Signatur.

Das folgende verkürzte Beispiel ist synthetisch, keine echte oder prüfbare Signatur:

d=example.com; s=mail202609
mail202609._domainkey.example.com

default, google und selector1 sind mögliche Namen, keine vollständige Liste. Ein frei gewählter Selektor funktioniert nur, wenn auch der Signierer genau diesen Namen verwendet. Finden Sie bei bekannten Selektoren keinen Schlüssel, können andere Selektoren existieren. Es gibt keine allgemeine DNS-Abfrage, die sämtliche DKIM-Selektoren einer Domain auflistet.

1. Schlüssel beim zuständigen Signierer vorbereiten

Bei einem verwalteten Versanddienst lassen Sie den Dienst die Schlüssel erzeugen. Übernehmen Sie seine veröffentlichten DNS-Werte. Der private Schlüssel bleibt beim Dienst und gehört weder ins DNS noch in einen Prüfbericht. Manche Dienste liefern einen TXT-Wert; andere geben CNAME-Ziele vor, hinter denen sie den öffentlichen Schlüssel verwalten.

Für einen selbst betriebenen Signierer gelten dessen dokumentiertes Schlüsselformat und Berechtigungen. Für neue RSA-Schlüssel sind mindestens 2048 Bit die Empfehlung aus RFC 8301, Abschnitt 3.2. Das vorgeschriebene Minimum beträgt 1024 Bit; 1024 Bit allein beweisen daher keine ungültige Signatur. rsa-sha1 darf nicht mehr zum Signieren oder Prüfen verwendet werden. Ed25519 ist ein eigener DKIM-Algorithmus, aber keine automatisch verfügbare Option jedes Anbieters.

Das folgende Beispiel zeigt ausschließlich lokale RSA-Schlüsselerzeugung in einem neuen geschützten Arbeitsverzeichnis. Die Befehle wurden für die isolierte Signaturprobe mit OpenSSL 3.6.3 ausgeführt. Vorhandene Dateien dürfen nicht überschrieben werden; die erzeugte private Datei ist ohne Passphrase und muss geschützt bleiben. Die Übernahme in den konkreten Maildienst ist ein weiterer Schritt.

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out dkim-private.pem
openssl pkey -in dkim-private.pem -pubout -out dkim-public.pem

Die zweite Datei enthält nur den öffentlichen Schlüssel im PEM-Format. Verwenden Sie für den DNS-Eintrag den vom DKIM-Signierer vorgesehenen Export. Entfernte PEM-Begrenzungszeilen allein sind keine vollständige Format- oder Einrichtungsprüfung. Laden Sie den privaten Schlüssel nicht in einen Onlinegenerator oder Checker hoch. OpenSSL: genpkey, pkey.

2. Den vorgesehenen DNS-Record veröffentlichen

Ermitteln Sie die tatsächlich zuständige DNS-Verwaltung. dig NS example.com kann Hinweise auf die Nameserver geben; bei delegierten Unterzonen reicht die Betrachtung der Hauptdomain nicht aus. Der Registrar ist nur dann die richtige Eingabestelle, wenn er auch diese DNS-Zone verwaltet.

Bei einem direkten TXT-Record steht der öffentliche Schlüssel unter dem Namen aus Selektor, _domainkey und Signierdomain. Dieses schematische Beispiel ist kein einsetzbarer Schlüssel:

mail202609._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_BASE64"

Ein langer TXT-Record darf aus mehreren Zeichenketten innerhalb eines Records bestehen. Die Grenze von 255 Oktetten gilt je Zeichenkette, nicht für den gesamten DKIM-Schlüssel. Die Zeichenketten werden ohne zusätzliches Leerzeichen verbunden. Mehrere getrennte DKIM-TXT-Records am selben Selektornamen sind kein Ersatz dafür. Prüfen Sie, wie Ihre DNS-Oberfläche lange Werte entgegennimmt. RFC 6376, Abschnitt 3.6.2.

Gibt der Dienst CNAMEs vor, übernehmen Sie diese statt eines selbst zusammengesetzten TXT-Records. Prüfen Sie Recordtyp, vollständigen Namen und Ziel. Eine Oberfläche kann die Zone automatisch an den eingegebenen Namen anhängen. Ein bereits vorhandener Record desselben Namens darf nicht unbesehen verdrängt werden; klären Sie vorher, welcher Versandweg ihn verwendet.

3. Die Signierung aktivieren

Bei einem verwalteten Dienst folgen nach der DNS-Veröffentlichung dessen Aktivierungs- und Statusprüfung. „Record gespeichert“ in der DNS-Verwaltung und „Signierung aktiv“ beim Versanddienst sind verschiedene Zustände.

Bei eigener Serververwaltung müssen privater Schlüssel, Signierdomain und Selektor in der zuständigen DKIM-Komponente zusammenpassen. Beschränken Sie den Schlüsselzugriff auf den benötigten Dienst. Prüfen Sie die Konfiguration mit den Werkzeugen dieser Implementierung und laden Sie sie nach deren Verfahren. Ein pauschaler Neustart aller Maildienste gehört nicht zur DKIM-Einrichtung.

relaxed/relaxed bezeichnet bestimmte Regeln für Header- und Körperkanonisierung. Sie können manche Leerraumänderungen tolerieren, aber keine beliebigen Inhaltsänderungen. Übernehmen Sie die dokumentierte Einstellung Ihres Signierers; eine Umstellung repariert keine bereits beschädigte Signatur.

4. DNS und eine tatsächlich versandte Nachricht getrennt prüfen

Fragen Sie den Namen ab, der zur tatsächlichen Signierkonfiguration gehört. Die Beispiele verwenden ausschließlich die synthetische Domain und den synthetischen Selektor von oben:

dig TXT mail202609._domainkey.example.com +short
dig CNAME mail202609._domainkey.example.com +short

Ein CNAME führt zum vom Dienst verwalteten Schlüsselziel. Lesen Sie die vollständige Antwort, wenn die Kurzform leer oder unklar bleibt: etwa mit dig TXT mail202609._domainkey.example.com ohne +short. Eine leere Kurzantwort unterscheidet weder einen fehlenden Namen noch alle DNS-Fehler zuverlässig. Cachezustand, Resolver und Abfragezeitpunkt gehören zur Beobachtung. Diese Befehle senden keine Testmail.

Für den Signaturnachweis benötigen Sie eine eigene, über den untersuchten Versandweg gesendete und extern empfangene Nachricht. Lesen Sie deren Originalheader: Welche Signatur enthält das erwartete d= und s=? Welches Ergebnis meldet der vertrauenswürdige empfangende Dienst in Authentication-Results für diese Signatur? Ein frei eingefügter Header ist kein vertrauenswürdiger Prüfbefund. Die Einordnung von Headerbefunden hilft bei der Zuordnung.

Der E-Mail-Security-Check untersucht öffentlich auffindbare DKIM-Schlüssel unter begrenzt bekannten oder angegebenen Selektoren. Geben Sie den tatsächlichen Selektor an, soweit das Formular dies vorsieht. Ein fehlender Fund beweist nicht, dass DKIM fehlt. Der Domaincheck liest keine Nachricht und überwacht spätere Änderungen nicht automatisch.

Für eine neue eigene Nachricht steht die kostenlose deutsche Testmail-Beta im begrenzten Startprofil über den E-Mailcheck zur Verfügung. Beachten Sie die dortigen Voraussetzungen. Ihr privater Nachrichtenbefund bleibt vom öffentlichen Domainbefund getrennt; er ersetzt dessen Note nicht. Ein vollständiger englischer Funktionsweg ist derzeit nicht freigegeben. Wenn Sie den Stand für eine Übergabe dokumentieren müssen, erklärt die Reportübersicht, welche begrenzten Befunde die jeweilige Unterlage enthält. Ein Report ist kein Audit-, Compliance- oder Sicherheitszertifikat.

Mehrere Versanddienste und Schlüsselwechsel

Verwenden mehrere Dienste dieselbe From-Domain, braucht jeder tatsächlich signierende Weg eine passende Konfiguration. Ein für Google Workspace bereitgestellter Schlüssel richtet einen separaten Newsletterdienst nicht ein. Halten Sie je Dienst Signierdomain, Selektor, Recordtyp und Verantwortlichkeit fest; vermeiden Sie Namenskollisionen.

Bei einem geplanten Wechsel veröffentlichen Sie den neuen öffentlichen Schlüssel unter dem vorgesehenen neuen Selektor, prüfen seine Erreichbarkeit und schalten erst nach dem Verfahren des Dienstes den Signierer um. Prüfen Sie anschließend eine neue Nachricht auf den tatsächlich verwendeten Selektor und den Empfängerbefund. Alte DNS-Schlüssel können für noch unterwegs befindliche oder später erneut geprüfte Nachrichten relevant bleiben. Entfernen Sie sie nicht allein, weil die neue Konfiguration gespeichert wurde.

Eine allgemeine Wartefrist passt nicht zu allen Caches, Warteschlangen und Anbietern. Auch ein Notfall wegen eines kompromittierten privaten Schlüssels verlangt eine andere Abwägung als ein geplanter Wechsel. Die ausführliche Erklärung steht im DKIM-Kapitel; die konkrete Anbieterrotation bleibt an deren dokumentierten Ablauf gebunden.

Was die isolierte Signaturprobe zeigt

Am 29. September 2026 wurden mit OpenSSL 3.6.3 frische RSA-Schlüssel mit 2048 Bit erzeugt. dkimpy 1.1.8 signierte eine synthetische Nachricht mit rsa-sha256, d=example.com und s=mail202609. Der Verifizierer erhielt den öffentlichen Schlüssel ausschließlich aus lokalen DNS-Fixtures. Deren Wire-Format und CNAME-Kette wurden mit dnspython 2.7.0 verarbeitet. Es gab keinen Versand und keine öffentliche DNS-Abfrage.

Die elf kontrollierten Fälle prüfen Signaturverhalten und DNS-Darstellung. Sie sind keine eigenen Authentication-Results eines empfangenden Internet-Maildienstes und kein Zustell-, Google- oder Microsoft-Nachweis. Die privaten Testschlüssel wurden nach der Probe entfernt. Ihre eigene Abnahme bleibt die in Schritt 4 beschriebene Nachricht auf dem vorgesehenen Versandweg.

Wenn die Nachweise nicht zusammenpassen

Fehlendes DKIM bedeutet nicht automatisch DMARC-Fail: Ein erfolgreicher ausgerichteter SPF-Pfad kann das allgemeine Pass-Kriterium erfüllen. Umgekehrt garantiert eine veröffentlichte p=reject-Policy keine bestimmte Empfängerentscheidung. DMARC und Alignment erklären diese Grenzen.

Passende weitere Anleitungen

Weitere DKIM-Anleitung: Google Workspace · Microsoft 365

Zur Einordnung: SPF, DKIM-Grundlagen und DMARC. Für das Zusammenspiel mit der sichtbaren Absenderdomain: DMARC-Alignment verstehen.