SPF, DKIM och DMARC – Del 3 av 4

I denna bloggserie tar jag upp grundläggande mekanismer för att skydda din epost mot spoofing. I del 1 avhandlades Sender Policy Framwork, del 2 handlar om DKIM och denna tredje del fokuserar på Domain-based Message Authentication, Reporting and Conformance eller som det vanligare sägs, DMARC.

Historik

DMARC såg dagens ljus 2012 och kom till som en samarbete mellan PayPal together with Google, Microsoft and Yahoo!. Arbetet gick ut på att skapa en standard för att ”autentisera epost”. DMARC standarden baseras på de redan befintliga initiativen SPF och DKIM men en av de nya sakerna som DMARC tillför är just delen kring rapportering.

Idag beskrivs DKIM i RFC 7489, https://tools.ietf.org/html/rfc7489

Vad är DMARC?

I korthet kan man säga att DMARC är ett protokoll för att se till att du kan begränsa och styra vilka servrar som kan skicka e-post som en specifik avsändardomän. Men en sak som är helt nytt med DMARC är att man även får rapportering på vem som faktiskt skickar e-post i en viss domäns namn. Med DMARC kan man även styra hur mottagaren ska reagera på e-post som kommer från någon av våra domäner. Man kan tex säga att om ett brev från magnus.bjork@altitude365.se som inte klarar ett DKIM och/eller SPF test skall hamna i karantän (skräppost eller liknande beroende på e-postsystem) eller helt enkelt inte tas emot alls.

Hur fungerar DMARC?

En DMARC-policy gör att din organisation kan bestämma hur e-post som skickas från din domän ska hanteras. Denna policy bygger på SFP och DKIM så därför är det viktigt att du konfigurerat båda dessa på ett korrekt sätt.

För att konkretisera så kan vi säga att denna fyrstegsraket är hur det lirar:

1. När ett mail skickas (av dina servrar eller någon som spoofar dig) så kollar mottagande mailserver om du har ett DMARC-record i din DNS
2. Mottagande mailserver testar DKIM och SPF för att avgöra om mailet kommer från dina servrar
   • Har mailet en korrekt DKIM signaur?
   • Matchar IP-adressen de som anges i avsändande domäns SPF-record?
   • Matchar mailets header de tester som körs?
3. När resultatet av testerna i steg 3 är klara kan mottagande mailsystem applicera din DMARC-policy. Denna kan säga tre olika saker:
   • ”reject” (vägra ta emot, dock hatanterar tex Office 365 detta en smula annorlunda vilket vi kommer återkomma till i del 4 av denna serie)
   • ”quarantine” (kan betyda lite olika saker beroende på mailsystem, Office 365 tex lägger dessa i junkmail och inte karantän som namnet kan antyda)
   • gör ingenting (dvs skicka in mailet som vanligt)
4. Det sista steget när mottagande mailsystem bestämt sig för vad det ska göra med mailet är att rapportera till det avsändande mailsystemet (via den epostadress som står i DMARC-record) vad mottagaren gjord med mailet (och alla andra mail det mottaget från samma domän).

Varför ska du ha DMARC?

Det finns en massa bra med DMARC! För det första så är det ett utmärkt sätt att få koll på vem som skickar mail och utger sig för att vara din domän. Det är väldigt vanligt när man börjar kolla på var vi som organisation skickar mail ifrån, att vi (åter)upptäcker servrar vi inte hade en aning om. Övervakningssystem, backupsystem, leverantörer av olika tjänster, nyhetsbrev osv, listan kan göras hur lång som helst för nästan allt mailar. Med DMARC så får du koll på dina källor som skickar mail och du får också veta vilka som utger sig för att vara från din domän. Detta är steg ett och det är fantastiskt enkelt att komma till denna nivån. Men det är inte detta som är slutmålet!

Du vill nå ”reject” eller ”quarantine”! Dvs att när ett mail som skickas i din domäns namn men inte kommer ifrån din organisation så vägrar mottagande system ta emot det eller så lägga det i karantän/skräppost eller likande.

Hur inför du DMARC?

Du behöver någon form av tjänst som kan analysera de rapporter som kommer att komma per mail, det finns en uppsjö av dessa men en som faktiskt är gratis för dig som är Office 365 kund är Valimail, https://see.valimail.com/acton/fs/blocks/showLandingPage/a/42385/p/p-0038/t/page/fm/0.
Notera att Altitude 365 inte ger rekommendationer utan att analysera dina behov, dvs detta är endast att se som ett exempel på en tjänst.

Beroende på tjänst så är detaljerna lite olika men gemensamt för alla är att du för in ett DMARC-record i DNS. I vårt fall ser vårt DMARC-record ut som nedan:

v=DMARC1; p=none; pct=100; rua=mailto:dmarc@altitude365.com; ruf=mailto:dmarc@altitude365.com; fo=1

Se DMARC syntax nedan för detaljer.

DMARC syntax

Se nedanstående tabell för förklaringar till DMARC-syntax. Jag har valt att inte översätta dessa från engelska för att undvika förvirring.

Tag         Förklaring                                           Exempel

v              Protocol version                               v=DMARC1

pct          % of messages subjected to filtering        pct=20

ruf          Reporting URI for forensic reports            ruf=mailto:dmarc@a365.com

rua         Reporting URI of aggregate reports          rua=mailto: dmarc@a365.com

p             Policy for organizational domain                p=quarantine

sp           Policy for subdomains of the OD                sp=reject

adkim    Alignment mode for DKIM                           adkim=s

aspf       Alignment mode for SPF                               aspf=r

fo            Failure Reporting Options                             fo=1

Sammanfattning

DMARC kan lösa en massa problem för dig, du får koll på varifrån dina mail skickas, du kan begränsa vilka källor mottagare tar emot ifrån och ditt ”rykte” som skickandes epost kan förbättras. Det gör sig dock inte av sig själv och du kommer behöva lägga en del tid innan du kan uppnå ”reject” men väl där kommer du ha väldigt mycket bättre koll på din epost-miljö, utöver att du sover gott om nätterna.

Ytterligare läsning:

Altitude 365 Workshop, Hur skickas e-post från era domäner? Vår workshop kring e-postsäkerhet med fokus på SPF, DKIM och DMARC riktar sig till er som vill säkra och skydda era domäner mot bland annat spoofing.

http://www.dkim.org/

Use DKIM to validate outbound email sent from your custom domain in Office 365

https://docs.microsoft.com/en-us/office365/securitycompliance/use-dkim-to-validate-outbound-email