SPF, DKIM och DMARC: så skyddar ni er domän mot nätfiske

E-post byggdes för en tid då alla som var uppkopplade litade på varandra. Protokollet har ingen inbyggd kontroll av vem som är avsändare, och utan extra skydd kan vem som helst skicka ett mejl som ser ut att komma från [email protected].

Det utnyttjas varje dag. Falska fakturor, mejl från ”VD:n” som ber ekonomiavdelningen göra en brådskande betalning och meddelanden om ändrade bankuppgifter är vardag för svenska företag. Polisen har en egen sida om hur företag ska agera vid fakturabedrägerier, och ett förfalskat avsändarnamn gör bluffen betydligt mer trovärdig.

Tre tekniska standarder – SPF, DKIM och DMARC – gör det möjligt för mottagande e-postservrar att avslöja mejl som utger sig för att komma från er domän. Dessutom är de numera ett krav för att era egna mejl ska komma fram till stora e-postleverantörer. Så här fungerar de och så inför ni dem.

Varför går det att förfalska en avsändare?

Ett mejl har i praktiken två avsändaradresser. Den ena används av servrarna under själva överföringen (”envelope from” eller Return-Path). Den andra är den som syns i mejlprogrammet (From). De behöver inte vara samma, och ingen av dem kontrolleras i grundprotokollet. Det är därför det krävs tre kompletterande standarder.

SPF – vilka servrar får skicka?

SPF (Sender Policy Framework) är en TXT-post i DNS som listar vilka servrar och tjänster som får skicka e-post för domänen. Ett företag med Microsoft 365 och ett nyhetsbrevsverktyg kan ha en post som ser ut så här (include-värdet för nyhetsbrevet är ett exempel – varje tjänst anger sitt eget):

ert-foretag.se.  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.exempel-nyhetsbrev.se -all"

-all på slutet betyder att alla andra servrar ska underkännas. ~all (”soft fail”) är ett mjukare alternativ som ofta används under införandet.

Tre saker att veta om SPF:

• Bara en SPF-post per domän. Två poster ger fel och gör att SPF slutar fungera helt.
• Max tio DNS-uppslag. Enligt RFC 7208 får en SPF-kontroll göra högst tio uppslag via include, a, mx, exists och redirect. Varje include kan i sin tur innehålla flera. Går ni över gränsen blir resultatet ett fel. Det händer lätt när företaget har många molntjänster.
• SPF kontrollerar inte den adress mottagaren ser, bara den tekniska avsändaradressen. Och SPF går ofta sönder när mejl vidarebefordras. Därför räcker inte SPF ensamt.

DKIM – en digital signatur på varje mejl

DKIM (DomainKeys Identified Mail) signerar varje utgående mejl med en privat nyckel. Den publika nyckeln publiceras i DNS under ett så kallat selektornamn, till exempel selector1._domainkey.ert-foretag.se. Mottagaren hämtar nyckeln och kontrollerar att signaturen stämmer – och därmed att mejlet verkligen skickats av någon med tillgång till nyckeln och inte ändrats på vägen.

I praktiken aktiverar ni DKIM i varje tjänst som skickar e-post åt er – Microsoft 365, Google Workspace, nyhetsbrevsverktyget, ekonomisystemet – och lägger in de DNS-poster tjänsten anger. Varje tjänst får sin egen selektor.

Använd nycklar på minst 2048 bitar där det stöds; Google kräver minst 1024 och rekommenderar 2048. DKIM överlever för det mesta vidarebefordran, vilket gör det till den viktigaste av de två teknikerna för DMARC.

DMARC – knyter ihop allt och bestämmer vad som händer

DMARC (Domain-based Message Authentication, Reporting and Conformance) löser problemet med att SPF och DKIM inte tittar på den adress mottagaren ser. Ett mejl godkänns av DMARC om det klarar SPF eller DKIM och den domänen stämmer överens med domänen i From-adressen. Det kallas alignment.

DMARC-posten publiceras som en TXT-post på _dmarc.ert-foretag.se:

_dmarc.ert-foretag.se.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p är policyn: none (bara rapportera), quarantine (lägg i skräpposten) eller reject (avvisa).
• rua är adressen dit mottagande e-postservrar skickar sammanställda rapporter, ofta en gång per dygn. Rapporterna är XML-filer, så använd ett verktyg som sammanställer dem.
• sp anger en separat policy för underdomäner.

DMARC är nu en riktig standard

DMARC beskrevs länge bara i ett informativt dokument, RFC 7489 från 2015. I maj 2026 publicerade IETF RFC 9989, som gör DMARC till en standard och ersätter den gamla specifikationen. För de flesta företag är förändringen liten – befintliga v=DMARC1-poster fortsätter att fungera – men några detaljer är bra att känna till:

• Taggen pct, som användes för att tillämpa policyn på en andel av mejlen, finns inte längre i standarden. I stället finns t=y för att signalera att policyn testas.
• Den nya taggen np anger policy för underdomäner som inte finns, ett vanligt sätt att förfalska avsändare som faktura.ert-foretag.se.
• Mottagarna hittar organisationens DMARC-post genom att gå uppåt i DNS-trädet i stället för att använda en extern lista över toppdomäner.

Gmail, Yahoo och Microsoft kräver det

Sedan den 1 februari 2024 ställer Google krav på alla som skickar till Gmail-adresser. Alla avsändare måste ha SPF eller DKIM, korrekta DNS-poster för servern och krypterad överföring. Den som skickar mer än 5 000 mejl per dag till Gmail måste dessutom ha SPF, DKIM och DMARC (minst p=none), alignment med From-adressen och avregistrering med ett klick för marknadsutskick. Yahoo införde motsvarande krav samtidigt.

Microsoft följde efter: sedan den 5 maj 2025 gäller liknande krav för Outlook.com för domäner som skickar fler än 5 000 mejl per dag.

Även om ni skickar färre mejl än så påverkar det er. Mottagare bedömer ofta oautentiserade mejl som mindre pålitliga, och era offerter och fakturor riskerar att hamna i skräpposten.

Steg för steg: från noll till p=reject

1. Inventera alla som skickar e-post i ert namn. Det är det viktigaste och mest förbisedda steget. Utöver e-postsystemet: nyhetsbrev, CRM, ekonomi- och faktureringssystem, e-handelsplattform, bokningssystem, webbformulär på sajten och skrivare som skickar inskannade dokument.
2. Skapa eller städa SPF-posten. En post, alla legitima tjänster, under tio uppslag. Börja med ~all om ni är osäkra.
3. Aktivera DKIM i varje tjänst och lägg in deras DNS-poster. Kontrollera att signaturen görs med er domän och inte med tjänstens egen – annars blir det ingen alignment.
4. Publicera DMARC med p=none och en rapportadress som någon faktiskt läser eller ett verktyg som tolkar rapporterna.
5. Analysera rapporterna i två till fyra veckor. Ni kommer nästan säkert att hitta tjänster ni glömt. Rätta dem.
6. Skärp till p=quarantine, följ rapporterna ett par veckor till och gå sedan till p=reject. Först då skyddar DMARC på riktigt.
7. Skydda domäner som inte skickar e-post. Gamla varumärken, parkerade domäner och .com-varianten av ert namn ska ha v=spf1 -all och v=DMARC1; p=reject; – annars är de fria att använda för bedragare.

Vanliga misstag

• Två SPF-poster, till exempel när en ny tjänst lagts till av någon som inte såg att det redan fanns en.
• För många uppslag i SPF, som gör att SPF ger fel för alla mejl.
• Faktureringssystemet glömdes bort, och fakturorna började hamna i kundernas skräppost när policyn skärptes.
• p=none för evigt. Många inför DMARC för att uppfylla Googles krav och stannar där. Det ger rapporter, men inget skydd.
• Rapporter som ingen läser. Utan analys vet ni inte när något slutar fungera eller när någon försöker förfalska er domän.

Tekniken räcker inte hela vägen

DMARC stoppar mejl som påstår sig komma från er exakta domän. Det stoppar inte en bedragare som registrerar en liknande domän, som ert-foretaq.se, eller som använder ett gratiskonto med ert företagsnamn som visningsnamn. Därför behövs också rutiner: ändrade bankuppgifter bekräftas alltid per telefon på ett nummer ni redan har, och större betalningar godkänns av två personer.

Vill ni gå längre finns MTA-STS, som tvingar fram krypterad överföring till era e-postservrar, och BIMI, som visar er logotyp i vissa mejlprogram men kräver att DMARC redan är i quarantine eller reject.

Kontrollera er domän

I en terminal kan ni se era poster med dig TXT ert-foretag.se och dig TXT _dmarc.ert-foretag.se. Enklare är att köra Secvras gratis säkerhetsskanning, som kontrollerar SPF och DMARC för domänen samtidigt som TLS, säkerhetsheaders och programversioner.

Hittar ni brister men saknar tid eller kunskap att rätta dem hjälper vi gärna till – det brukar vara klart på några veckor, inklusive analysen av rapporterna. Boka ett kort samtal eller se våra fasta priser. Omfattas ni av cybersäkerhetslagen är skydd av e-posten dessutom en naturlig del av den grundläggande cyberhygien lagen kräver.

Källor

• IETF: RFC 7208 – SPF, RFC 6376 – DKIM och RFC 9989 – DMARC
• Google: Riktlinjer för e-postavsändare
• Microsoft: Strengthening Email Security: Outlook's New Requirements for High-Volume Senders
• Polisen: Fakturabedrägeri