Et dkim=none resultat er ikke en anden stavemåde af en ødelagt signatur. RFC 8601 §2.7.1 definerer DKIM intet resultat, da beskeden ikke bliver underskrevet. Denne skelnen ændrer undersøgelsen: en usigneret meddelelse skal gennemgås underskriftssti, mens en underskrevet meddelelse, der mislykkes, kræver bekræftelsesbevis.
Start med at bekræfte, hvad resultatet tilhører, og hvem der har leveret det. En værktøjsoversigt, en Authentication-Results felt og det rå budskab kan beskrive forskellige observationer. Stol kun på resultatet inden for en bekræftet modtagergrænse, og bevar den originale besked, før du forsøger at forene tilsyneladende modsætninger.
Læs hele resultatfeltet
I Authentication-Results er dkim=none et resultat for DKIM metoden. Den separate formular bestående af en godkendelsestjenesteidentifikator efterfulgt af et blottet ingen angiver, at der ikke blev udført nogen meddelelsesgodkendelse. Disse former er ikke udskiftelige; se RFC 8601 §2.2. Manglende Authentication-Results er heller ikke bevis på, at en meddelelse var usigneret; overskriften er muligvis ikke tilføjet eller bevaret.
Læs authserv-id'et og forstå, hvilket system det identificerer. En meddelelse kan indeholde resultater fra flere hop, inklusive upålidelig tekst indsat før levering. RFC 8601 §7.1 beskriver håndtering af tillidsgrænser, fordi en angriber kan skrive et overbevisende resultatfelt. En bestået eller ingen-streng har kun betydning, når dens oprindelse og evalueringskontekst er etableret.
Undersøg underskriftsbeviset
Se efter DKIM-Signature felter i den bevarede råmeddelelse. Hvis ingen er til stede, og den betroede modtager rapporterer dkim=none, skal du undersøge, om afsenderen aktiverede signering på den rute. Tjek applikationens SMTP , relæforbindelser og API-genereret post uafhængigt af almindelig postkassepost.
Hvis en signatur er til stede, men resultatet siger ingen, skal du ikke straks beskylde modtageren for en fejl. Et senere hop kan have tilføjet signaturen, eller den tilgængelige prøve kan afvige fra den meddelelse, der blev evalueret af den pågældende modtager. Bestem, hvor hvert resultat og signatur kom ind på stien. Fortolkningen afhænger af observationsgrænsen, ikke kun af den endelige overskriftsliste.
Adskil tre praktiske cases
Case 1: Der findes ingen signatur ved den betroede evalueringsgrænse. Den næste handling er at bekræfte den understøttede signeringskonfiguration og -rute. Udgivelse af en anden offentlig nøgle gør ikke tjenesten tegnet.
Tilfælde to: Der findes en signatur, men den tilsvarende nøgle mangler. RFC 6376 §6.1.2 behandler dette som en bekræftelsesfejl uden nøgle, ikke en usigneret besked. Udled opslaget fra signaturens d- og s-værdier, og undersøg DNS udgivelse eller tilbagetrækning.
Tilfælde tre: nøglen hentes, men det dækkede indhold bekræftes ikke. Undersøg kropsrepræsentation, signerede overskrifter, nøglemateriale, beskadigede signaturværdier og underskriver/verifikator-defekter; en fejl alene fastslår ikke, hvilket input der er ændret. Et intakt DKIM-Signature felt betyder ikke, at signaturen passerer. Disse tilfælde er en diagnostisk ramme, ikke et sæt af levende testresultater.
Hold DMARC adskilt fra etiketten
Under en gældende DMARC politik, kan en usigneret meddelelse stadig passere justeret SPF under RFC 9989 §5.3.5. Omvendt leverer en bestået DKIM signatur under et ikke-relateret domæne muligvis ikke DMARC justering. Optag Fra-domænet, SPF identiteten og -resultatet, hver DKIM identitet og -resultat og justering som særskilte observationer.
Udled ikke levering eller sikkerhed fra ingen alene. Modtagere anvender deres egen filtrering, og DKIM er ét input frem for et bevis på, at en besked er harmløs. Det operationelle spørgsmål er, om den forventede autoriserede afsendelsessti har den tilsigtede autentificeringsdækning.
Bevis underskriftsreparationen
Hvis ruten skulle underskrive, skal du bruge udbyderens understøttede konfiguration og teste nye beskeder efter ændringen. Bekræft, at det tilsigtede d-domæne og vælger vises, at signaturen passerer til en betroet modtager, og at den justeres efter behov. Inkluder det faktiske forretningsformat og rute i stedet for en anden tjenestes testknap.
Bevar før-og-efter-beviset med tidsstempler og en rutebeskrivelse. Luk problemet som fraværende underskrift på en navngivet sti, manglende bekræftelsesmateriale eller mislykket integritetsbekræftelse, alt efter hvad der er relevant. Præcis klassificering giver den næste hændelse et nyttigt udgangspunkt.
Beviser nødvendig for den næste beslutning
Til illustration, Authentication-Results: mx.example; dkim=none rapporterer usigneret post for den metode, mens Authentication-Results : mx.example ; ingen siger, at der ikke blev udført godkendelsesskemaer. Ingen af strengene er troværdige, blot fordi mx.example vises i den. Hvis råprøven senere indeholder en signatur, skal du indhente rapporterings-hopprøven eller logfilerne, før du beslutter, om signering var fraværende der. Disse er syntetiske header-eksempler.