DKIM ermöglicht einer Domäne, durch eine kryptografische Signatur die Verantwortung für eine Nachricht zu übernehmen. Um zu verstehen, was das für eine bestimmte E-Mail bedeutet, beginnen Sie mit dem empfangenen Original und nicht mit einem DNS Prüfer. Die nützliche Beweiskette ist Nachrichtensignatur, Signaturdomäne und Wähler, öffentlicher Schlüssel, Ergebnis der Empfängerüberprüfung, dann beliebig DMARC Ausrichtung Entscheidung.
Lesen Sie die unterzeichnete Identität
Suchen Sie jedes DKIM-Signature Header in der ursprünglichen Nachricht. Der d=-Wert identifiziert die signierende Domäne und s= identifiziert ihren Selektor. Für den DNS-basierten Schlüsselabruf kombinieren Sie sie als Selektor. _domainkey.signing-domain. Die signierende Domain kann der Organisation des Autors, einem Relay oder einem für sie agierenden Dienst gehören. DKIM trennt bewusst die Verantwortung für die Unterzeichnung vom scheinbaren Autor. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
Anschauliches Beispiel: „Von“ lautet accounts@example.com “ und eine Signatur enthält d=example.com; s=mail2026. Der Prüfer sucht nach mail2026._domainkey.example.com . Dieser DNS Eintrag stellt öffentliches Verifizierungsmaterial bereit. Der private Signaturschlüssel verbleibt beim autorisierten Unterzeichner und darf nicht veröffentlicht werden. In diesem Beispiel wird die Suche erläutert. Es handelt sich nicht um eine echte Signatur oder eine getestete Nachricht.
Trennen Sie Anwesenheit von erfolgreicher Verifizierung
Ein DKIM-Signature Header kann vorhanden und ungültig sein. Ein DNS Schlüssel kann vorhanden sein, während die Anwendung überhaupt keine Signaturen sendet. Bei der Überprüfung werden die Signaturstruktur, der Schlüssel, die ausgewählten Header und die Textdarstellung überprüft. Änderungen nach der Unterzeichnung können dazu führen, dass es kaputt geht, je nachdem, was sich geändert hat und was Kanonisierung gebraucht. Eine Zeichenfolge, die wie ein Digest aussieht, ist kein Beweis dafür, dass diese Prüfungen erfolgreich waren. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
Überprüfen Sie, ob das empfangende System vertrauenswürdig ist Authentication-Results oder gleichwertige Protokolle. Erfahren Sie, welcher Authentifizierungsdienst dieses Ergebnis hinzugefügt hat und wo nicht vertrauenswürdige eingehende Ergebnisheader entfernt oder ignoriert werden. Ein Absender kann einen plausibel aussehenden Passtext in eine Nachricht einfügen, sodass willkürlicher Inhalt Authentication-Results kein Beweis ist. RFC 8601 §1.2, RFC 8601 §7.1.
Verbinden Sie das Ergebnis mit dem sichtbaren Autor
Vergleichen Sie für DMARC eine erfolgreich verifizierte d=-Domäne mit der Autorendomäne von From. Eine strikte DKIM Ausrichtung erfordert eine genaue Übereinstimmung unten RFC 9989 §3.2.10; Die entspannte Ausrichtung nutzt die Organisationsdomänenerkennung in RFC 9989 §4.10.2. Der Selektor und der optionale i=-Wert sind nicht die Domänen, die für diesen DMARC -Vergleich verwendet werden. Wenn mehrere DKIM -Signaturen vorhanden sind, kann eine passgenaue Signatur den DKIM Pfad zum DMARC -Pass liefern. RFC 9989 §4.4.1.
Im Beispiel entspricht d=example.com der From-Domäne. Wenn stattdessen d=service.example.net überprüft, wird das rohe DKIM bestanden, aber diese nicht verwandte Domäne stellt keine Ausrichtung mit example.com her. Beheben Sie dieses Problem nicht durch Bearbeiten eines empfangenen Headers: Konfigurieren Sie den legitimen Unterzeichner so, dass er eine geeignete unterstützte Identität verwendet.
Erstellen Sie eine nützliche Untersuchungsaufzeichnung
Zeichnen Sie Nachrichtenzeit, Route, Absenderdomäne, jedes D/S-Paar, vertrauenswürdiges DKIM Ergebnis und -Grund, DNS -Beobachtungszeit und Ausrichtungsergebnis auf. Schützen Sie die Originalnachricht, da sie möglicherweise persönliche oder vertrauliche Informationen enthält. Das Schwärzen einer Kopie kann ihre Signatur ungültig machen; Bewahren Sie ein zugriffsgeschütztes Original auf, wenn eine erneute Überprüfung erforderlich ist.
Wenn die Überprüfung fehlschlägt, prüfen Sie, ob die Signatur aktiviert wurde, der richtige Schlüssel verfügbar ist, der Algorithmus unterstützt wird und die Nachricht während der Übertragung geändert wurde. Aktuelle kryptografische Richtlinien ersetzen veraltete Standardeinstellungen: RFC 8301 §3.1 verbietet rsa-sha1 zum Signieren und Verifizieren; RFC 8301 §3.2 Aktualisiert die wichtigsten RSA-Richtlinien. Verwenden Sie nicht die kryptografischen Optionen eines alten Tutorials, nur weil die Syntax immer noch gültig erscheint. Schließen Sie mit dem Nachweis des empfangenen Ergebnisses ab, nicht nur mit dem Nachweis, dass DNS einen Schlüssel enthält.
Wenden Sie die Unterscheidung an
Schreiben Sie für eine hypothetische Nachricht eine Zeile für jede Signatur: d, s, Lookup-Eigentümer, vertrauenswürdiges Überprüfungsergebnis und Ausrichtung. Wenn die Signatur example.com fehlschlägt, während eine nicht verwandte Signatur service.example.net erfolgreich ist, kombinieren Sie die erste Domäne nicht mit dem zweiten Ergebnis. Untersuchen Sie die fehlgeschlagene Signatur und bewerten Sie sie SPF separat vor der Zuweisung DMARC . Für diesen Artikel wurde keine Nachrichtenüberprüfung durchgeführt.