Der zuverlässigste Ort, um einen zu finden DKIM Selektor ist das DKIM-Signature Kopfzeile der Nachricht, die Sie untersuchen. Lesen Sie den s=-Wert und koppeln Sie ihn mit der d=-Signaturdomäne aus derselben Signatur.
Der Selektor gibt an, wo Verifizierungsmaterial veröffentlicht wird. Es identifiziert weder den sichtbaren Absender noch beweist es, dass die Signatur erfolgreich war. In diesem Leitfaden werden die Hinweise einer empfangenen Nachricht auf den korrekten DNS Namen untersucht und anschließend erläutert, was durch die Suche ermittelt werden kann und was nicht.
Erhalten Sie die ursprünglich empfangene Nachricht
Verwenden Sie eine kontrollierte Nachricht, die über den eigentlichen Dienst an einen separaten Empfänger gesendet wird. Bewahren Sie die dort empfangene Originalnachricht auf. Ein weitergeleiteter Screenshot oder eine erneut gespeicherte, bearbeitete Nachricht kann Beweise auslassen oder ändern.
Suchen Sie jeden DKIM-Signature Header. Eine Nachricht kann mehr als eine Nachricht enthalten. Erfassen Sie für jede Signatur die Signaturdomäne und den Selektor separat und korrelieren Sie dann das Überprüfungsergebnis des vertrauenswürdigen Empfängers.
- d: Signierungsdomäne.
- s: Selektor.
- a: Signierungs-/Hash-Algorithmus.
- h: Liste der ausgewählten signierten Header.
- bh und b: Körper-Hash und Signaturwerte, keine DNS -Public-Key-Einträge.
Diese Felder werden definiert durch RFC 6376 §3.5.
Ersetzen Sie nicht die sichtbare Von-Domäne durch d= beim Erstellen der Schlüsselsuche. Ausrichtung ist ein späterer Vergleich zwischen der vorübergehenden Signaturidentität und der sichtbaren Von-Identität.
Erstellen Sie den Verifizierungsnamen und fragen Sie ihn ab
Unter RFC 6376 §3.6.2.1, der Verifizierungsname kombiniert die beiden Werte derselben Signatur:
<Auswahl>. _domainkey .<Signaturdomäne>
In diesem synthetischen Beispiel identifiziert die Signatur:
Die synthetische Signatur hat d=example.com und s=mail2026.
Die entsprechende Suche lautet:
dig TXT mail2026._domainkey.example.com +noall +answer
Wenn ein Anbieter die Schlüsselverwaltung über a delegiert CNAME, überprüfen Sie auch diese Kette:
dig CNAME mail2026._domainkey.example.com +noall +answer
Hierbei handelt es sich um beispielhafte DNS -Prüfungen, nicht um die Überprüfung einer erfassten echten Nachricht. Verwenden Sie die tatsächlichen Signaturwerte. Unter RFC 1034 §3.6.2Folgen Sie für einen veröffentlichten Alias dem beabsichtigten Ziel und stellen Sie sicher, dass die Verifizierungsdaten über die Kette verfügbar sind.
Öffentliches DNS enthält das Verifizierungsschlüsselmaterial oder die dazu führende Delegation. Der private Signaturschlüssel gehört in das autorisierte Signatursystem, nicht in ein TXT Eintrag.
Interpretieren Sie die Suche zusammen mit den Verifizierungsergebnissen
Eine Antwort mit öffentlichem Schlüssel zeigt, dass ein Resolver zu diesem Zeitpunkt bestimmtes Verifizierungsmaterial abrufen kann. Es beweist nicht, dass eine Nachricht eine Signatur enthält, dass der entsprechende private Schlüssel korrekt verwendet wurde oder dass der signierte Inhalt intakt blieb.
Wenn der Schlüssel vorhanden ist, die Signatur jedoch fehlschlägt, untersuchen Sie das vollständige Überprüfungsergebnis. Inhaltsänderungen, fehlerhafte oder inkompatible Schlüsseldaten, Signaturabdeckung, zeitbezogene Bedingungen und DNS Beobachtungen können unterschiedliche Abhilfemaßnahmen erfordern.
Wenn kein Schlüssel gefunden wird, überprüfen Sie den genauen d= Und s=, die autorisierende Zone, das CNAME Ziel, den Verlauf der Schlüsselentfernung und Resolver-Fehler. Veröffentlichen Sie keinen erratenen Selektor, nur um einen Stein grün zu machen.
Wenn das Original keine relevante DKIM Signatur aufweist, kann eine Selektorsuche keine Signatur herstellen. Überprüfen Sie, ob der tatsächliche Absender zum Signieren konfiguriert ist, ob der Dienst die erforderliche Identität unterstützt und ob eine spätere Route die Evidenz geändert hat.
Behandeln Sie mehrere Signaturen und Schlüsselrotationen
Erstellen Sie für jede Signatur und ihr vertrauenswürdiges Ergebnis eine separate Zeile. Die eigene Weitergabesignatur eines Dienstes ist möglicherweise nicht ausgerichtet, während die Passsignatur einer Kundendomäne die Ausrichtung weitergibt. Eine andere Nachricht weist möglicherweise eine fehlgeschlagene Kundendomänensignatur und nur eine nicht damit zusammenhängende Weitergabesignatur auf.
Überprüfen Sie für die Rotation, welchen Selektor die tatsächliche Nachricht verwendet hat, und nicht nur, welche beiden Datensätze im DNS verfügbar sind. Behalten Sie die Beziehung zwischen Konfigurationsstatus, Signaturumstellung und bereits übertragenen Nachrichten bei. Die Außerbetriebnahme eines alten Selektors kann sich auf die spätere Überprüfung gespeicherter oder verzögerter Nachrichten auswirken.
Verwenden Sie für Microsoft 365 die mandantenspezifischer Einrichtungsleitfaden. Verwenden Sie für den Arbeitsbereich die Anleitung zur Einrichtung ausgewählter Domains. Das gemeinsame Auswahlmuster beider Anbieter sollte das Lesen der tatsächlichen Beweise nicht ersetzen.
Bestätigen Sie die Anmeldung beim tatsächlichen Dienst
Wenn ein Anbieter sagt, dass Ihre Domain hat DKIM konfiguriert ist, bitten Sie ihn, eine vom entsprechenden Workflow gesendete Nachricht und die Domäne anzuzeigen, die sie tatsächlich signiert hat. Ein öffentlich sichtbarer Schlüssel ist eine Konfigurationsabhängigkeit und kein Beweis für eine Live-Signatur.
Dies ist wichtig, wenn mehrere Werkzeuge dieselbe sichtbare Marke verwenden. Mitarbeiter-E-Mails, Support-Tickets und Quittungen können unterschiedliche Selektoren, Signaturdomänen und Besitzer haben. Eine erfolgreiche Kontrolle bei einem kann den Rest nicht ersetzen.
Behalten Sie den Überblick über die Eigentumsverhältnisse und Delegationen der Unterzeichnung
Halten Sie ein Selektorinventar bereit, das an den Dienst, die Domäne, das Schlüsselverwaltungsmodell und den Geschäftsinhaber gebunden ist. Unterscheiden Sie die direkte Kontrolle eines Schlüssels von der Delegation an einen Anbieter. Überprüfen Sie die Delegation, wenn ein Dienst ausgelagert wird.
Beschränken Sie den Zugriff auf private Schlüssel und definieren Sie die Reaktion auf eine vermutete Kompromittierung. Eine gültige öffentliche Aufzeichnung ist kein Beweis dafür, dass die Schlüsselverwahrung ordnungsgemäß ist. In ähnlicher Weise stellt eine gültige Signatur eine Behauptung auf Domänenebene über den abgedeckten Inhalt her; Es genehmigt weder eine Zahlungsanforderung noch schließt es eine Kontokompromittierung aus.
Die nützliche Beweiskette besteht aus Nachricht, Signaturidentität, Schlüsselsuche, vertrauenswürdiger Überprüfung und Ausrichtung. Halten Sie diese Beobachtungen zusammen, damit der nächste Prüfer die Diagnose reproduzieren kann.
Der praktische Imbiss
Halten Sie die ursprüngliche Nachricht, die Signaturidentitäten, DNS Beobachtung und das Ergebnis des vertrauenswürdigen Empfängers zusammen. Dieser Beweis unterscheidet einen fehlenden Schlüssel von einer nicht signierten Nachricht, einer fehlgeschlagenen Signatur oder einer Signatur, die zwar erfolgreich ist, aber nicht übereinstimmt.
Wenden Sie die Unterscheidung an
Mit zwei hypothetischen Signaturen, d=example.com/s=mail2026 und d=service.example.net/s=outbound, fragen Sie mail2026._domainkey.example.com und outbound._domainkey.service.example.net separat ab. Kombinieren Sie niemals mail2026 mit dem zweiten d. Bewahren Sie jede Suchzeit und jedes vertrauenswürdige Ergebnis zusammen mit dem zugehörigen Paar auf. Ein später fehlender Schlüssel löscht nicht die frühere Beobachtung eines vertrauenswürdigen Empfängers.