Ein dkim=none Ergebnis ist keine andere Schreibweise einer fehlerhaften Signatur. RFC 8601 §2.7.1 definiert die DKIM Kein Ergebnis, da die Nachricht nicht signiert ist. Diese Unterscheidung verändert die Untersuchung: Eine nicht signierte Nachricht erfordert eine Überprüfung des Signaturpfads, während eine signierte Nachricht, die fehlschlägt, einen Verifizierungsnachweis benötigt.
Bestätigen Sie zunächst, wozu das Ergebnis gehört und wer es bereitgestellt hat. Eine Tool-Zusammenfassung, ein Authentication-Results Das Feld und die Rohnachricht können unterschiedliche Beobachtungen beschreiben. Vertrauen Sie dem Ergebnis nur innerhalb einer verifizierten Empfängergrenze und bewahren Sie die ursprüngliche Nachricht auf, bevor Sie versuchen, offensichtliche Widersprüche in Einklang zu bringen.
Lesen Sie das vollständige Ergebnisfeld
In Authentication-Results ist dkim=none ein Ergebnis für die DKIM Methode. Das separate Formular, bestehend aus einer Authentifizierungsdienst-ID, gefolgt von einem bloßen Keine, zeigt an, dass keine Nachrichtenauthentifizierung durchgeführt wurde. Diese Formen sind nicht austauschbar; sehen RFC 8601 §2.2. Fehlende Authentication-Results sind auch kein Beweis dafür, dass eine Nachricht nicht signiert war; Der Header wurde möglicherweise nicht hinzugefügt oder beibehalten.
Lesen Sie die Authserv-ID und verstehen Sie, welches System sie identifiziert. Eine Nachricht kann Ergebnisse aus mehreren Hops enthalten, einschließlich nicht vertrauenswürdigem Text, der vor der Zustellung eingefügt wurde. RFC 8601 §7.1 beschreibt den Umgang mit Vertrauensgrenzen, da ein Angreifer ein überzeugend aussehendes Ergebnisfeld schreiben kann. Eine Pass- oder None-Zeichenfolge hat nur dann eine Bedeutung, wenn ihre Herkunft und ihr Bewertungskontext festgelegt sind.
Überprüfen Sie den Unterschriftsnachweis
Suchen DKIM-Signature Felder in der erhaltenen Rohnachricht. Wenn keine vorhanden sind und der vertrauenswürdige Empfänger dkim=none, prüfen Sie, ob der Absender die Signatur auf dieser Route aktiviert hat. Überprüfen Sie Anwendungs SMTP , Relay-Konnektoren und API-generierte E-Mails unabhängig von gewöhnlicher Postfach-E-Mail.
Wenn eine Signatur vorhanden ist, das Ergebnis jedoch keine anzeigt, beschuldigen Sie den Empfänger nicht sofort eines Fehlers. Möglicherweise wurde die Signatur durch einen späteren Hop hinzugefügt, oder das verfügbare Beispiel weicht möglicherweise von der von diesem Empfänger ausgewerteten Nachricht ab. Stellen Sie fest, wo jedes Ergebnis und jede Signatur in den Pfad gelangt ist. Die Interpretation hängt von der Beobachtungsgrenze ab, nicht nur von der endgültigen Header-Liste.
Trennen Sie drei praktische Fälle
Fall eins: An der vertrauenswürdigen Bewertungsgrenze ist keine Signatur vorhanden. Die nächste Aktion besteht darin, die unterstützte Signaturkonfiguration und -route zu bestätigen. Durch die Veröffentlichung eines anderen öffentlichen Schlüssels wird der Dienst nicht signiert.
Fall zwei: Eine Signatur ist vorhanden, aber der entsprechende Schlüssel fehlt. RFC 6376 §6.1.2 behandelt dies als einen Fehler bei der Überprüfung ohne Schlüssel und nicht als eine nicht signierte Nachricht. Leiten Sie die Suche aus den d- und s-Werten der Signatur ab und untersuchen Sie DNS Veröffentlichung oder -Entfernung.
Fall drei: Der Schlüssel wird abgerufen, aber der abgedeckte Inhalt wird nicht überprüft. Untersuchen Sie die Körperdarstellung, signierte Header, Schlüsselmaterial, beschädigte Signaturwerte und Unterzeichner-/Prüffehler. Ein Fehler allein sagt nicht aus, welche Eingabe sich geändert hat. Ein intaktes DKIM-Signature Signaturfeld bedeutet nicht, dass die Signatur erfolgreich ist. Bei diesen Fällen handelt es sich um einen Diagnoserahmen und nicht um eine Reihe von Live-Testergebnissen.
Bewahren Sie DMARC getrennt vom Etikett auf
Unter einem anwendbaren DMARC Gemäß dieser Richtlinie kann eine nicht signierte Nachricht weiterhin ausgerichtet weitergeleitet werden SPF unter RFC 9989 §5.3.5. Umgekehrt stellt eine weitergebende DKIM Signatur unter einer nicht verwandten Domäne möglicherweise kein DMARC bereit Ausrichtung. Zeichnen Sie die Von-Domäne, SPF -Identität und das SPF-Ergebnis, jede DKIM Identität und das jeweilige DKIM-Ergebnis sowie die Ausrichtung als eindeutige Beobachtungen auf.
Schließen Sie Lieferung oder Sicherheit nicht allein von niemandem ab. Empfänger wenden ihre eigene Filterung an, und DKIM ist eher eine Eingabe als ein Beweis dafür, dass eine Nachricht harmlos ist. Die operative Frage ist, ob der erwartete autorisierte Sendepfad die beabsichtigte Authentifizierungsabdeckung aufweist.
Beweisen Sie die Signierreparatur
Wenn die Route signieren soll, verwenden Sie die vom Anbieter unterstützte Konfiguration und testen Sie neue Nachrichten nach der Änderung. Stellen Sie sicher, dass die beabsichtigte d-Domäne und Wähler Es scheint, dass die Signatur an einen vertrauenswürdigen Empfänger gelangt und dort ausgerichtet wird, wo sie benötigt wird. Fügen Sie das tatsächliche Geschäftsformat und die Route ein und nicht die Testschaltfläche eines anderen Dienstes.
Bewahren Sie die Vorher-Nachher-Beweise mit Zeitstempeln und einer Routenbeschreibung auf. Schließen Sie das Problem als fehlende Signatur auf einem benannten Pfad, fehlendes Verifizierungsmaterial oder ggf. fehlgeschlagene Integritätsüberprüfung. Eine präzise Klassifizierung gibt dem nächsten Vorfall einen sinnvollen Ausgangspunkt.
Beweise für die nächste Entscheidung erforderlich
Zur Veranschaulichung: Authentication-Results: mx.example; dkim=none meldet nicht signierte E-Mails für diese Methode, while Authentication-Results : mx.example ; keiner sagt, dass keine Authentifizierungsschemata durchgeführt wurden. Keine der beiden Zeichenfolgen ist allein deshalb vertrauenswürdig, weil mx.example darin vorkommt. Wenn das Rohbeispiel später eine Signatur enthält, besorgen Sie sich das Reporting-Hop-Beispiel oder die Protokolle, bevor Sie entscheiden, ob dort keine Signatur vorhanden war. Dies sind Beispiele für synthetische Header.