Signaturen og nøglen
Jeres mailserver signerer udvalgte dele af mailen med en privat nøgle, altså afsender, emne og brødtekst. Den offentlige modpart ligger som en DNS-record på jeres domæne. Modtageren henter nøglen, verificerer signaturen og ved derefter to ting med sikkerhed. Mailen er sendt af en server med adgang til jeres private nøgle, og indholdet er ikke ændret undervejs.
Til forskel fra SPF overlever DKIM normalt videresendelse. Signaturen følger med mailen, uanset hvilken vej den tager.
Hvorfor DKIM ikke står alene
DKIM beviser, at en signatur er gyldig. Den beviser ikke, at signaturdomænet er det samme som det afsenderdomæne, modtageren ser. En angriber kan signere med sit eget domæne og stadig vise jeres i Fra-feltet.
Det er DMARC, der kræver det match, og som fortæller modtageren, hvad der skal ske, når det fejler. SPF og DKIM leverer beviserne. DMARC dømmer.
Det, der driller i praksis
DKIM-nøgler bør være mindst 2048 bit. Ældre nøgler på 1024 bit regnes ikke længere for sikre.
Nøgler skal roteres med passende mellemrum, og hver tjeneste, der sender for jer, skal have sin egen DKIM-opsætning med eget selector-navn. Microsoft 365, nyhedsbrevssystemet, CRM’et.
Vil I se, hvilke af jeres nøgler der kan findes udefra, og hvor lange de er, så kør domænet gennem vores DKIM-tjek. Kender I et selector-navn, vi ikke gætter, kan I skrive det selv.
En glemt tjeneste uden DKIM er det svage led, den dag I strammer jeres DMARC-politik. Som regel er det også den, ingen kan huske hvem der oprettede. På mindst tre af de elleve domæner, vi har gennemgået den seneste måned, var DKIM slet ikke sat op. På ét af dem stod DMARC alligevel på p=reject, så hele politikken hvilede på SPF alene. At finde dem alle er hovedparten af arbejdet i et DMARC-forløb.