DKIM lader et domæne tage ansvar for en besked gennem en kryptografisk signatur. For at forstå, hvad det betyder for en bestemt e-mail, skal du starte med den modtagne original i stedet for en DNS kontrol. Den nyttige beviskæde er beskedsignatur, underskriftsdomæne og vælger, offentlig nøgle, modtagerbekræftelsesresultat og derefter evt DMARC justering afgørelse.
Læs den identitet, der blev underskrevet
Find hver DKIM-Signature header i den originale besked. Værdien d= identificerer signeringsdomænet, og s= identificerer dets vælger. For DNS-baseret nøglehentning skal du kombinere dem som vælger. _domainkey.signing-domain. Signeringsdomænet kan tilhøre forfatterens organisation, et relæ eller en tjeneste, der handler for den. DKIM adskiller bevidst signeringsansvaret fra den tilsyneladende forfatter. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
Illustrativt eksempel: From er accounts@example.com og en signatur indeholder d=example.com; s=mail2026. Verifikatoren slår mail2026._domainkey.example.com op. Denne DNS post leverer offentligt verifikationsmateriale. Den private signaturnøgle forbliver hos den autoriserede underskriver og må ikke offentliggøres. Dette eksempel forklarer opslag; det er ikke en rigtig signatur eller en testet besked.
Adskil tilstedeværelse fra vellykket bekræftelse
En DKIM-Signature header kan være til stede og ugyldig. En DNS nøgle kan eksistere, mens applikationen slet ikke sender nogen signaturer. Verifikation kontrollerer signaturstruktur, nøgle, valgte overskrifter og kropsrepræsentation. Ændringer efter underskrivelse kan bryde det, afhængigt af hvad der er ændret og kanonisering brugt. En streng, der ser sammenfattende ud, er ikke bevis på, at disse kontroller bestod. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
Undersøg modtagersystemets betroede Authentication-Results eller tilsvarende logfiler. Forstå, hvilken godkendelsestjeneste der tilføjede dette resultat, og hvor upålidelige indgående resultatoverskrifter fjernes eller ignoreres. En afsender kan indsætte plausibelt udseende pass-tekst i en meddelelse, så vilkårligt Authentication-Results er ikke bevis. RFC 8601 §1.2, RFC 8601 §7.1.
Forbind resultatet til den synlige forfatter
For DMARC skal du sammenligne et med succes verificeret d=-domæne med Author Domain fra From. Streng DKIM justering kræver et nøjagtigt match under RFC 9989 §3.2.10; afslappet justering bruger organisationsdomæneopdagelsen i RFC 9989 §4.10.2. Vælgeren og den valgfri i=-værdi er ikke de domæner, der bruges til denne DMARC sammenligning. Hvis flere DKIM signaturer er til stede, kan én passerende tilpasset signatur levere DKIM stien til DMARC passet. RFC 9989 §4.4.1.
I eksemplet matcher d=example.com Fra-domænet. Hvis i stedet d=service.example.net verificerer, godkendes rå DKIM , men det ikke-relaterede domæne etablerer ikke justering med example.com . Du må ikke "rette" dette ved at redigere en modtaget header: konfigurer den legitime underskriver til at bruge en passende understøttet identitet.
Opbyg en nyttig undersøgelsesjournal
Registrer beskedtid, rute, Fra domæne, hvert d/s-par, betroet DKIM resultat og årsag, DNS observationstid og justeringsresultat. Beskyt den originale meddelelse, fordi den kan indeholde personlige eller fortrolige oplysninger. Redigering af en kopi kan ugyldiggøre dens signatur; beholde en adgangskontrolleret original, når genbekræftelse er nødvendig.
Hvis verifikationen mislykkes, skal du undersøge, om signering var aktiveret, den korrekte nøgle er tilgængelig, algoritmen understøttes, og meddelelsen ændres under overførsel. Nuværende kryptografisk vejledning erstatter forældede standardindstillinger: RFC 8301 §3.1 forbyder rsa-sha1 til signering og verifikation; RFC 8301 §3.2 opdaterer RSA nøglevejledning. Brug ikke en gammel tutorials kryptografiske valg, blot fordi dens syntaks stadig ser gyldig ud. Afslut med bevis for det modtagne resultat, ikke kun bevis på, at DNS indeholder en nøgle.
Anvend sondringen
For en hypotetisk meddelelse skal du skrive en række for hver signatur: d, s, opslagsejer, betroet verifikationsresultat og justering. Hvis example.com -signaturen mislykkes, mens en ikke-relateret service.example.net -signatur passerer, skal du ikke kombinere det første domæne med det andet resultat. Undersøg den mislykkede signatur og evaluer SPF separat, før du tildeler DMARC . Ingen meddelelsesbekræftelse blev udført for denne artikel.