DKIM i praktiken: selectors, nycklar och tjänster

Modul 4: Leveransbarhet: SPF, DKIM och DMARC i praktiken · Lästid: 12 minuter

Lärandemål: Efter den här lektionen kan du tolka en DKIM-Signature-rubrikrad, ställa in DKIM med ditt eget domän för valfri avsändartjänst, kontrollera om en selector fungerar, och förklara hur du byter nycklar på ett säkert sätt.

Nyckelbegrepp: DKIM-Signature, d= (signerande domän), s= (selector), h= (signerade rubrikrader), bh= och b=, kanonisering (c=), <selector>._domainkey.<domän>, TXT med p= eller CNAME till tjänsten, nyckellängd 2048 bit (RFC 8301), bitar om 255 tecken, ed25519 (RFC 8463), nyckelbyte, tom p= (återkallad), DKIM och vidarebefordran

Varför DKIM är den viktigaste av de tre

SPF anger vilka servrar som får skicka mejl, men går sönder vid vidarebefordran och tittar på Return-Path, som hos många tjänster inte är ditt eget. DKIM lägger en signatur i själva mejlet. Den signaturen överlever vidarebefordran (så länge mejlet inte ändras) och är kopplad till ett domän som du själv väljer. Därför är DKIM i praktiken ofta det enda som får DMARC att godkännas för nyhetsbrev, fakturor från ett bokföringsprogram och vidarebefordrad mejl.

Grunderna (hur nyckeln ligger i DNS, vad en selector är) finns i DNS-kursen, lektion 4.4. Här går vi vidare: vad står det egentligen i en signatur, och hur ordnar du DKIM för varje tjänst?

Att tolka en signatur

Öppna rubrikraderna för ett mejl du tagit emot (lektion 1.5). Högst upp står det, om mejlet är signerat, något i stil med:

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...lång teckensträng...Qx9A==

Mottagaren hämtar den publika nyckeln från <s>._domainkey.<d>, i det här fallet alltså x._domainkey.example.com, och kontrollerar om b= stämmer med rubrikraderna från h= och fingeravtrycket bh=. Har en enda bokstav i texten eller i en signerad rubrikrad ändrats under vägen, misslyckas kontrollen.

I Authentication-Results ser du resultatet, till exempel dkim=pass header.d=example.com header.s=x. Ett mejl kan ha flera signaturer, till exempel en från ditt domän och en från själva tjänsten. För DMARC räknas bara en signatur där d= hör till ditt Från-domän.

Varje tjänst sin egen selector

Ett domän kan ha många DKIM-nycklar samtidigt, var och en under en egen selector. Det är precis meningen: varje tjänst som skickar mejl å dina vägnar signerar med en egen nyckel.

TXT eller CNAME?

• Med en TXT-post lägger du själv in den publika nyckeln i din DNS. Vill tjänsten ha en ny nyckel måste du själv ändra posten.
• Med en CNAME-post pekar du selectorn vidare till ett namn hos tjänsten, till exempel k2._domainkey.example.com CNAME dkim2.mailer.example. Tjänsten sköter då nyckeln själv och kan byta den utan att du behöver göra något. Därför väljer stora tjänster CNAME, och använder ofta två: på så sätt kan de växla mellan en aktiv och en ny nyckel.

Observera: en CNAME får inte finnas bredvid en annan post på samma namn. Finns det redan en TXT på selector1._domainkey, ta bort den.

Det viktigaste: slå på DKIM hos tjänsten

Hos många tjänster är DKIM med ditt eget domän inte påslaget som standard. De signerar då med sitt eget domän (d=mailer.example). Mejlet är då visserligen signerat, men inte uppriktat med din Från-adress. För DMARC räknas inte det. I tjänstens administration heter det ofta "verifiera domän", "domänverifiering", "autentisering" eller "eget avsändardomän". Först när du både har lagt in posterna och slagit på det i tjänsten signerar den med d=example.com.

Nycklar: längd, bitar och algoritm

• Längd. RFC 8301 säger: minst 1024 bit, och avsändare bör använda minst 2048 bit. Använd 2048. En nyckel på 512 bit ses av mottagare som ogiltig.
• Bitar om 255 tecken. En TXT-post består av teckensträngar på max 255 tecken. En 2048-bit-nyckel är ungefär 400 tecken och ryms inte i en enda sträng. Posten består då av två eller fler strängar efter varandra ("v=DKIM1; k=rsa; p=MIIBIj..." "...IDAQAB"), som mottagaren klistrar ihop. De flesta paneler gör det automatiskt. Går det fel får du en avkapad nyckel och varje signatur misslyckas. Kopiera därför alltid en nyckel i sin helhet, utan extra mellanslag eller citattecken i mitten.
• ed25519 (RFC 8463) är en modernare algoritm med korta nycklar. Ännu kontrollerar inte alla mottagare den. Den som använder den signerar därför med två signaturer: en RSA och en ed25519.

Att byta en nyckel

Det är bra att byta en nyckel då och då, och absolut om du misstänker att den privata nyckeln har läckt ut (till exempel efter en hackad server eller en administratör som slutat). Gör så här:

1. Skapa en ny nyckel under en ny selector, till exempel s2026, och lägg den publika nyckeln i DNS.
2. Vänta tills posten syns överallt (TTL, se DNS-kursen lektion 6.1).
3. Låt servern signera med den nya selectorn.
4. Låt den gamla nyckeln ligga kvar några dagar till: mejl som redan var på väg eller kontrolleras på nytt hänvisar fortfarande till den.
5. Återkalla den gamla nyckeln genom att tömma p= (v=DKIM1; p=), eller ta bort posten.

Hos tjänster med CNAME-poster sköter tjänsten detta själv.

Vad som får DKIM att misslyckas

• Mejlet ändras på vägen: en mejllista som lägger till [listnamn] i ämnesraden eller en fotnot, ett virusskydd som klistrar in en rad under mejlet, en vidarebefordringsserver som ändrar formateringen.
• Fel eller avkapad nyckel i DNS.
• Selectorn finns inte: ett stavfel i namnet, eller selector1._domainkey.example.com.example.com (domännamnet dubbelt, eftersom panelen redan lägger till det själv).
• Nyckeln återkallad (tom p=) medan servern fortfarande signerar med den selectorn.

Kontrollera att det fungerar

1. Skicka ett mejl från tjänsten till en adress hos Gmail eller Outlook.com.
2. Öppna rubrikraderna och leta upp DKIM-Signature: notera d= och s=.
3. Kolla i Authentication-Results om det står dkim=pass, och om header.d= är ditt domän.
4. Slå upp selectorn: dig TXT s._domainkey.example.com (eller med ett onlineverktyg). Det ska stå en p= med en lång nyckel, eller en CNAME som leder till en sådan post.

I praktiken: så ser det ut i en panel

I ett hostingpaket från WebOké är DKIM påslaget som standard, med selectorn x: posten heter x._domainkey.<dittdomän>. I DirectAdmin ser du den i DNS Beheer; ligger din DNS hos en annan leverantör kopierar du posten dit. I Mitt WebOké visar kortet Ange e-post vilket värde som ska finnas och om det hittas. Hos andra leverantörer heter selectorn något annat (default, mail, dkim), men du hittar den på samma sätt: i panelen eller i s= för ett signerat mejl.

Sammanfattning

• DKIM är kontrollen som överlever vidarebefordran och som du kopplar till ditt eget domän per tjänst; för DMARC räknas bara en signatur med ditt domän i d=.
• I DKIM-Signature hittar du d= (domän) och s= (selector); nyckeln ligger på <s>._domainkey.<d>.
• Varje tjänst får en egen selector; CNAME-poster låter tjänsten själv byta nycklar. Se till att verkligen slå på DKIM med ditt eget domän i tjänsten.
• Använd 2048 bit; var uppmärksam på avkapade nycklar vid kopiering.
• Byt en nyckel med en ny selector och återkalla den gamla först efteråt.

Quiz

Uppgift

Uppgift Z4.3: Kontrollera en DKIM-selector. Skicka ett mejl från ditt eget domän (eller från en tjänst som skickar å dina vägnar) till en egen adress hos en annan leverantör. Öppna rubrikraderna och fyll i värdena för d= och s= från DKIM-Signature, samt vad som står vid dkim= i Authentication-Results. Programmet slår upp selectorn i realtid, följer en eventuell CNAME, kontrollerar nyckeln (finns, inte tom, längd) och berättar om d= är uppriktat med det domän du anger som avsändare.

Läs mer

Stegen i dessa artiklar gäller för panelerna hos WebOké; hos andra leverantörer fungerar det på liknande sätt.

• Gratis DNS-kurs 4.4: DKIM: signaturen under din e-post
• DirectAdmin-guide 5.8: Aktivera och kontrollera DKIM
• Ställ in DKIM när DNS ligger på en extern server
• WebOké manual 6.7: Kortet Ställ in e-post (MX, SPF, DKIM, DMARC)
• RFC 6376 (DKIM), RFC 8301 (nyckellängd och algoritmer), RFC 8463 (ed25519)