DKIM i praksis: selectors, nøgler og tjenester

Modul 4: Leveringsevne: SPF, DKIM og DMARC i praksis · Læsetid: 12 minutter

Læringsmål: Efter denne lektion kan du analysere en DKIM-Signature-header, opsætte DKIM med dit eget domæne hos enhver afsendertjeneste, kontrollere om en selector virker, og forklare hvordan du udskifter nøgler sikkert.

Centrale begreber: DKIM-Signature, d= (det underskrivende domæne), s= (selector), h= (underskrevne headere), bh= og b=, kanonikalisering (c=), <selector>._domainkey.<domæne>, TXT med p= eller CNAME til tjenesten, nøglelængde 2048 bit (RFC 8301), stykker på 255 tegn, ed25519 (RFC 8463), nøgleudskiftning, tom p= (tilbagekaldt), DKIM og videresendelse

Hvorfor DKIM er den vigtigste af de tre

SPF angiver hvilke servere der må sende mail, men det går i stykker ved videresendelse og kigger på Return-Path, som ved mange tjenester ikke er dit. DKIM sætter en signatur i selve mailen. Den signatur overlever videresendelse (så længe mailen ikke bliver ændret) og er knyttet til et domæne, du selv vælger. Derfor er DKIM i praksis ofte det eneste, der får DMARC til at godkende nyhedsbreve, fakturaer fra et regnskabsprogram og videresendt mail.

Det grundlæggende (hvordan nøglen står i DNS'en, hvad en selector er) findes i DNS-kurset, lektion 4.4. Her går vi videre: hvad står der præcis i en signatur, og hvordan ordner du DKIM for hver tjeneste?

Analyse af en signatur

Åbn headerne for en mail, du har modtaget (lektion 1.5). Øverst står der, hvis mailen er underskrevet, noget som:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
	t=1762588800; h=from:to:subject:date:message-id:mime-version:content-type;
	bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
	b=Gm7yW3q...lang tegnrække...Qx9A==

Modtageren henter den offentlige nøgle fra <s>._domainkey.<d>, her altså x._domainkey.example.com, og kontrollerer om b= passer med headerne fra h= og fingeraftrykket bh=. Er der undervejs ændret et enkelt bogstav i teksten eller i en underskrevet header, så fejler kontrollen.

I Authentication-Results ser du resultatet, for eksempel dkim=pass header.d=example.com header.s=x. En mail kan have flere signaturer, for eksempel en fra dit domæne og en fra selve tjenesten. For DMARC tæller kun en signatur, hvor d= hører til dit Fra-domæne.

Hver tjeneste sin egen selector

Et domæne kan have mange DKIM-nøgler samtidig, hver under sin egen selector. Det er netop meningen: hver tjeneste, der sender mail på dine vegne, underskriver med sin egen nøgle.

TXT eller CNAME?

• Ved en TXT-record sætter du selv den offentlige nøgle i din DNS. Vil tjenesten have en ny nøgle, skal du selv opdatere recorden.
• Ved en CNAME-record peger du selectoren videre til et navn hos tjenesten, for eksempel k2._domainkey.example.com CNAME dkim2.mailer.example. Tjenesten administrerer så selv nøglen og kan udskifte den uden at du behøver gøre noget. Derfor vælger store tjenester CNAME, og de bruger ofte to: så kan de skifte mellem en aktiv og en ny nøgle.

Bemærk: en CNAME må ikke stå ved siden af en anden record på samme navn. Står der allerede en TXT på selector1._domainkey, skal den fjernes.

Det vigtigste: slå DKIM til hos tjenesten

Hos mange tjenester er DKIM med dit eget domæne ikke slået til som standard. De underskriver så med deres eget domæne (d=mailer.example). Mailen er så nok underskrevet, men ikke tilpasset (alignment) med din Fra-adresse. For DMARC tæller det ikke. I administrationen af tjenesten hedder det ofte "verificer domæne", "domæneverifikation", "autentificering" eller "eget afsenderdomæne". Først når du har sat recordsne op og slået det til i tjenesten, underskriver den med d=example.com.

Nøgler: længde, stykker og algoritme

• Længde. RFC 8301 siger: mindst 1024 bit, og afsendere bør bruge mindst 2048 bit. Brug 2048. En nøgle på 512 bit bliver opfattet som ugyldig af modtagere.
• Stykker på 255 tegn. En TXT-record består af tegnrækker på højst 255 tegn. En 2048-bit-nøgle er cirka 400 tegn og passer ikke i én række. Recorden består så af to eller flere rækker efter hinanden ("v=DKIM1; k=rsa; p=MIIBIj..." "...IDAQAB"), som modtageren limer sammen. De fleste paneler gør det automatisk. Går det galt, får du en afkortet nøgle, og hver signatur fejler. Kopiér derfor altid en nøgle i sin helhed, uden ekstra mellemrum eller anførselstegn i midten.
• ed25519 (RFC 8463) er en mere moderne algoritme med korte nøgler. Ikke alle modtagere kontrollerer det endnu. Den, der bruger det, underskriver derfor med to signaturer: en RSA og en ed25519.

Udskiftning af en nøgle

Det er godt at udskifte en nøgle en gang imellem, og især hvis du tror, den private nøgle er blevet lækket (for eksempel efter et hack af serveren eller en administrator der er stoppet). Gør det sådan:

1. Lav en ny nøgle under en ny selector, for eksempel s2026, og sæt den offentlige nøgle i DNS'en.
2. Vent til recorden er synlig overalt (TTL'en, se DNS-kurset lektion 6.1).
3. Lad serveren underskrive med den nye selector.
4. Lad den gamle nøgle stå i et par dage endnu: mail, der allerede var undervejs eller bliver kontrolleret igen, henviser stadig til den.
5. Tilbagekald den gamle nøgle ved at tømme p= (v=DKIM1; p=), eller fjern recorden.

Hos tjenester med CNAME-records gør tjenesten dette selv.

Hvad der får DKIM til at fejle

• Mailen ændres undervejs: en mailingliste der sætter [listenavn] i emnet eller tilføjer en sidefod, en virusscanner der limer en linje under mailen, en videresendelsesserver der konverterer formateringen.
• Forkert eller afkortet nøgle i DNS'en.
• Selector findes ikke: en tastefejl i navnet, eller selector1._domainkey.example.com.example.com (domænenavnet dobbelt, fordi panelet selv sætter det bagved).
• Nøgle tilbagekaldt (tom p=), mens serveren stadig underskriver med den selector.

Kontroller om det virker

1. Send en mail fra tjenesten til en adresse hos Gmail eller Outlook.com.
2. Åbn headerne og find DKIM-Signature: noter d= og s=.
3. Kig i Authentication-Results om der står dkim=pass, og om header.d= er dit domæne.
4. Slå selectoren op: dig TXT s._domainkey.example.com (eller med et online værktøj). Der skal stå en p= med en lang nøgle, eller en CNAME der peger på sådan en record.

I praksis: sådan ser det ud i et panel

Ved en hostingpakke fra WebOké er DKIM slået til som standard, med selectoren x: recorden hedder x._domainkey.<dit domæne>. I DirectAdmin ser du det under DNS-administration; ligger din DNS hos en anden udbyder, kopierer du den record derhen. I Mit WebOké viser kortet Angiv e-mail, hvilken værdi der skal stå, og om den bliver fundet. Hos andre udbydere hedder selectoren noget andet (default, mail, dkim), men du finder den på samme måde: i panelet eller i s= for en underskrevet mail.

Opsummering

• DKIM er den kontrol, der overlever videresendelse, og som du knytter til dit eget domæne pr. tjeneste; for DMARC tæller kun en signatur med dit domæne i d=.
• I DKIM-Signature finder du d= (domæne) og s= (selector); nøglen står på <s>._domainkey.<d>.
• Hver tjeneste får sin egen selector; CNAME-records lader tjenesten selv udskifte nøgler. Sørg for også rent faktisk at slå DKIM med dit eget domæne til i tjenesten.
• Brug 2048 bit; vær opmærksom på afkortede nøgler ved kopiering.
• Udskift en nøgle med en ny selector, og tilbagekald først den gamle bagefter.

Quiz

Opgave

Opgave Z4.3: Kontrollér en DKIM-selector. Send en mail fra dit eget domæne (eller fra en tjeneste, der sender mail på dine vegne) til en egen adresse hos en anden udbyder. Åbn headerne og udfyld værdierne for d= og s= fra DKIM-Signature, og hvad der står i Authentication-Results ved dkim=. Programmet slår selectoren op live, følger en eventuel CNAME, kontrollerer nøglen (til stede, ikke tom, længde) og fortæller om d= er tilpasset (alignment) med det domæne, du angiver som afsender.

Læs mere

Trinnene i disse artikler gælder for panelerne hos WebOké; hos andre udbydere fungerer det på lignende vis.

• Gratis DNS-kursus 4.4: DKIM: underskriften under din mail
• DirectAdmin vejledning 5.8: DKIM slå til og kontrollere
• Opsæt DKIM, når DNS kører via en ekstern server
• WebOké vejledning 6.7: Kortet Opsæt e-mail (MX, SPF, DKIM, DMARC)
• RFC 6376 (DKIM), RFC 8301 (nøglelængde og algoritmer), RFC 8463 (ed25519)