DKIM-signaturer förklarade: vad som gör en signatur pålitlig

Vad är DKIM och hur fungerar en signatur?

DKIM (DomainKeys Identified Mail, RFC 6376) låter det sändande systemet signera varje meddelande med en privat nyckel. Den mottagande servern hämtar den matchande publika nyckeln från DNS och kontrollerar signaturen. Verifieras den vet mottagaren att den signerande domänen har tagit ansvar för meddelandet och att de signerade delarna inte har ändrats sedan dess.

Signaturen ligger i ett DKIM-Signature-huvud som det sändande systemet lägger till. Ett typiskt huvud ser ut så här:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=selector1; t=1767225600; h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR...

d= är den signerande domänen och s= selektorn, och tillsammans talar de om för mottagaren var nyckeln finns. a= är algoritmen, c= kanoniseringen, h= listan över signerade huvuden, bh= en hash av innehållet och b= själva signaturen. Valfria taggar som l=, t=, x= och i= ändrar vad signaturen täcker och hur länge den gäller, och det är där de flesta svaga signaturer går fel.

Var publiceras DKIM-nyckeln?

Den publika nyckeln är en TXT-post på selektorns namn under _domainkey på den signerande domänen. För signaturen ovan slår mottagaren upp selector1._domainkey.example.com:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

k= är nyckeltypen (rsa om den utelämnas) och p= den publika nyckeln i base64. En RSA-nyckel på 2048 bitar är längre än de 255 tecken en TXT-sträng rymmer, så den publiceras som flera citerade strängar i samma post, och mottagaren slår ihop dem. Varje selektor måste ge exakt en nyckelpost. Saknas selektorn, eller svarar två nyckelposter på samma namn, kan ingen mottagare verifiera signaturen på ett pålitligt sätt.

Nyckelposten kan också ha flaggor. Ett tomt p= betyder att nyckeln är återkallad, och signaturer som gjorts med den verifieras inte. t=y markerar att nyckeln testas, vilket säger åt mottagare att bortse från misslyckade verifieringar, så ingenting tillämpas så länge flaggan finns kvar. Ta bort den när signeringen fungerar. t=s betyder att identiteten i signaturens i= måste använda exakt d=-domänen och inte en underdomän till den.

Varför måste DKIM-domänen stämma med From-domänen?

DKIM ensamt bevisar bara något om d=-domänen, och den kan vara vilken domän som helst som avsändaren styr över. DMARC lägger till kopplingen till adressen mottagaren ser: ett DKIM-pass räknas bara för DMARC när d=-domänen är i linje med domänen i From-huvudet.

Med relaxed alignment, som är standard, måste d=-domänen och From-domänen höra till samma organisationsdomän, så en signatur med d=mail.example.com är i linje med From: news@example.com. Med strict alignment (adkim=s i DMARC-posten) måste de vara identiska.

Därför spelar externa avsändare roll. Ett nyhetsbrevsverktyg eller CRM-system som signerar med sin egen domän ger en giltig signatur som inte hjälper ert DMARC-resultat alls. Be varje leverantör att signera med er domän. De kallar det oftast eget DKIM eller egen avsändardomän, och ni publicerar nyckeln eller en CNAME-post som de ger er under ert eget _domainkey-namn.

Vilken DKIM-algoritm och nyckellängd ska jag använda?

• rsa-sha256 är standardvalet och verifieras av alla mottagare.
• rsa-sha1 är föråldrad. RFC 8301 tog bort SHA-1 från DKIM eftersom kollisioner går att ta fram i praktiken, och allt fler mottagare vägrar sådana signaturer. Behandla det som ett fel och byt till SHA-256.
• ed25519-sha256 (RFC 8463) ger korta nycklar och stark säkerhet, men alla mottagare verifierar den inte ännu. Använd den som en andra signatur vid sidan av en RSA-signatur, inte i stället för den.
• RSA-nycklar bör vara på 2048 bitar. En nyckel på 1024 bitar verifieras fortfarande, men är en äldre nyckel att byta vid nästa rotation. Nycklar kortare än 1024 bitar är inte tillåtna enligt RFC 8301, och flera stora mottagare vägrar dem.

Nyckeltypen i DNS måste stämma med algoritmen i signaturen. En ed25519-sha256-signatur kan inte verifieras mot en RSA-nyckel, och omvänt, så publicera varje nyckel under en egen selektor.

Vilka huvuden ska en DKIM-signatur täcka?

Taggen h= listar de huvuden som signaturen skyddar. From är det som måste finnas med. RFC 6376 kräver det, och en signatur som inte täcker From bevisar ingenting om den avsändare mottagaren ser, så den kan inte ge ett DMARC-pass hur stark kryptografin än är.

Utöver From minskar det som kan ändras efter avsändningen om ni signerar Subject, Date, Message-ID, To, MIME-Version och Content-Type. Vissa huvuden skrivs om på vägen av legitima skäl, så att ett av dem är osignerat är inget fel i sig.

Som avancerad härdning kan ni översignera känsliga huvuden genom att lista deras namn en gång fler än de förekommer i meddelandet:

h=from:from:subject:subject:date:to:message-id

Den extra posten signerar att det inte finns någon andra kopia, så den som lägger till ett extra From- eller Subject-huvud bryter signaturen. Alla e-postplattformar låter er inte ställa in detta.

Vilka risker finns med taggarna l=, x= och t=?

• l= begränsar signaturen till de första så och så många byten av innehållet. Det som läggs till efter den punkten bryter inte signaturen, så tillagd text, eller ett helt annat meddelande, får er domäns autentisering på köpet. Ta bort l= så att hela innehållet signeras.
• x= anger när signaturen upphör att gälla. Det är normalt att utelämna den. Om den finns behandlas en utgången signatur som ett fel, och fördröjd eller köad e-post drabbas värst. En giltighetstid på mer än ungefär 30 dagar är värd att korta, eftersom den som senare kommer åt den privata nyckeln kan återanvända meddelanden som fortfarande verifieras.
• t= anger när meddelandet signerades. En tidsstämpel mer än ungefär en timme in i framtiden betyder oftast att klockan i det signerande systemet går fel, och vissa mottagare avvisar sådana signaturer.

Taggen i= kan ange en användare eller underdomän som meddelandet signerades för. Det är normalt att utelämna den. Om den finns måste dess domän vara d=-domänen eller en underdomän till den, och bara d=-domänen själv när nyckeln har t=s. Annars underkänns signaturen vid verifieringen.

Är relaxed kanonisering mindre säker än simple?

Nej. Kanoniseringen (taggen c=) avgör hur huvuden och innehåll normaliseras innan de signeras och verifieras. Simple tål nästan inga ändringar. Relaxed tål de ofarliga ändringar som e-postsystem gör på vägen, som annorlunda blanksteg och omradbrutna huvudrader.

Relaxed är inget svagare val. Det är det som gör att signaturer klarar en vanlig leverans, och relaxed/relaxed är en bra inställning i drift. Alla standardkombinationer fungerar. Utelämnas c= gäller simple/simple. Bara ett okänt värde är ett problem, eftersom mottagare troligen bortser från det.

Hur roterar jag DKIM-nycklar utan att e-posten slutar fungera?

Att rotera betyder att byta nyckelpar, vilket begränsar skadan om en privat nyckel läcker. Det säkra sättet använder två selektorer, så att e-post aldrig signeras med en nyckel som inte är publicerad:

1. Skapa ett nytt nyckelpar och publicera den publika nyckeln under en ny selektor, till exempel selector2._domainkey.example.com.
2. Vänta tills posten har spridits i DNS, minst postens TTL.
3. Låt det sändande systemet signera med den nya selektorn.
4. Låt den gamla selektorn ligga kvar några dagar, tills e-post som signerades och köades med den gamla nyckeln har levererats.
5. Återkalla den gamla nyckeln genom att publicera den med ett tomt p=, eller ta bort posten.

Många leverantörer sköter detta åt er: ni publicerar två CNAME-poster en gång, och de roterar nycklarna bakom dem. DNS låter ingen lista selektorerna under _domainkey, så en extern kontroll av ett meddelande ser bara den selektor som meddelandet använde. Stäm av med varje leverantör att det finns en andra selektor och att nycklarna byts enligt ett schema.

DMARC Visions kostnadsfria e-postsäkerhetskontroll läser DKIM-signaturen i ett meddelande ni skickar till den, slår upp den publicerade nyckeln och redovisar de punkter i den här guiden som ett enskilt meddelande kan visa.