De fleste webmastere og IT-ansvarlige kender SPF-recorden. Den er nem at forstå - den fortæller verden, hvilke servere der må sende e-mail på vegne af dit domæne. Men SPF er kun halvdelen af historien, og den halvdel, de fleste overser, hedder DKIM. DKIM er ikke blot endnu en DNS-record at sætte op og glemme. Den løser et fundamentalt problem, som SPF slet ikke adresserer: hvad der sker med din e-mail, efter den forlader din server.
Hvad DKIM egentlig gør
DKIM står for DomainKeys Identified Mail. Teknologien fungerer som en digital segl på din e-mails indhold - en kryptografisk signatur, der beviser to ting på én gang: at mailen stammer fra dit domæne, og at ingen har ændret i indholdet undervejs fra afsender til modtager.
Forestil dig, at du sender et brev i en forseglet konvolut med et unikt laksegl. Modtageren kan se, at forseglingen er intakt, og at laksegl-mønstret matcher dit. Hvis nogen har åbnet brevet og ændret indholdet, er forseglingen brudt. DKIM gør præcis det samme - bare kryptografisk og automatisk for hver eneste e-mail, dit domæne udsender.
Den tekniske mekanisme bag DKIM
DKIM bygger på asymmetrisk kryptografi med et public/private key-par. Princippet er enkelt, selvom implementeringen foregår i baggrunden uden at du normalt ser det.
Når din mailserver afsender en e-mail, bruger den den private nøgle til at beregne en unik hash-værdi baseret på udvalgte dele af mailen - typisk e-mailens body og specifikke headers som From, To, Subject og Date. Denne hash krypteres med den private nøgle og tilføjes til mailen som en særlig header kaldet DKIM-Signature.
Modtagerens mailserver henter derefter den tilhørende public nøgle fra dit domænes DNS - den ligger som en TXT-record. Med den offentlige nøgle dekrypterer modtageren signaturen og sammenligner den beregnede hash med den, der er indlejret i mailen. Stemmer de overens, er mailen autentisk og uændret. Stemmer de ikke, er mailen enten manipuleret undervejs eller signaturen ugyldig.
DKIM-Signature headeren i praksis
Hver udgående e-mail med DKIM indeholder en header, der ser nogenlunde sådan ud:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=eksempel.dk; s=mail2024;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=ABC123...signaturen...XYZ789De vigtigste parametre her er:
d= - Det domæne, signaturen tilhører. Skal matche afsenderdomænet.
s= - Selector-værdien, som fortæller modtageren, hvilken DNS-record der indeholder den tilhørende public nøgle. I eksemplet er det
mail2024.h= - De headers, der indgår i signaturen. Disse headers er beskyttet mod manipulation.
bh= - En hash af mailens body. Ændres et enkelt tegn i brødteksten, ændres denne hash.
b= - Selve den kryptografiske signatur.
Sådan ser en DKIM TXT-record ud i DNS
Den tilhørende DNS-record publiceres under en specifik navnekonvention: [selector]._domainkey.[domæne]. Med eksemplet ovenfor ville DNS-opslaget ske på:
mail2024._domainkey.eksempel.dkOg selve TXT-record-værdien ser typisk sådan ud:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3...
...din offentlige nøgle her...AQABParametrene i recorden:
v=DKIM1 - Versionen af DKIM-standarden.
k=rsa - Den anvendte krypteringsalgoritme. RSA er standard; nyere opsætninger kan bruge
ed25519.p= - Den base64-kodede offentlige nøgle. Dette er den halvdel af nøgleparret, der er offentligt tilgængeligt og bruges til at verificere signaturer.
Forskellen på SPF og DKIM - de løser ikke det samme problem
SPF (Sender Policy Framework) svarer på spørgsmålet: Kom denne e-mail fra en server, der er autoriseret til at sende på vegne af domænet? SPF verificerer afsendelsesserveren - ikke indholdet.
DKIM svarer på et helt andet spørgsmål: Er denne e-mail virkelig skrevet og afsendt af den, der hævder at have skrevet den, og er indholdet uændret? DKIM verificerer integritet og autenticitet af selve meddelelsen.
De to teknologier komplementerer hinanden. SPF kan brydes eller omgås ved videresendelse, fordi den videresendende server ikke nødvendigvis er på den originale SPF-liste. DKIM-signaturen rejser derimod med mailen og forbliver gyldig, så længe indholdet er uændret - uanset hvilke servere mailen passerer igennem. Det gør DKIM særligt værdifuld i scenarier med automatisk videresendelse og mailinglister.
Sådan finder og tjekker du din DKIM-record
Før du kan verificere din DKIM-opsætning, skal du kende din selector-værdi. Den finder du typisk i din mailudbyders kontrolpanel eller ved at kigge på en udgående e-mails headers og finde DKIM-Signature-feltet med s=-parametret.
Har du selector-værdien, kan du lave et DNS-opslag direkte på DNSinfo's DNS-opslagsværktøj. Søg på TXT-recorden for [selector]._domainkey.[ditdomæne].dk - eksempelvis google._domainkey.eksempel.dk for Google Workspace eller selector1._domainkey.eksempel.dk for Microsoft 365. Returnerer opslaget en record med en p=-værdi, er din public nøgle publiceret korrekt i DNS. Er recorden tom, mangler eller returnerer en fejl, er DKIM ikke aktivt for det pågældende domæne.
Konsekvenserne af manglende eller fejlkonfigureret DKIM
En manglende DKIM-signatur er ikke blot en teknisk mangel - den har direkte konsekvenser for, om dine e-mails når frem.
Modtagerservere hos store udbydere som Gmail, Outlook og Yahoo bruger DKIM-validering som et centralt signal i deres spamfiltrering. E-mails uden gyldig DKIM-signatur behandles med langt større mistænksomhed og havner hyppigere i spam-mappen - eller afvises helt. Afsendere med store mailvolumener, eksempelvis nyhedsbreve og transaktionsmails, er særligt udsatte, fordi manglende DKIM kombineret med høje bounce-rater hurtigt forringer domænets afsenderomdømme.
Den anden kritiske konsekvens handler om DMARC. DMARC-politikken på dit domæne kræver, at en e-mail enten består SPF- eller DKIM-tjekket - og at det godkendte domæne stemmer overens med det domæne, der vises i From-headeren (det såkaldte "alignment"). Mangler DKIM, eller er den konfigureret forkert, fejler DMARC-tjekket for alle mails, der ikke består SPF-alignment. Det betyder, at dine legitime e-mails potentielt afvises eller sættes i karantæne, afhængigt af din DMARC-politik.
Praktisk opsætning hos de mest brugte udbydere
Google Workspace
Log ind på Google Admin Console og navigér til Apps > Google Workspace > Gmail > Authenticate email. Her kan du generere et 2048-bit RSA nøglepar. Google præsenterer dig med den TXT-record, du skal tilføje til dit domænes DNS under google._domainkey.[ditdomæne]. Når recorden er propageret - typisk inden for få timer - aktiverer du signeringen i Admin Console. Google begynder herefter automatisk at signere al udgående e-mail.
Microsoft 365
I Microsoft 365 Defender-portalen navigerer du til Email & Collaboration > Policies & Rules > Threat policies > Email authentication settings > DKIM. Vælg dit domæne og aktivér DKIM-signering. Microsoft genererer to CNAME-records (ikke TXT-records), som du tilføjer til dit DNS. CNAME-tilgangen giver Microsoft mulighed for automatisk at rotere nøglerne uden at du skal opdatere DNS manuelt. Selector-navnene er typisk selector1 og selector2.
Simply.com
Simply.com håndterer DKIM automatisk for e-mailkonti, der er oprettet og hostet direkte hos dem. Log ind på dit Simply-kontrolpanel, gå til E-mail og verificér, at DKIM er aktiveret for dit domæne. Simply publicerer selv de nødvendige DNS-records, hvis du bruger deres navneservere. Bruger du Simply's mailhosting men har DNS hos en anden udbyder, skal du manuelt tilføje de TXT-records, Simply oplyser i kontrolpanelet.
DKIM er fundamentet - ikke hele bygningen
En korrekt konfigureret DKIM-opsætning er ikke målet i sig selv. DKIM er det andet ben i en treenighed af e-mailautentificeringsteknologier, der kun fungerer optimalt, når alle tre er på plads og konfigureret til at arbejde sammen.
SPF definerer, hvilke servere der må afsende på dit domænes vegne. DKIM beviser, at indholdet er autentisk og uændret. DMARC binder de to sammen og fortæller modtagerservere, hvad de skal gøre, når en e-mail fejler disse tjek - og giver dig rapporter, så du kan se, hvem der forsøger at misbruge dit domæne. Uden alle tre er dit domæne enten sårbart over for spoofing, eller dine legitime e-mails risikerer at blive behandlet som spam. DKIM alene løfter leveringsraten og troværdigheden markant - men SPF og DMARC er nødvendige for at lukke de resterende huller.
