SPF, DKIM och DMARC – Del 2 av 4

DKIM bygger på två olika initiativ, Domain Keys och Identified Internet Mail (IIM). Dessa båda togs fram av Yahoo och Cisco, men 2004 så fastställdes en standard hos Internet Engenering Task Force. Precis som beskrivet i första delen av denna bloggserie så är det avsaknaden av autentisering i SMTP som ligger bakom behovet.

Idag beskrivs DKIM i RFC 6376, https://tools.ietf.org/html/rfc6376

Efter första initiativet med Sender Policy Framwork så 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 autentiseras att epost kommer från den organisation den utger sig för att komma ifrån.

I korthet kan man säga att DKIM ser till att din organisation kan ta ansvar för att epost skickas på ett sätt så att mottagaren kan verifiera att det verkligen är din organisation som skickat det.

Detta göra genom att en krypterad del läggs till i headern på varje epostmeddelande, en slags digital signatur. När mottagaren sen tar emot epostmeddelandet så 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å är brevet från någon av dina servrar.

När en server är konfigurerad för DKIM så kommer denna att lägga till en krypterad signatur i headern på samtliga epostmeddelande den skickar ut. En sådan signatur kan se ut på följande vis:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=altitude365.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 avsett för att mottagande epostsystem automatiskt ska kunna processa den information som kommer. Några av de värde 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 epost med en DKIM signatur så 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.altitude365.com

selector1-altitude365-com._domainkey.Altitude365.onmicrosoft.com.

Dvs mottagande server får veta i signaturen (s=) att den ska kolla selector1, selector1 hittar servern via att gå till länken selector1._domainkey.altitude365.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 Altitude365.com verkligen är avsändare av detta brev.

Som beskrivet i förra delen av den här serien 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 som organisation att du har system som inte stödjer DKIM men mer om det under sammanfattningen nedan.

DKIM kräver något mer av dig än ”lillebror” SPF men det är också ett bra mycket bättre skydd mot spoofing. Det som framförallt av dig och din organisation är att ni ser över era tjänster ni använder för att skicka mail, tjänster som nyhetsbrev, reklamutskick mm. Här behöver ni som organisation se över hur upphandlingar görs osv. Denna delen är en av de saker som vi behandlar i vår workshop som ni hittar här.