A DKIM-Signature er et sæt semikolon-separerede tags, der beskriver, hvordan et domæne signerede en besked. At læse disse felter hjælper dig med at vælge den rigtige DNS opslag og undersøgelsessti. Det lader dig ikke validere kryptografien med øjet. Bevar den originale meddelelse, før du kopierer eller omformaterer en signatur til inspektion.
Start med opslags- og algoritmefelterne
Den påkrævede d=-værdi er signeringsdomænet; påkrævet s= er vælger. Med den normale DNS TXT forespørgselsmetode fører disse til s. _domainkey.d. a=-tagget identificerer signerings- og hash-algoritmen. Det påkrævede v=-tag skal have værdien 1 for RFC 6376 -signatursyntaks. Dette adskiller sig fra versionskoden i en DNS nøglepost. Disse værdier beskriver signaturen, ikke dens verifikationsresultat. RFC 6376 §3.5, RFC 6376 §3.6.2.
Illustrativt fragment, bevidst ufuldstændigt og ikke en gyldig signatur: d=example.com; s=outbound2026; a=rsa-sha256; c=relaxed/relaxed; h=from:to:subject:date. Dens opslagsnavn er outbound2026._domainkey.example.com . Dens kanonisering bruger afslappet bearbejdning til både header og krop. Dens signerede overskriftsliste navngiver de valgte overskriftsfelter. Fragmentet udelader påkrævede kryptografiske værdier og må aldrig bruges som en produktionspost.
Skelne indholdsdækning fra signaturdata
H=-tagget viser overskriftsfelter, der leveres til signeringsoperationen, i deres definerede rækkefølge. Det er ikke en hash-algoritme. Fra skal indgå i en gyldig DKIM signatur. Gentagne headernavne og duplikerede meddelelsesfelter kræver udvælgelsesreglerne i specifikationen; et tilfældigt blik på listen kan ikke løse alle dækningsspørgsmål.
Bh=-tagget indeholder kropshash. B=-tagget indeholder signaturværdien. Matchende eller plausibelt udseende kodninger beviser ikke gyldighed. c=-tagget beskriver kanonisering, som tillader specifik normalisering af den signerede repræsentation. Det tillader ikke vilkårlig omskrivning af en meddelelse. Hvis c= udelades, er standarden simpel/simpel; hvis kun én algoritme er navngivet, gælder den for overskrifter, og brødteksten er som standard simpel. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §5.4.
Det valgfrie l=-tag begrænser antallet af inkluderede kanoniserede kropsoktetter. Dets tilstedeværelse kræver omhu: En gyldig signatur dækker muligvis ikke indhold, der er tilføjet ud over denne længde. Beskriv ikke alle DKIM sendes som bevis på, at hver synlig byte er uændret. RFC 6376 §3.5, RFC 6376 §8.2.
Fortolk identitet og tid omhyggeligt
Den valgfrie i=-værdi er en agent- eller bruger-id, der hævdes under signeringsdomænets regler; det er ikke nødvendigvis en fungerende postkasse. DMARC bruger valideret d=, ikke i=, til DKIM justering. t= og x= tags beskriver signeringstid og signaturudløb. RFC 6376 §3.5 markerer formelt begge ANBEFALET, selvom de kan være fraværende. De er signaturmetadata, ikke bevis for faktisk SMTP ankomsttid. Bevar modtagne overskrifter og systemlogfiler til transitanalyse.
En signatur, der bruger forældet kryptografi, bør ikke accepteres, blot fordi dens felter parses. RFC 8301 §3.1 forbyder rsa-sha1; RFC 8301 §3.2 opdaterer RSA-nøglekrav. Brug understøttet verifikationssoftware og aktuelle udbydervejledning i stedet for manuelt at implementere disse kontroller fra denne feltvejledning.
Afslut med modtagerresultatet
Indsaml d/s-parret, algoritmen, relevante dækningsfelter, betroet DKIM resultat og fejlårsag. Hvis DNS mangler, skal du undersøge det nøjagtige ejernavn og nøglelivscyklus. Hvis nøglen er tilgængelig, men verifikationen mislykkes, skal du sammenligne signerings- og leveringsstier uden at ændre det originale bevis. Bekræft enhver afhjælpning med en nyligt sendt besked og et betroet modtagerresultat. Målet er en forsvarlig forklaring på en signatur, ikke et visuelt bestået/ikke bestået gæt.
Anvend sondringen
Læs det illustrative fragment i fire grupper: d/s vælger identitet og opslag; a/c specificerer algoritme og kanonisering; h og enhver l definerer dækning; b/bh bærer værdier, som softwaren verificerer. Manglende påkrævet v/b/bh betyder, at fragmentet ikke er en gyldig signatur. Hvis l=0 vises i en reel signatur, hashes nul body-oktetter, så kropsintegriteten er ikke beskyttet; RFC 6376 §3.5 definerer denne længdemekanisme. Ingen af disse observationer er et kryptografisk pass.