DKIM

DKIM står for DomainKeys Identified Mail. Metoden tilføjer en kryptografisk signatur til udgående e-mail. Modtagerens mailserver henter en offentlig nøgle fra afsenderdomænets DNS og bruger den til at kontrollere, om signaturen er gyldig.

Signaturen dækker udvalgte headers og en beregning af beskedens indhold. En gyldig kontrol viser, at de signerede dele ikke er ændret på en måde, der bryder signaturen, siden den signerede mail blev sendt. Den knytter samtidig signeringen til et domæne angivet i DKIM-headeren.

DKIM krypterer ikke beskeden. Mailens tekst og vedhæftninger bliver ikke hemmelige af at være DKIM-signeret. Metoden handler om domæneidentifikation og dataintegritet, ikke om ende-til-ende-kryptering.

DKIM indgår ofte sammen med SPF. De to kan hver især give et autentificeringsresultat, mens DMARC vurderer, om et godkendt domæne stemmer tilstrækkeligt overens med domænet i det synlige Fra-felt.

DKIM aktiveres normalt hos mailudbyderen. Udbyderen opretter eller viser en privat nøgle i sit system og giver dig en DNS-record med den offentlige nøgle. Den private nøgle skal blive hos den tjeneste, der signerer mailen.

Nøglen publiceres under en selector, eksempelvis google._domainkey.example.dk eller selector1._domainkey.example.dk. Selectoren står i hver DKIM-signatur og fortæller modtageren, hvor den relevante offentlige nøgle skal slås op.

Afhængigt af leverandøren publiceres nøglen som en TXT-record eller via CNAME til leverandørens DNS. Kopiér navn og værdi præcist, og vær opmærksom på, om DNS-panelet selv tilføjer domænet til hostfeltet.

Efter aktivering bør du sende en testmail og læse Authentication-Results og DKIM-Signature i headeren. Kontrollér, at resultatet er pass, hvilket d-domæne der signerer, og om det matcher det domæne, der forventes i DMARC-politikken.

En virksomhed sender gennem Google Workspace. Administratoren genererer en DKIM-nøgle og får hostnavnet google._domainkey. Når DNS-recorden er synlig, aktiveres signering. Nye mails får en DKIM-Signature-header, som modtagere kan kontrollere.

Webshoppen sender ordrebekræftelser gennem en separat e-mailtjeneste. Tjenesten bruger en anden selector og måske et subdomæne. Begge systemer kan have hver sin DKIM-nøgle, så længe records og alignment er planlagt korrekt.

En mailingliste tilføjer en footer til en videresendt besked. Ændringen kan bryde DKIM-signaturen, afhængigt af hvad der er signeret og canonicalization. Hvis SPF samtidig fejler på grund af videresendelsen, kan DMARC også fejle. Det er en kendt udfordring i indirekte mailflows.

En svindler sender en DKIM-signeret mail fra sit eget domæne og skriver virksomhedens navn i display name. DKIM kan godt bestå, fordi signaturen er ægte for svindlerens domæne. Det viser, at en gyldig signatur ikke gør selve budskabet sandt.

Den mest almindelige fejl er at publicere recorden uden at aktivere signering hos leverandøren, eller omvendt. Begge dele skal være på plads. En offentlig nøgle i DNS gør intet, hvis udgående mails ikke signeres med den tilhørende private nøgle.

En anden fejl er forkert selector. DNS kan indeholde en gyldig nøgle på selector1, mens mailen spørger efter selector2. Modtageren kan så ikke finde nøglen og får et DKIM-resultat som none eller fail.

Pas også på meget gamle eller svage nøgler. Mailudbydere tilbyder typisk rotation eller nye selectors. Ved nøgleskift kan gammel og ny record eksistere parallelt i en overgang, så mails i kø stadig kan verificeres.

Til sidst bør DKIM ikke bruges som eneste sikkerhedsmål. En angriber kan sende gyldigt signerede mails fra sit eget domæne. Filtre og brugere skal stadig vurdere afsender, domæne, indhold og kontekst.

DKIM-signaturen indeholder blandt andet d= for signeringsdomænet og s= for selectoren. Kombinationen bruges til DNS-opslaget. Headeren kan også vise, hvilke felter der er signeret og hvilken algoritme der er brugt.

Alignment i DMARC kræver ikke nødvendigvis, at DKIM-domænet er tegn for tegn identisk med Fra-domænet. Ved relaxed alignment kan et relevant subdomæne være tilstrækkeligt, mens strict alignment kræver et tættere match.

Et domæne kan have flere selectors samtidig. Det gør det muligt at bruge forskellige leverandører og rotere nøgler uden at erstatte én global DKIM-record. Hver afsender skal dog være dokumenteret og fortsat nødvendig.

Signaturen kan bruge relaxed eller simple canonicalization for header og body. Relaxed tolererer visse ufarlige ændringer i mellemrum og formatering, mens simple er mere følsom. Valget foretages normalt af mailudbyderen og påvirker, hvor let signaturen overlever transporten.

Nogle gateways tilføjer bannere som “Denne mail kommer udefra”. Hvis ændringen sker i beskedens body efter signering, kan DKIM brydes. Organisationer med sådanne gateways bør teste både indgående og videresendte flows, især hvis DMARC-politikken er streng.

En selector kan afsløre leverandøren eller nøglens generation, men navnet har ingen sikkerhed i sig selv. Vælg et administrerbart navn og dokumentér, hvem der ejer den. Når en tjeneste opsiges, bør dens selector og DNS-record fjernes efter en passende overgang.

DKIM-rotation bør planlægges, så nye mails signeres med den nye nøgle, mens den gamle offentlige nøgle fortsat kan findes i en periode. Mails kan ligge i kø eller blive leveret forsinket, og en for hurtig fjernelse kan gøre en ellers gyldig signatur umulig at kontrollere.

En DKIM-signatur kan have en tidsmarkering og eventuel udløbstid, men ikke alle implementeringer bruger udløb. Modtageren vurderer stadig beskedens samlede kontekst og kan afvise en mail med gyldig signatur på grund af omdømme eller indhold.

Når flere systemer sender for samme domæne, bør hver leverandør helst have sin egen selector. Det gør fejlsøgning og udfasning enklere end at dele én nøgle på tværs af systemer. Den private nøgle bør aldrig kopieres mellem leverandører uden en meget klar arkitektur.

Headeren From, signeringsdomænet d= og selector s= kan læses i mailens rå kilde. Det er en nyttig kontrol, når et administrationspanel blot siger “DKIM aktiv”. En rigtig test af en leveret mail viser, hvad modtageren faktisk så.

DKIM passer ikke nødvendigvis efter en mail er blevet ændret af en mailingliste. ARC kan bevare autentificeringsresultater gennem visse indirekte flows, men det er en separat standard. For de fleste virksomheder er første skridt stadig korrekt DKIM og DMARC på de direkte afsendere.

DKIM-resultatet “body hash did not verify” peger ofte på, at indholdet er ændret efter signering. En manglende nøgle eller forkert selector giver en anden type fejl. Den præcise fejltekst er derfor vigtigere end blot et rødt DKIM-symbol i et testværktøj.

Nogle leverandører bruger CNAME-records til DKIM, så de selv kan rotere den underliggende nøgle. Det kan være lettere at vedligeholde end en statisk TXT-nøgle, men domæneejeren skal stadig sikre, at CNAME peger korrekt og kun til den valgte leverandør.

På fælles platforme bør hver kundes domæne have egen DKIM-konfiguration. En signatur med platformens generiske domæne kan være teknisk gyldig, men giver ikke nødvendigvis alignment eller samme brandbeskyttelse som et tilpasset domæne.

En nøgle bør roteres efter leverandørens anbefalinger og straks ved mistanke om kompromittering. Rotation kræver normalt, at en ny selector publiceres, før afsenderen skifter til den. Den gamle record kan blive stående en kort overgang, så mails, der allerede er undervejs, stadig kan valideres.

Når flere brands sender fra samme tekniske platform, skal domæner, selectors og ansvar være dokumenteret separat. Det mindsker risikoen for, at en ændring for én kunde påvirker en anden, og gør det lettere at afgøre, hvilken leverandør der ejer en ukendt signatur i mailheaderen.

DKIM kan være godkendt, selv om afsendernavnet ser mistænkeligt ud, fordi signaturen validerer et andet domæne end det synlige From-domæne. DMARC tilføjer kravet om alignment. Ved fejlsøgning skal du derfor se både på resultatet og på de domæner, der faktisk blev brugt i signaturen og afsenderfeltet.

Vi hjælper med domæne- og mailopsætning omkring hjemmesider og webshops. Vores artikel om HTTP og HTTPS, forklarer, hvorfor autentificering, kryptering og domæneopslag er forskellige sikkerhedslag.