Skydda din e-post från spoofing, del 2: DKIM

I denna artikelserie tar jag upp grundläggande mekanismer för att skydda sin e-post mot spoofing. I del 1 avhandlades Sender Policy Framwork, denna del fokuserar på DomainKeys Identified Mail, eller som man oftare uttrycker det: DKIM.

DKIM bygger på två olika initiativ, Domain Keys och Identified Internet Mail (IIM). Dessa båda togs fram av Yahoo och Cisco, men 2004 fastställdes en standard hos Internet Engeneering Task Force. Precis som beskrivet i första delen av denna artikelserie så är det avsaknaden av autentisering i SMTP som ligger bakom behovet. Idag beskrivs DKIM i RFC 6376, https://tools.ietf.org/html/rfc6376

DomainKeys Identified Mail
Efter första initiativet med Sender Policy Framwork konstaterade många att flera utmaningar inte var lösta, bland annat problematiken med vidarebefordrad e-post, och ytterligare en lösning togs fram för att åstadkomma en lösning som på ett säkrare och flexiblare sätt kunde autentisera att e-post kommer från den organisation den utger sig för att komma från.

Vad är DKIM?
I korthet kan man säga att DKIM ser till att din organisation kan ta ansvar för att e-post skickas på ett sätt så att mottagaren kan verifiera att det verkligen är din organisation som skickat det. Detta görs genom att en krypterad del läggs till i headern på varje e-postmeddelande som en slags digital signatur. När mottagaren sedan tar emot e-postmeddelandet kan denna digitala signatur verifieras genom att dekryptera signaturen med en publik nyckel. Om den publika nyckeln passar för att låsa upp signaturen så kommer brevet från någon av dina servrar.

Hur fungerar DKIM?
När en server är konfigurerad för DKIM kommer denna att lägga till en krypterad signatur i headern på samtliga e-postmeddelande som den skickar ut. En sådan signatur kan se ut på följande sätt:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exobe.com;

s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;

bh=yaOrs6n35yfZvI4OZxinvJ1ihYwvsUxhvj7bVgt1QPI=;

b=kF3xBBwzo/gEgx4U9W58a/xhpkA9fB7J+O9EInFFFwiYXtIBSUQR8j4MO4i8RMX4a/gHsYdaJ/NeageW1XT4odKVD1JHFrHf9gEoxJjuJfK5kDqQTbVzmhn6/bpioD956kEVzjemSwrZwy+6wSundWU3wT5o/+yNsYQgjZ6TK8w=

Som du kan se så innehåller denna en hel del information som är avsedd för att mottagande e-postsystem automatiskt ska kunna processa den information som kommer. Några av de värden man kan utläsa ur DKIM-signaturen är (d=) avsändande SMTP-domän, (b=) den faktiska signaturen och (bh=) en hash som används för att dekrypteras med den publika nyckeln. När mottagande servern tar emot e-post med en DKIM-signatur kontrollerar den i DNS var avsändande domäns publika nyckel finns via ett CNAME-record.
I vårt fall ser detta CNAME-record ut som nedan.

selector1._domainkey.exobe.com

selector1-exobe-com._domainkey.exobe.onmicrosoft.com.

Mottagande server får alltså veta i signaturen (s=) att den ska kolla selector1, selector1 hittar servern genom att gå till länken selector1._domainkey.exobe.com som i vårt fall pekar vidare till Office 365. Nedan en skiss på hur detta fungerar:

Nu kan mottagande server dekryptera signaturen och avgöra om exobe.com verkligen är avsändare av detta brev.

Risker och problem med DKIM
Som beskrivet i förra delen, så har SPF en del tillkortakommanden när det gäller automatisk vidarebefordring. DKIM har inga liknande problem. Möjligen skulle det kunna vara ett problem för dig vars organisation inte har system som stödjer DKIM, men mer om detta i sammanfattningen nedan.

Sammanfattning
DKIM kräver något mer av dig än ”lillebror” SPF, men det är också ett mycket bättre skydd mot spoofing. Det som framförallt krävs av dig och din organisation är att ni ser över de tjänster ni använder för exempelvis nyhetsbrev, reklamutskick och att skicka mejl. Här behöver ni som organisation även se över hur upphandlingar görs.