E-postspoofing: Så skyddar du dig med SPF, DKIM & DMARC

6 av 7 toppbyråer kan spoofas

Tidigare i år körde vi vår fullständiga SVAR-säkerhetsgranskning av 597 svenska advokatbyråer. Rubrikresultaten kring GDPR-efterlevnad var usla. Men e-postautentiseringen var ännu sämre.

Bland de sju största byråerna, de som hanterar de känsligaste företagsförvärven och brottmålen, saknade sex stycken fungerande DMARC-policy. Det är byråer vars namn väger tungt. Ett mejl från dem öppnas, litas på och ageras efter. Precis det som gör spoofing så farligt.

Det här är inte teori. Business email compromise (BEC) är den dyraste typen av cyberbrott i världen. FBI:s IC3 rapporterade förluster på över 2,9 miljarder dollar under 2023. Advokatbyråer är extra utsatta. De hanterar banköverföringar, förlikar tvister och skickar känslig information via mejl varje dag.

Lösningen är varken dyr eller krånglig. SPF, DKIM och DMARC är gratis, öppna standarder som funnits i över tio år. Den här guiden förklarar vad de gör, hur de hänger ihop och hur du sätter upp dem steg för steg.

Hur e-postspoofing fungerar

E-post byggdes på 1980-talet för ett litet, slutet forskarnätverk. Protokollet som skickar mejl, SMTP, har inget inbyggt sätt att verifiera att avsändaren i "Från"-fältet verkligen skickade meddelandet. Det funkar som vanlig post: du kan skriva vilken avsändaradress du vill på kuvertet.

När du skickar ett mejl ansluter din klient till en SMTP-server och anger två saker: kuvertavsändaren (den faktiska routingadressen) och meddelandehuvudena (det mottagaren ser, inklusive "Från"-raden). De två värdena behöver inte matcha. Inget i protokollet kräver det.

En angripare kan alltså ansluta till vilken SMTP-server som helst och skicka ett meddelande med din domän i From-fältet. Mottagarens mejlklient visar det som skickat från dig. Om mottagaren inte granskar de råa meddelandehuvudena (och det gör nästan ingen) går det inte att se skillnaden.

Så här kan ett spoofat e-postmeddelande se ut i praktiken:

Från: anders.berg@advokatfirman.se
Till: maria.nilsson@klientforetag.se
Ämne: Uppdaterade bankuppgifter — brådskande

Hej Maria,

Bankuppgifterna för den slutliga förlikningen har ändrats på grund av
en intern omstrukturering. Vänligen använd följande konto för
överföringen som ska vara klar på fredag:

IBAN: DE89 3704 0044 0532 0130 00
BIC: COBADEFFXXX

Bekräfta gärna när överföringen är genomförd.

Med vänlig hälsning,
Anders Berg
Delägare, Berg & Partners Advokatbyrå

Maria ser ett meddelande från sin advokats exakta mejladress. Det refererar till en riktig transaktion. Språket är professionellt och korrekt. Hon genomför överföringen. Pengarna hamnar på angriparens konto i ett annat land. När bedrägeriet upptäcks är pengarna borta.

Det här är inte ett påhittat scenario. Det är standard-BEC. Det fungerar för att utan SPF, DKIM och DMARC finns det ingenting som säger åt Marias mejlserver att avvisa eller flagga meddelandet.

SPF: Vem får skicka å dina vägnar

SPF (Sender Policy Framework) är det första lagret av e-postautentisering. Det svarar på en enkel fråga: vilka servrar får skicka mejl från din domän?

Du lägger in en SPF-post som en TXT-post i din domäns DNS. När en mottagande mejlserver får ett meddelande som påstår sig komma från din domän slår den upp din SPF-post och kollar om avsändarens IP-adress finns på den godkända listan. Finns den inte där vet servern att något är fel.

En grundläggande SPF-post ser ut så här:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all

Så här tolkas varje del:

v=spf1 deklarerar att det här är en SPF-post (version 1). Alla SPF-poster börjar med detta.

include:_spf.google.com godkänner Google Workspaces mejlservrar. "include" säger åt mottagaren att även kolla Googles SPF-post för godkända IP-adresser.

include:sendgrid.net godkänner SendGrid för transaktionsmejl. Varje tredjepartstjänst som skickar mejl å dina vägnar behöver sin egen include.

ip4:203.0.113.50 godkänner en specifik IP-adress, till exempel din egen mejlserver.

-all är verkställighetsmekanismen. Den viktigaste delen. Den säger åt mottagande servrar att avvisa all mejl från servrar som inte listas ovan.

Vanliga SPF-misstag att undvika:

För många DNS-uppslag. SPF har en hård gräns på 10 DNS-uppslag per post. Varje "include", "a" och "mx"-mekanism kostar ett uppslag, och nästlade includes räknas också. Överskrider du 10 kraschar hela SPF-kontrollen med "permerror" och din mejl tappar autentisering. Det här är det vanligaste SPF-felet vi ser i våra skanningar. Kör du Google Workspace, Microsoft 365, ett CRM, en marknadsföringsplattform och en transaktionsmejltjänst når du gränsen snabbt. Lösningen är att platta till din SPF-post, det vill säga upplösa includes till deras faktiska IP-intervall, eller använda en SPF-flattening-tjänst.

Flera SPF-poster. En domän får bara ha en SPF TXT-post. Har du två (vanligt när olika avdelningar lägger till poster på egen hand) blir båda ogiltiga enligt RFC. Slå ihop dem till en enda post.

Bortglömda tredjepartsavsändare. Varje tjänst som skickar mejl som din domän måste finnas i SPF-posten. CRM, helpdesk, nyhetsbrev, transaktionsmejl, till och med bokföringsprogrammet om det skickar fakturor. Gå igenom alla tjänster som använder din domän i From-adressen.

SPF räcker inte ensamt. SPF kollar bara kuvertavsändaren (Return-Path), inte From-fältet som människor ser. En angripare kan använda sin egen domän som kuvertavsändare och passera SPF, men samtidigt förfalska din domän i det synliga From-fältet. Därför behöver du DKIM och DMARC för att täppa till hålet.

DKIM: Digitala signaturer för e-post

DKIM (DomainKeys Identified Mail) lägger till en kryptografisk signatur på varje utgående mejl. Den bevisar två saker: att mejlet faktiskt kom från din domän, och att det inte ändrades på vägen.

Det funkar med asymmetrisk kryptering. Din mejlserver har en privat nyckel som signerar utgående meddelanden. Den matchande publika nyckeln publiceras som en DNS TXT-post. När mottagarens server tar emot ditt mejl hämtar den den publika nyckeln från DNS och verifierar signaturen. Stämmer den är mejlet äkta. Annars har något ändrats.

DKIM-signaturen läggs till som ett huvud i mejlet. Den ser ut så här:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=dindomän.se; s=google;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk2yFUGCVEGHFY
   OKYHGOHkgmjfaliLIvKOewNhP3IfEGD...

De viktigaste delarna:

d=dindomän.se är domänen som äger signeringsnyckeln.

s=google är selectorn, en etikett som identifierar vilket nyckelpar som används. En domän kan ha flera selectors (t.ex. en för Google Workspace, en annan för SendGrid). Den publika nyckeln finns på google._domainkey.dindomän.se.

h=from:to:subject:date:message-id listar de huvuden som ingår i signaturen. Ändras något av dessa efter signering misslyckas verifieringen.

b= är den faktiska kryptografiska signaturen.

bh= är en hash av mejlets brödtext. Säkerställer att innehållet inte har ändrats.

DNS-posten för den publika nyckeln ser ut så här:

google._domainkey.dindomän.se  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Konfigurera DKIM: De flesta mejlleverantörer sköter signeringen automatiskt. I Google Workspace genererar du DKIM-nyckeln i adminpanelen och lägger till TXT-posten i din DNS. I Microsoft 365 aktiverar du DKIM-signering i Exchange-admincentret och publicerar två CNAME-poster. Tredjepartstjänster som SendGrid, Mailchimp och Postmark har egna DKIM-guider, vanligtvis en eller två DNS-poster att lägga till.

Så verifierar du att DKIM funkar: Skicka ett testmejl till en extern adress (Gmail funkar bra) och visa de ursprungliga meddelandehuvudena. Leta efter dkim=pass i Authentication-Results-huvudet. Du kan också kolla din DKIM DNS-post direkt:

dig TXT google._domainkey.dindomän.se

Om detta returnerar en post med v=DKIM1 och ett p=-värde med din publika nyckel är DKIM publicerad. Om det returneras tomt saknas posten eller så är selectorn fel.

Nyckelrotation. DKIM-nycklar bör roteras regelbundet, minst en gång per år. Generera ett nytt nyckelpar, publicera den nya publika nyckeln med en ny selector, konfigurera din mejlserver att signera med den nya nyckeln och ta efter en övergångsperiod bort den gamla från DNS. De flesta hanterade mejltjänster sköter det automatiskt.

DMARC: Policylagret

SPF och DKIM löser var sin del av problemet. SPF verifierar avsändarservern. DKIM verifierar meddelandets integritet. Men ingen av dem talar om för mottagarens server vad den ska göra när verifieringen misslyckas. Och ingen av dem kollar om domänen i det synliga From-fältet matchar den autentiserade domänen.

DMARC (Domain-based Message Authentication, Reporting & Conformance) täpper till båda hålen. Den gör tre saker:

1. Alignment. DMARC kollar att domänen i From-fältet (det människor ser) matchar antingen SPF-domänen eller DKIM-domänen. Det stänger kryphålet där en angripare passerar SPF med sin egen domän men spoofar din i det synliga From-fältet.

2. Policy. DMARC låter dig bestämma vad mottagande servrar ska göra med mejl som inte klarar autentiseringen. Tre alternativ:

p=none        →  Gör ingenting. Leverera normalt. Skicka bara rapporter.
p=quarantine  →  Markera felaktiga e-postmeddelanden som misstänkta. Skicka dem till skräppost.
p=reject      →  Blockera felaktiga e-postmeddelanden helt. Leverera dem inte.

3. Rapportering. DMARC genererar rapporter som visar exakt vad som händer med mejl skickade från din domän. Det finns två typer:

Aggregerade rapporter (rua) är dagliga XML-sammanfattningar från mottagande servrar. De visar hur många meddelanden som passerade eller misslyckades med SPF, DKIM och DMARC alignment. Du får helhetsbilden: vilka IP-adresser skickar som din domän, hur många passerar och hur många misslyckas.

Forensiska rapporter (ruf) är felrapporter per meddelande med detaljer om enskilda mejl som misslyckades med DMARC. Alla leverantörer skickar inte dessa av integritetsskäl, men när de finns är de ovärderliga för felsökning.

En DMARC-post publiceras som en TXT-post på _dmarc.dindomän.se. Här är en typisk progression:

Startpunkt, bara övervakning:

_dmarc.dindomän.se  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rapporter@dindomän.se; ruf=mailto:dmarc-forensik@dindomän.se; pct=100"

Mellansteg, karantän för misstänkta mejl:

_dmarc.dindomän.se  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rapporter@dindomän.se; pct=100"

Full verkställighet, avvisa spoofade meddelanden:

_dmarc.dindomän.se  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-rapporter@dindomän.se; pct=100"

Varför de flesta stannar vid p=none. I vår granskning av 597 byråer hade majoriteten som ens hade en DMARC-post fastnat på p=none. De satte upp DMARC men verkställde det aldrig. En p=none-policy säger till mottagande servrar "gör vad du vill med felaktiga meddelanden", vilket i praktiken är samma sak som att inte ha DMARC alls. Enda fördelen är rapporterna. Har du legat på p=none i mer än några veckor utan att aktivt granska rapporter och röra dig mot verkställighet? Då ger DMARC dig noll skydd.

BEC: Hotet från Business Email Compromise

Business Email Compromise är en riktad social engineering-attack. Brottslingar utger sig för att vara en betrodd person, oftast en VD, advokat, revisor eller affärspartner, för att lura någon att överföra pengar eller lämna ut känsliga uppgifter. Till skillnad från vanligt nätfiske som skickar brett är BEC-attacker researchade, personaliserade och tålmodiga.

En typisk BEC-attack följer det här mönstret:

Rekognosering. Angriparen undersöker målorganisationen. LinkedIn visar vilka som jobbar där, deras titlar och vem de rapporterar till. Hemsidan listar nyckelpersoner. Rättshandlingar och pressmeddelanden avslöjar pågående affärer. För advokatbyråer är den här informationen särskilt lättillgänglig.

Infrastruktur. Angriparen komprometterar antingen ett legitimt mejlkonto (kontoövertagande) eller sätter upp spoofing-infrastruktur. Saknar måldomänen DMARC-verkställighet är spoofing trivialt enkelt. Ingen kontoövertagning behövs.

Attacken. Ett noggrant utformat mejl anländer vid exakt rätt tillfälle. Det refererar till riktiga personer, riktiga affärer, riktiga deadlines. Det ber om något som verkar rutinmässigt: uppdaterade bankuppgifter, en överföring, ett dokument med personuppgifter. Brådskan och specificiteten gör det övertygande.

Uttag. Pengarna överförs till bulvankonton och flyttas snabbt utomlands. Känsliga uppgifter exfiltreras. När bedrägeriet upptäcks är det sällan möjligt att få tillbaka något.

Varför advokatbyråer och finanssektorn är särskilt utsatta:

Advokatbyråer hanterar stora banköverföringar rutinmässigt. En begäran om att ändra betalningsuppgifter för en förlikning väcker inte omedelbar misstanke. Byråer sitter dessutom på privilegierad information: detaljer om företagsförvärv, immateriella rättigheter, personuppgifter från rättsprocesser. Allt kan utnyttjas eller säljas. Och klienter tenderar att lita på och agera efter kommunikation från sin advokat utan att ifrågasätta.

De regulatoriska konsekvenserna är verkliga. Enligt GDPR utlöser ett dataintrång orsakat av en BEC-attack anmälningsskyldighet enligt artikel 33 (till tillsynsmyndigheten inom 72 timmar) och potentiellt artikel 34 (till berörda individer). IMY har redan utfärdat sanktionsavgifter för otillräckliga tekniska skyddsåtgärder. NIS2-direktivet höjer ribban ytterligare och kräver "lämpliga och proportionerliga tekniska åtgärder" för enheter inom tillämpningsområdet. Det inkluderar i allt högre grad juridiska och finansiella tjänster.

Under 2024 rapporterade Europeiska dataskyddsstyrelsen en kraftig ökning av tillsynsåtgärder kopplade till bristande mejlsäkerhet. Flera nationella myndigheter utfärdade böter där saknad e-postautentisering pekades ut som en bidragande faktor. Budskapet är tydligt: skydd mot e-postspoofing är inte längre valfritt. Det är en grundläggande förväntning.

Så kontrollerar du din e-postsäkerhet nu

Du kan kolla din e-postautentisering på under fem minuter. Här är tre metoder, från enklast till mest grundlig.

Metod 1: Kör en SVAR-skanning. Vår kostnadsfria säkerhetsskanning kollar SPF, DKIM och DMARC som del av en 16-dimensionell säkerhetsbedömning. Ange din domän, vänta två minuter och få en tydlig uppdelning av vad som funkar, vad som saknas och vad som är felkonfigurerat. Ingen registrering krävs.

Metod 2: Kommandoraden. Vill du kolla manuellt kan du använda dig eller nslookup för att fråga din DNS direkt.

Kontrollera SPF:

dig TXT dindomän.se | grep spf

# Bra resultat:
"v=spf1 include:_spf.google.com -all"

# Dåligt resultat:
(tomt — ingen SPF-post finns)

Kontrollera DMARC:

dig TXT _dmarc.dindomän.se

# Bra resultat:
"v=DMARC1; p=reject; rua=mailto:dmarc@dindomän.se; pct=100"

# Svagt resultat:
"v=DMARC1; p=none;"

# Dåligt resultat:
(tomt — ingen DMARC-post finns)

Kontrollera DKIM:

dig TXT google._domainkey.dindomän.se

# Bra resultat:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

# Dåligt resultat:
(tomt — DKIM inte konfigurerat för denna selector)

OBS: för DKIM behöver du veta selectorns namn. Vanliga selectors: google för Google Workspace, selector1 och selector2 för Microsoft 365, och tjänstspecifika selectors för verktyg som SendGrid (s1, s2) eller Mailchimp (k1).

Metod 3: Skicka ett testmejl. Skicka ett mejl från din domän till en Gmail-adress. Öppna meddelandet i Gmail, klicka på de tre punkterna och välj "Visa original." Titta på Authentication-Results-huvudet:

Authentication-Results: mx.google.com;
  dkim=pass header.d=dindomän.se;
  spf=pass (google.com: domain of user@dindomän.se designates 203.0.113.50 as permitted sender);
  dmarc=pass (p=REJECT) header.from=dindomän.se

Du vill se pass för alla tre. Visar något fail, softfail eller none är det en lucka som behöver åtgärdas.

Uppsättningen: Enklare än du tror

Folk överkomplicerar det här. Själva jobbet tar en dag. Du listar dina mejlavsändare, lägger till DNS-poster och börjar övervaka. Se vår guide om grunderna i säkerhetskonfiguration för den bredare bilden.

Steg 1: Lista alla tjänster som skickar mejl som din domän

Det här är steget de flesta hoppar över, och det enda som verkligen spelar roll. Skriv ner varje system som använder din domän i From-adressen. Din mejlleverantör (Google Workspace, Microsoft 365), CRM, helpdesk, marknadsföringsverktyg, transaktionsmejl, faktureringsystem. Fråga runt. Kolla befintliga SPF-poster om du har några. Titta på mejlhuvuden från olika tjänster.

Steg 2: Lägg till DNS-posterna

Med listan klar konfigurerar du allt tre i en sittning. SPF först, sedan DKIM för varje tjänst, sedan DMARC.

För SPF, lägg till en TXT-post med include: för varje tredjepartstjänst och ip4: för servrar du hanterar själv. Börja med ~all (soft fail) tills du verifierat att inget saknas. Håll totala DNS-uppslag på 10 eller färre.

# Exempel på SPF-post:
v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com ~all

# När du verifierat, byt till hard fail:
v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com -all

För DKIM, aktivera signering i varje tjänsts adminpanel och publicera DNS-posterna de ger dig. De flesta leverantörer gör det till en toggle plus en DNS-post. Skicka testmejl och kolla headers efter dkim=pass.

För DMARC, publicera en TXT-post på _dmarc.dindomän.se med p=none för att samla rapporter utan att blockera något:

_dmarc.dindomän.se  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rapporter@dindomän.se; pct=100"

Sätt upp en gratis DMARC-rapportparser (DMARC Analyzer, Postmarks verktyg, eller en open source-variant) så du faktiskt kan läsa XML-rapporterna som börjar komma in.

Steg 3: Övervaka några dagar, sedan verkställ

Kolla rapporterna i några dagar. Du letar efter två saker: legitima tjänster som misslyckas (fixa deras SPF/DKIM-konfiguration) och obehöriga avsändare du kan blockera. När din legitima mejl konsekvent passerar, flytta till quarantine:

_dmarc.dindomän.se  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rapporter@dindomän.se; pct=100"

Ser allt bra ut efter ett par dagar till, byt till full reject:

_dmarc.dindomän.se  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-rapporter@dindomän.se; pct=100"

Klart. Din domän kan inte spoofas längre.