DMARC, DKIM og SPF forklart på norsk

De fleste møter DMARC, DKIM og SPF den dagen noe allerede har gått galt. Fakturaen kom aldri fram. Eller en kunde ringer og spør hvorfor dere ba om nytt kontonummer i en e-post dere aldri har sendt.

De tre forkortelsene løser hver sin del av det samme problemet: hvordan kan mottakeren vite at en e-post med din adresse som avsender faktisk kom fra deg? Her er svaret, uten unødvendig sjargong.

Hvorfor dette i det hele tatt er et problem

E-post ble designet på syttitallet, i et nett der alle maskinene i praksis stolte på hverandre. Avsenderadressen i en e-post er derfor omtrent like fri som avsenderfeltet på en konvolutt: du kan skrive hva du vil. Ingenting i selve e-postprotokollen hindrer noen i å sende en melding som ser ut til å komme fra post@dittfirma.no.

DMARC, DKIM og SPF er tre lag som ble lagt oppå i ettertid for å tette det hullet. Alle tre bor i DNS-en til domenet ditt, ikke i e-postprogrammet. Det er derfor du må inn til den som administrerer domenet for å fikse dem, ikke til Outlook.

DMARC: hva mottakeren skal gjøre når noe ikke stemmer

DMARC bestemmer hva mottakeren skal gjøre når en e-post ikke består kontrollene. Selve kontrollene gjøres av DKIM og SPF, som du leser om lenger ned, men ingen av dem sier alene hva som skal skje med en e-post som feiler. Det er DMARC sin jobb.

v=DMARC1; p=none; rua=mailto:dmarc@dittfirma.no

Det sentrale er p, altså policyen:

• p=none gjør ingenting, men du får rapporter. Dette er alltid startpunktet.
• p=quarantine sender det som ikke består til søppelpost.
• p=reject avviser meldingen helt. Den kommer aldri fram noe sted.

rua er adressen som mottar de daglige rapportene om hvem som sender e-post i ditt navn. Dropper du den, kjører du i blinde.

DKIM: en signatur som ikke kan forfalskes

DKIM sier noe om selve meldingen, mens SPF – som du leser om under – sier noe om hvilken server e-posten kom fra. E-postserveren din signerer hver utgående melding med en privat nøkkel, og den offentlige nøkkelen legges i DNS. Mottakeren regner ut om signaturen stemmer.

Stemmer den, vet mottakeren to ting: meldingen kom fra noen som har nøkkelen din, og innholdet er ikke endret underveis. DKIM har også en praktisk fordel over SPF: den overlever videresending. Blir en e-post videresendt, bytter avsenderserveren, og SPF ryker. DKIM-signaturen følger med meldingen.

SPF: hvem har lov til å sende på vegne av deg

SPF er en liste over hvilke servere som har lov til å sende e-post med ditt domene. Den ligger som en TXT-oppføring på domenet og ser omtrent slik ut:

v=spf1 include:spf.protection.outlook.com -all

Oversatt: «e-post fra Microsoft 365 sine servere er godkjent. Alt annet skal avvises.» Bruker dere i tillegg et nyhetsbrevverktøy, et CRM eller et regnskapssystem som sender på deres vegne, må også de inn i listen.

To detaljer er verdt å kjenne til. Den siste delen avgjør hva som skjer med det som ikke står på listen: -all betyr avvis, ~all betyr «marker som mistenkelig, men slipp gjennom». Og SPF har en hard grense på ti DNS-oppslag. Legger du inn for mange tjenester, slutter hele oppføringen å virke, uten at noen varsler deg.

Justering: delen de fleste bommer på

Her ligger den vanligste misforståelsen. SPF kontrollerer ikke adressen mottakeren ser i Fra-feltet. Den kontrollerer en teknisk avsenderadresse i konvolutten, som ofte tilhører et helt annet domene, typisk nyhetsbrevverktøyet du bruker.

Det betyr at en e-post kan bestå SPF, og likevel vise ditt domene til en mottaker som aldri har godkjent noe. DMARC krever derfor justering: domenet mottakeren ser må være det samme domenet som SPF eller DKIM godkjente. Uten justering teller ikke godkjenningen.

Det er denne mekanismen som gjør DMARC til mer enn summen av de to andre, og grunnen til at et domene kan ha både DKIM og SPF på plass og fortsatt være åpent for misbruk.

Rekkefølgen du bør gjøre det i

1. Kartlegg alt som sender e-post i ditt navn. E-postsystemet, nyhetsbrev, CRM, regnskap, bookingsystem, nettbutikk, og gjerne skriveren i resepsjonen.
2. Sett opp SPF med alle sammen, og avslutt med ~all inntil videre.
3. Slå på DKIM hos hver enkelt tjeneste som støtter det.
4. Legg inn DMARC med p=none og en rua-adresse.
5. Les rapportene i noen uker. De avslører tjenestene du glemte.
6. Stram til: først quarantine, så reject og -all når bildet er rent.

Denne rekkefølgen tar uker, ikke minutter. Det er med vilje. Hopper du rett til reject, er det dine egne fakturaer som forsvinner først.

De fem vanligste feilene

• To SPF-oppføringer på samme domene. Det er ikke lov, og resultatet er at ingen av dem gjelder. Slå dem sammen til én.
• Over ti oppslag i SPF. Oppføringen slutter stille å virke.
• Glemte avsendere. Nyhetsbrevet og bookingsystemet er de som oftest faller utenfor.
• DMARC rett på reject. Uten rapportperiode først vet du ikke hva du slår av.
• Ingen rua-adresse. Da har du en policy, men ingen anelse om den virker.

Hva med MTA-STS og BIMI?

Du har kanskje sett disse nevnt i samme åndedrag. De løser andre problemer: MTA-STS handler om at selve forbindelsen mellom e-postservere skal være kryptert, og BIMI handler om å få firmalogoen vist i innboksen. Begge forutsetter at DMARC allerede er på plass. Ta dem etterpå, ikke før.

Slik sjekker du hvor domenet ditt står

Du trenger ikke lese DNS-oppføringer manuelt for å få et svar. Domenesjekken vår leser DMARC, DKIM, SPF, BIMI, MTA-STS og TLS-RPT på domenet ditt, gir en karakter og viser de faktiske verdiene, slik at du ser hva som mangler og hvorfor.

Trenger du hjelp med å rydde opp, eller vil du ha noen til å følge DMARC-rapportene i oppstartsfasen? Se hva vi gjør innen IT-sikkerhet, eller ta kontakt.