För ett svenskt företag är e-postdomänen en del av identiteten, inte bara en teknisk adress. Kundtjänst, fakturor, lönebesked, bokningsbekräftelser och nyhetsbrev kan använda samma eller närliggande domäner. När en angripare skickar ett meddelande som ser ut att komma från företaget drabbas därför både mottagaren och avsändarens förtroende. SPF, DKIM och DMARC ger ett gemensamt sätt att visa vilka system som får skicka, att meddelandet inte ändrats på vägen och vad mottagaren bör göra när kontrollen misslyckas.
Den vanligaste missen är att publicera en policy utan att först förstå den egna avsändarbilden. Ett svenskt bolag kan ha Microsoft 365 eller Google Workspace för personalen, en separat fakturatjänst, ett CRM, ett rekryteringssystem, en kundundersökning och en äldre SMTP-tjänst som ingen längre äger. Var och en kan använda olika domäner, subdomäner eller DKIM-väljare. En bra process börjar med inventering och ägarskap, inte med att kopiera en DNS-post från ett blogginlägg.
Förstå vad varje kontroll faktiskt gör
SPF är en publicerad policy för vilka servrar som får sända för en domäns räkning. Mottagaren läser DNS-posten och jämför avsändarserverns IP eller ett inkluderat regelverk med posten. SPF gäller den tekniska envelope-from-identiteten, inte alltid adressen som en person ser i fältet From. Därför kan en godkänd SPF-kontroll fortfarande lämna utrymme för synlig avsändarförfalskning om DKIM och DMARC saknas.
DKIM lägger en digital signatur i meddelandet. Mottagaren hämtar den publika nyckeln från en selector i DNS och kan kontrollera att utvalda delar av meddelandet inte har ändrats samt att en godkänd sändare signerat det. DKIM eliminerar inte spam och bevisar inte att en leverantör är seriös. Det ger däremot en stabil teknisk identitet när meddelanden vidarebefordras och SPF:s envelope-from-information förändras.
DMARC kopplar ihop synlig From-adress med SPF eller DKIM genom alignment och talar om vad mottagaren kan göra när kontrollen misslyckas. Policyn kan börja med p=none och rapportering, gå vidare till quarantine och till sist reject när legitim trafik är känd. Rapportering är ett beslutsunderlag, inte en perfekt logg. Vissa rapporter är aggregerade, vissa system skickar inte rapporter och en leverantör kan använda flera sändningsvägar som är svåra att tolka utan intern information.
Börja med en svensk avsändarinventering
Lista alla domäner och subdomäner som kan synas i e-post. Ta med huvuddomänen, en supportdomän, marknadsföringsdomäner, transaktionsdomäner och äldre domäner som fortfarande vidarebefordrar. För varje namn anger du affärsägare, teknisk ägare, användning, kritikalitet, leverantör, DKIM-selector, SPF-källa, DMARC-policy och planerat slutdatum. En post utan ägare är inte en neutral detalj. Den kan vara en glömd avsändare eller en risk som ingen tar ansvar för.
- Fakturor och betalningskvitton, med ansvar hos ekonomi och systemförvaltning.
- Kundservice och driftmeddelanden, med ansvar hos support eller produkt.
- Nyhetsbrev och kampanjer, med ansvar hos marknad och dataskydd.
- Rekrytering, enkäter och bokningar, med ansvar hos HR eller respektive verksamhet.
- Test-, utvecklings- och gamla kampanjdomäner, med tydlig beslutspunkt för avveckling.
- Underleverantörer som skickar med företagets synliga From-adress och behöver DKIM-alignment.
Jämför sedan inventeringen med SPF- och DMARC-resultat. En DNS-kontroll visar vad som är publicerat just nu, medan DMARC-rapporter kan visa att verkliga mottagare sett en källa som ingen nämnde i mötet. Skillnaderna ska utredas, inte automatiskt läggas till i SPF. Fråga vem som initierar utskicket, vilken synlig From-adress som används, om leverantören stöder DKIM och om avtalet tillåter avsändning från företagets domän.
Bygg SPF utan att skapa en ny begränsning
SPF-posten måste vara syntaktiskt korrekt, ha en tydlig avslutande policy och hållas begriplig över tid. Varje include kan ge fler DNS-uppslag, och SPF har en gräns för hur många sådana mekanismer som får utvärderas. Många hopkopplade leverantörer kan därför göra att en post som såg bra ut i testmiljön börjar ge PermError i produktion. Dokumentera varför varje include finns, vem som äger den och när den ska tas bort.
Undvik att använda alltför breda IP-intervall eller en generell tillåtelse för alla servrar. Det kan göra policyn enkel att skriva men svår att försvara vid en incident. Ändra i en kontrollerad ordning, sänk inte TTL precis före en kritisk kampanj utan plan, och kontrollera att den auktoritativa DNS-zonen är den som verksamheten faktiskt använder. En lokal ändring i fel zon är en vanlig orsak till att ett team tror att SPF är klart när mottagare ser något annat.
Gör DKIM till en ägarfråga
Be varje avsändartjänst att visa vilken selector den använder och vilken domän som signeras. Kontrollera den publika nyckeln, nyckellängd enligt leverantörens dokumentation och om signaturen alignar med den synliga From-domänen. Använd separata selectors när det förenklar rotation och återkallelse. En selector som lever kvar efter ett avslutat avtal kan ge onödig exponering, medan en förhastad radering kan bryta en tjänst som fortfarande används av en verksamhet.
Testa både nya och vidarebefordrade meddelanden. En intern leverans kan gå igenom medan en extern mottagare ändrar ämnesrad eller fotnot och gör DKIM ogiltig. Det är mottagarens autentiseringsresultat och den slutliga meddelandestrukturen som är intressant. Be om ett konkret test från en svensk kund- eller supportadress och spara headers med tidsstämpel, utan att lägga känsliga personuppgifter i ärendet.
Rulla ut DMARC med mätbara steg
Publicera först en policy som samlar aggregerade rapporter till en övervakad adress eller rapporttjänst. Definiera i förväg hur länge observationsfasen pågår och vilka trösklar som kräver åtgärd. Titta efter volym, källor, SPF-resultat, DKIM-resultat och alignment. En stor okänd källa behöver inte vara ett angrepp, men den behöver en ägare och en förklaring. En liten volym kan ändå vara viktig om den rör fakturor eller återställning av konto.
När legitim trafik är identifierad kan du införa policy per subdomän eller gradvis påverkan där standarden och verksamhetens riskbedömning tillåter det. Använd quarantine eller reject först när de mest kritiska flödena är testade. Var försiktig med procentbaserad tillämpning: den kan hjälpa vid en stegvis start men gör också att två likadana meddelanden får olika resultat under övergången. Dokumentera varför en nivå valdes och när den ska omprövas.
- Inventera domäner, avsändare, ägare och kritiska flöden.
- Kontrollera SPF-syntax, uppslagsgräns och minimala tillåtna källor.
- Aktivera DKIM hos varje legitim tjänst och testa alignment.
- Publicera DMARC-rapportering och analysera verklig trafik.
- Åtgärda okända och trasiga avsändare med respektive systemägare.
- Inför en skärpt policy i etapper och återtesta efter varje förändring.
- Lägg en återkommande kvartalskontroll i ordinarie domänförvaltning.
Hantera leverantörer och undantag
Svenska företag använder ofta byråer och SaaS-tjänster som startas av enskilda team. Sätt därför en enkel regel i inköps- och onboardingprocessen: ingen extern tjänst får skicka med företagets synliga From-adress innan den har en dokumenterad ägare, DKIM-plan och testadress. Ett undantag ska ha slutdatum. Om tjänsten inte stöder DKIM kan en separat sändningsdomän vara säkrare än att sänka skyddet för huvuddomänen.
När en tjänst avslutas tar du bort DNS-poster enligt en återkallningsplan och söker efter kvarvarande selectors, SPF-includes och omdirigeringar. Spara rapporter som visar att volymen försvunnit. Att bara radera ett konto hos leverantören räcker inte alltid, eftersom gamla DNS-poster kan ligga kvar och framtida ägare kan återanvända samma tjänst eller subdomän. Granska också om gamla utskick finns i arkiv eller integrationer som fortfarande kan triggas.
Koppla tekniken till incidentberedskap
Vid misstänkt domänförfalskning behöver organisationen kunna svara på tre frågor: vilken domän och From-adress missbrukas, syns meddelandet i DMARC-data och vilken mottagaråtgärd vill ni att andra ska ta? Förbered kontaktvägar mellan säkerhet, drift, kommunikation, kundservice och juridik. DMARC stoppar inte alla sociala bedrägerier, men en tydlig policy kan minska hur lätt en mottagare accepterar uppenbart obehörig sändning.
Mät inte bara hur många domäner som har en DMARC-post. Mät andelen legitim volym som klarar alignment, antalet okända källor med ägare, tiden från ny leverantör till godkänd DKIM och antalet policyändringar som krävt återställning. En låg andel reject kan vara helt rimlig under en migrering. En hög andel reject utan fungerande rapportering kan däremot dölja ett leveransproblem.
En praktisk beslutsmall
För varje domän kan du använda ett kort beslutskort: syfte, ägare, kritiska flöden, SPF-status, DKIM-status, DMARC-policy, rapportmottagare, öppna undantag, nästa testdatum och ansvarig godkännare. Lägg till ett exempel på ett legitimt meddelande och ett förväntat resultat. Det gör att nästa förändring kan verifieras utan att en person behöver minnas hela historien.
Det viktigaste är att behandla e-postautentisering som en löpande domänprocess. Börja med synlighet, ta bort okända vägar, säkra legitima sändare och skärp policyn när data stöder beslutet. Med en tydlig inventering och återkommande kontroll får svenska företag bättre motståndskraft mot domänförfalskning utan att skapa en onödig driftstörning för kunder och medarbetare.
Gör en sista leveranskontroll efter varje ändring: skicka ett test till en extern brevlåda, läs autentiseringsresultaten i headers, kontrollera mottagarens spamklassning och följ rapporteringen under minst en normal arbetscykel. Testa även faktura, lösenordsåterställning och nyhetsbrev om dessa flöden finns. En ändring är klar först när både tekniska resultat och verksamhetens mottagare fungerar som planerat.
Anpassa processen till svenska mottagare
Testa inte bara ett internt meddelande mellan två konton i samma miljö. Skicka representativa test till privata och företagsadresser hos olika mottagare, utan kunddata, och kontrollera headers och slutlig placering. Ett svenskt nyhetsbrev kan passera den egna testbrevlådan men få annan behandling hos en kommun, bank eller kunds e-postsystem. Dokumentera vilket flöde som testades, avsändardomän, selector och förväntat alignment-resultat.
Bygg en enkel förändringsmatris för leverantörer. För varje tjänst anges om den stöder DKIM, vilken synlig From-adress som används, om SPF behövs, vem som får ändra DNS och hur snabbt tjänsten kan återställas. När en leverantör inte kan svara ska den inte automatiskt få ett undantag på huvuddomänen. En separat subdomän eller en intern relay kan vara en säkrare affärslösning, men beslutet ska fattas av ansvarig arkitekt och verksamhetsägare.
Gå igenom rapporterna efter en löneperiod, fakturakörning och kampanj, inte bara efter en lugn testdag. Säsongsflöden och kvartalsvisa utskick är vanliga orsaker till att legitima sändare upptäcks sent. Lägg därför in viktiga kalenderhändelser i observationsplanen. Det gör övergången till reject mer förutsägbar och minskar risken att en sällan använd men kritisk avsändare blockeras.