Begriff · DKIM prüfen

Wie prüfen Sie DKIM für E-Mails aus Ihrer Anwendung?

Eine zuverlässige DKIM-Prüfung arbeitet mit einer echten, zugestellten Nachricht. Lesen Sie den Header DKIM-Signature, entnehmen Sie die signierende Domain (`d=`) und den Selektor (`s=`), fragen Sie den zugehörigen DNS-Schlüssel unter `<selector>._domainkey.<domain>` ab und verifizieren Sie die signierten Header und den Body kryptografisch. Prüfen Sie anschließend die Authentication-Results eines vertrauenswürdigen Empfängers. Behandeln Sie Verfügbarkeit des Eintrags, Signaturprüfung, DMARC-Alignment, Annahme durch den empfangenden Server und Platzierung im Posteingang als getrennte Ergebnisse.

Eine DKIM-Prüfung als vier getrennte Tests behandeln

Eine DNS-Abfrage allein ist keine vollständige DKIM-Prüfung. Stellen Sie erstens fest, dass die Nachricht ein Feld DKIM-Signature enthält, und bestimmen Sie die Signatur, die Sie testen wollen. Rufen Sie zweitens den Public-Key-Eintrag ab, auf den diese Signatur verweist, und parsen Sie ihn. Prüfen Sie drittens, ob die signierten Header und der kanonisierte Body noch zur kryptografischen Signatur passen. Entscheiden Sie viertens, ob eine erfolgreich geprüfte signierende Domain für DMARC mit der sichtbaren From-Domain übereinstimmt (Alignment). Diese Ebenen beantworten unterschiedliche Fragen. Ein veröffentlichter Eintrag kann ungenutzt sein, eine Nachricht kann auf einen fehlenden Selektor verweisen, eine Signatur kann nach einer Inhaltsänderung fehlschlagen, und eine kryptografisch gültige Signatur kann trotzdem ohne Alignment zur Autorendomain bleiben. Dokumentieren Sie jedes Ergebnis einzeln, statt ein einziges grünes Häkchen anzuzeigen. Trennen Sie außerdem Transport- und Postfachzustände: Annahme durch den Provider, Annahme durch den empfangenden Server und Platzierung im Posteingang sind keine Ergebnisse der DKIM-Verifizierung.

Bei der Signatur einer echten Nachricht beginnen

Beschaffen Sie die Rohnachricht von einem kontrollierten Empfänger, der über den normalen Anwendungspfad erreicht wurde. Notieren Sie in jedem Feld DKIM-Signature die signierende Domain `d=`, den Selektor `s=`, den Algorithmus `a=`, die Kanonisierungsmodi `c=`, die Liste signierter Header `h=`, den Body-Hash `bh=`, die Signaturdaten `b=` und, falls vorhanden, die Zeitstempel. RFC 6376 definiert die Tags für signierende Domain und Selektor und nutzt sie, um den öffentlichen Schlüssel zu finden. Raten Sie den Selektor nicht anhand eines Provider-Dashboards und fragen Sie `_domainkey` nicht ohne ihn ab. Eine Nachricht kann mehrere Signaturen von Absender, Zwischenstation oder Mailinglisten-System tragen, halten Sie daher das Ergebnis für jede Signatur fest. Fügen Sie Nachrichten aus dem Produktivbetrieb nicht in öffentliche Checker ein: Rohe Header und Bodys können Empfänger, Message-IDs, Routing-Details, Abmelde-Tokens und Anwendungsinhalte preisgeben. Nutzen Sie zugriffsbeschränkten Speicher und eine geschwärzte Diagnosekopie, wenn der vollständige Inhalt nicht nötig ist.

Genau den Selektor und die signierende Domain abfragen

Bilden Sie den DNS-Namen aus der Signatur als `<selector>._domainkey.<signing-domain>`. Enthält der Header `s=app2026` und `d=notify.example.test`, fragen Sie TXT unter `app2026._domainkey.notify.example.test` ab. Notieren Sie den ursprünglichen Namen, den Resolver, die Antwort, die TTL und eine etwaige CNAME-Kette. Parsen Sie den zurückgegebenen Tag-Wert-Eintrag, statt nach einem Textfragment zu suchen. Der Eintrag kann Version, Schlüsseltyp, Dienstbeschränkung, Flags, Hash-Algorithmen und die Public-Key-Daten angeben. Ein leerer Public-Key-Wert widerruft den Schlüssel. Unterscheiden Sie NXDOMAIN, eine leere Antwort, fehlerhaften Inhalt, einen nicht unterstützten Algorithmus, einen unbrauchbaren Schlüssel und einen vorübergehenden Resolver-Fehler. Wiederholen Sie eine geänderte Abfrage nach Ablauf der TTL über einen unabhängigen Resolver, gehen Sie aber nicht davon aus, dass alle Empfänger sofort aktualisiert haben. Ein DNS-Erfolg belegt nur, dass in diesem Moment ein Eintrag zurückgegeben wurde. Er belegt weder, dass die getestete Nachricht verifiziert wird, noch dass der Provider aktuellen Traffic mit diesem Selektor signiert.

Header, Body-Hash und Signatur verifizieren

Die DKIM-Verifizierung folgt den Kanonisierungsregeln, die in der Signatur angegeben sind. Der Verifizierer kanonisiert den Body, berechnet dessen Hash und vergleicht ihn mit `bh=`. Außerdem kanonisiert er die in `h=` genannten signierten Header, bezieht das Feld DKIM-Signature wie vorgeschrieben ein und verifiziert `b=` mit dem öffentlichen Schlüssel. Verwenden Sie eine gepflegte Verifizierungsbibliothek oder das vertrauenswürdige Authentifizierungsergebnis eines Empfängers, statt diese Transformationen mit String-Operationen nachzubauen. Ein abweichender Body-Hash bedeutet oft, dass der Body nach dem Signieren verändert wurde. Ein Fehler bei der Header-Signatur kann auf veränderte signierte Header, einen falschen Schlüssel, beschädigte Signaturdaten oder einen Implementierungsfehler hinweisen. Halten Sie fest, in welcher Phase der Fehler auftrat. Prüfen Sie, ob wichtige Felder wie From, Subject, Date und Message-ID signiert wurden, erfinden Sie aber keine allgemeingültige Regel für signierte Header. Die Kanonisierung toleriert definierte Formatierungsänderungen; sie macht beliebig eingefügte Footer, MIME-Umschreibungen, beschädigte Zeilenenden oder Änderungen beim Transport nicht unbedenklich.

Ergebnisse des Empfängers innerhalb seiner Vertrauensgrenze lesen

RFC 8601 definiert den Header Authentication-Results und DKIM-Ergebnisse wie none, pass, fail, policy, neutral, temperror und permerror. Ein pass bedeutet, dass der Empfänger eine akzeptable Signatur gefunden hat, die die Verifizierungstests bestanden hat. Ein temperror kann auf einen Zustand hinweisen, der sich voraussichtlich ändert, etwa einen vorübergehenden Fehler bei der Schlüsselabfrage; ein permerror wird ohne Korrektur voraussichtlich auch bei einem späteren Versuch nicht erfolgreich sein. Notieren Sie, soweit angegeben, den meldenden Authentifizierungsdienst, die signierende Domain, den Selektor und den Algorithmus. Vertrauen Sie nur Ergebnissen, die innerhalb der dokumentierten Grenze des empfangenden Systems eingefügt wurden, denn ein Absender kann vor dem Versand ein gefälschtes Feld Authentication-Results hinzufügen. Werten Sie das oberste vertrauenswürdige Ergebnis der letzten empfangenden Umgebung aus und berücksichtigen Sie zwischengeschaltete Hops. Wenn verschiedene Empfänger zu unterschiedlichen Ergebnissen kommen, vergleichen Sie die genaue Nachrichtenversion, die DNS-Sicht, den Prüfzeitpunkt, die unterstützten Algorithmen und die lokale Richtlinie. Leiten Sie aus `dkim=pass` nicht ab, dass der Postfachanbieter den Inhalt gutheißt oder in den Posteingang einsortiert hat.

DMARC-Alignment getrennt vom DKIM-Pass prüfen

Ein DKIM-Pass authentifiziert die signierende Domain in `d=`; er setzt nicht voraus, dass diese Domain der sichtbaren From-Domain nach RFC 5322 entspricht. RFC 9989 verwendet eine erfolgreich per DKIM authentifizierte Kennung für DMARC nur dann, wenn sie im jeweils geltenden strikten oder entspannten Alignment-Modus mit der Autorendomain übereinstimmt. So kann eine Nachricht von `billing.example.test`, die mit `d=provider.test` signiert ist, DKIM bestehen und trotzdem ohne Alignment bleiben. Eine gültige Signatur von `d=example.test` kann im entspannten Modus aligned sein – abhängig von der Berechnung der Organisationsdomain und der Richtlinie. Melden Sie drei Felder: DKIM-Ergebnis, signierende Domain und Alignment-Entscheidung. Eine Nachricht kann DMARC auch über aligned SPF bestehen, wenn DKIM fehlschlägt oder nicht aligned ist; ein DMARC-Pass belegt also nicht, dass genau diese DKIM-Signatur erfolgreich war. Die aktuellen Gmail-Richtlinien für Absender enthalten Anforderungen an Authentifizierung und Alignment für den betreffenden Traffic. Auch wer sie erfüllt, hat aber keine Garantie für die Annahme durch den empfangenden Server oder die Platzierung im Postfach.

Aktuelle Algorithmen und Schlüsselrotation prüfen

RFC 8301 aktualisiert die kryptografischen Anforderungen an DKIM: Signierer müssen `rsa-sha256` verwenden, Verifizierer müssen es unterstützen, und `rsa-sha1` darf nicht verwendet werden. Außerdem verlangt RFC 8301 RSA-Signaturschlüssel mit mindestens 1024 Bit und erläutert, warum größere Schlüssel vorzuziehen sind, wenn der Betrieb es zulässt. Ein Checker sollte den Algorithmus erkennen und veraltetes oder unbrauchbares Material markieren, ohne zu behaupten, dass die Schlüssellänge allein einen E-Mail-Stream vertrauenswürdig macht. Die Workflows der Provider unterscheiden sich. Amazon SES dokumentiert für Easy DKIM standardmäßig 2048-Bit-Schlüssel und warnt, dass ein Wechsel der Signaturmethode ohne Zwischenschritt eine Phase verursachen kann, in der Nachrichten nicht per DKIM signiert werden. Planen Sie die Rotation mit zwei gültigen Selektoren oder dem dokumentierten Übergangsmechanismus des Providers, bestätigen Sie, dass neue Nachrichten den neuen Selektor verwenden, behalten Sie den alten öffentlichen Schlüssel, solange verzögerte E-Mails noch eintreffen können, und entfernen Sie ihn erst nach der Übergangsphase. Veröffentlichen Sie den privaten Signaturschlüssel niemals in DNS, Logs, Tickets oder Prompts.

Fehler von der Nachricht ausgehend diagnostizieren

Wenn eine Prüfung fehlschlägt, sichern Sie die Rohnachricht und das Ergebnis des Empfängers, bevor Sie DNS ändern. Stellen Sie sicher, dass die Nachricht tatsächlich von der erwarteten Anwendung und dem erwarteten Provider erzeugt wurde. Fehlt die Signatur, prüfen Sie, ob das Signieren für diese Identität, Region, diesen Tenant oder diese Nachrichtenklasse aktiviert war. Schlägt die Selektor-Abfrage fehl, vergleichen Sie die genauen Werte von `d=` und `s=`, die DNS-Zone, das CNAME-Ziel, die TTL und eine kürzlich erfolgte Rotation. Lässt sich der Schlüssel parsen, aber der Body-Hash schlägt fehl, prüfen Sie Gateways, Listen-Footer, Tracking-Umschreibungen, MIME-Transformationen, Zeilenenden und Sicherheitsprodukte, die Inhalte nach dem Signieren verändern können. Schlägt die kryptografische Signatur bei passendem Body-Hash fehl, untersuchen Sie Änderungen an signierten Headern, abweichende Schlüssel und die Implementierung des Signierens. Besteht DKIM, aber DMARC schlägt fehl, testen Sie das Alignment, statt denselben Schlüssel erneut zu veröffentlichen. Testen Sie nach Ablauf der relevanten TTL oder der Propagierung der Konfiguration erneut über kontrollierte Empfänger und dokumentieren Sie Nachweise für jede Nachrichtenklasse, statt die gesamte Domain nach einer einzigen erfolgreichen Stichprobe für repariert zu erklären.

Ein nachvollziehbares Protokoll der DKIM-Prüfung führen

Bewahren Sie für jede kontrollierte Nachricht eine nicht sensible Korrelations-ID, das sendende System, das Provider-Konto oder den Workspace, die sichtbare From-Domain, das empfangende System, den Zeitpunkt der Nachricht und das vollständige Ergebnis jeder Signatur auf. Erfassen Sie `d=`, `s=`, `a=`, Kanonisierung, signierte Header, den Namen der DNS-Abfrage, Zeitpunkt und TTL der DNS-Antwort, den Status des Schlüsseleintrags, das Ergebnis des Body-Hash, das Signaturergebnis, den vertrauenswürdigen Wert von Authentication-Results, die DMARC-Alignment-Entscheidung und die für die Behebung verantwortliche Person. Speichern Sie Rohnachrichten nur dort, wo Zugriff und Aufbewahrung angemessen kontrolliert sind. Ergänzen Sie das Testszenario: normaler Versand aus der Anwendung, Provider-Migration, Schlüsselrotation, Gateway-Pfad oder Weiterleitung. So lassen sich Regressionen vergleichen, und ein Screenshot wird nicht zum dauerhaften Beweis, nachdem sich Selektoren oder die Nachrichtenverarbeitung geändert haben. Prüfen Sie erneut nach Änderungen an der Provider-Einrichtung, an DNS, an der Signaturmethode, am Routing oder bei einer neuen Nachrichtenklasse. Ein Betriebs-Dashboard sollte unbekannte und nicht verfügbare Zustände ausdrücklich anzeigen, statt sie stillschweigend als pass oder fail zu werten.

Wie SendHQ in die Prüfung passt

SendHQ verlangt eine verifizierte From-Domain und stellt Zustell-Events bereit. Senden Sie für eine DKIM-Prüfung eine kontrollierte Nachricht über den vorgesehenen Anwendungspfad, prüfen Sie die empfangene Signatur, fragen Sie die tatsächlichen Werte `d=` und `s=` ab und halten Sie das Alignment getrennt fest. Leiten Sie Selektor, Schlüssellänge, Signaturalgorithmus, Platzierung im Posteingang oder Zustellgarantie nicht allein aus der Produktdokumentation ab.

Häufig gestellte Fragen

Wo finde ich den DKIM-Selektor?

Öffnen Sie die Rohnachricht und suchen Sie das Feld DKIM-Signature. Der Selektor ist der Wert `s=`, die signierende Domain der Wert `d=`. Bilden Sie aus beiden `<selector>._domainkey.<signing-domain>` für die DNS-Abfrage.

Besteht DKIM, wenn ein DKIM-DNS-Eintrag gefunden wird?

Nein. Der Eintrag liefert nur Schlüsselmaterial und Richtlinien-Tags. Ein Verifizierer muss damit den kanonisierten Body, die signierten Header, den Body-Hash, die Signaturdaten und den Algorithmus genau dieser Nachricht prüfen. Testen Sie eine echte, zugestellte Nachricht.

Kann DKIM bestehen, während DMARC fehlschlägt?

Ja. DKIM kann mit einer signierenden Domain verifiziert werden, die nicht mit der sichtbaren From-Domain ausgerichtet ist. DMARC benötigt eine erfolgreiche, ausgerichtete SPF- oder DKIM-Kennung im jeweils geltenden Alignment-Modus. Melden Sie Verifizierung und Alignment daher getrennt.

Was verursacht einen abweichenden DKIM-Body-Hash?

Der kanonisierte Body, den der Verifizierer erhält, weicht von dem ab, was der Signierer gehasht hat. Typische Untersuchungsbereiche sind Gateways, Footer, Tracking-Umschreibungen, MIME-Konvertierung, Sicherheitswerkzeuge und Änderungen an Zeilenenden nach dem Signieren. Sichern Sie vor der Diagnose die exakte Nachricht.

Sollten alte DKIM-Selektoren nach der Rotation sofort gelöscht werden?

Nein. Halten Sie den alten öffentlichen Schlüssel während einer kontrollierten Übergangsphase verfügbar, damit verzögerte Nachrichten, die damit signiert wurden, weiterhin verifiziert werden können. Bestätigen Sie, dass neuer Traffic den neuen Selektor verwendet, und folgen Sie dem dokumentierten Rotationsprozess des Providers, bevor Sie alte DNS-Einträge entfernen.

Belegt ein DKIM-Pass die Platzierung im Posteingang?

Nein. Er bestätigt eine akzeptable Signatur der getesteten Nachricht beim prüfenden Empfänger. Empfänger berücksichtigen bei Annahme und Einordnung von E-Mails weiterhin Authentifizierungs-Alignment, Reputation, Inhalt, Beschwerden, Empfängersignale und lokale Richtlinien.

Quellen

Weiterlernen

DMARC prüfen: So testen Sie E-Mails aus Ihrer AnwendungPrüfen Sie Auffindbarkeit und Syntax des DMARC-Eintrags, SPF- und DKIM-Alignment, Richtlinie, Berichte und echte Anwendungsnachrichten – ohne eine DNS-Abfrage mit einer Zustellung zu verwechseln.SMTP-Protokoll: Wie E-Mails aus Anwendungen übertragen werdenErfahren Sie, wie SMTP-Submission, Relay, Envelopes, Antwortcodes, TLS, Wiederholungsversuche und Nachrichteninhalte den E-Mail-Workflow einer Anwendung prägen.