DMARC, SPF, DKIM: 72% Oskyddade, Fixa i 16 Steg [2026]

72,4 procent av svenska domäner saknar fortfarande ett effektivt DMARC-skydd, enligt siffror från den 18 oktober 2026. Samtidigt kräver Gmail, Yahoo och Microsoft numera att alla som skickar mer än 5 000 mejl per dag autentiserar sig med SPF, DKIM och DMARC, annars studsar mejlen rakt tillbaka. Den här guiden visar precis hur du bygger upp skyddet från grunden: från den första DNS-posten till ett fullt enforced p=reject-läge, med konkreta kodexempel, en felsökningslista och ett eget litet övervakningsskript du kan köra på egen hand.

Du behöver inte vara DNS-expert för att följa stegen. Det som krävs är adminbehörighet till din DNS-zon, åtkomst till din e-postleverantörs adminpanel och cirka 90 minuter ostörd tid utspridd över de första dagarna. Vi går igenom varje steg i ordning, pekar ut de vanligaste fallgroparna och visar hur du läser de rapporter som DMARC faktiskt genererar åt dig, innan vi avslutar med ett eget litet Node.js-skript som gör den löpande kontrollen automatisk istället för att du ska behöva komma ihåg att slå upp posterna manuellt varje vecka.

Vad är DMARC, SPF och DKIM och varför är det akut just nu

SPF, DKIM och DMARC är tre separata DNS-baserade tekniker som tillsammans bevisar att ett mejl verkligen kommer från den domän det påstår sig komma från. SPF (Sender Policy Framework) listar vilka servrar som får skicka mejl för din domän. DKIM (DomainKeys Identified Mail) lägger en kryptografisk signatur på varje utgående mejl så mottagaren kan verifiera att innehållet inte manipulerats på vägen. DMARC (Domain-based Message Authentication, Reporting and Conformance) binder ihop de två, talar om för mottagande servrar vad de ska göra med mejl som faller på autentiseringen, och skickar dig rapporter om vem som försöker skicka mejl i ditt namn.

Ingen av de tre teknikerna är ny. SPF och DKIM har funnits sedan mitten av 2000-talet, och DMARC-specifikationen publicerades redan 2015. Det som förändrats är inte tekniken i sig, utan hur hårt den nu tillämpas av mottagarsidan. Tidigare var publicerad autentisering en bra praxis som förbättrade leveransgraden marginellt. Idag är den ett hårt krav som avgör om ett mejl kommer fram över huvud taget, vilket gör att samma tre förkortningar plötsligt dyker upp i agendan för IT-chefer som aldrig tidigare behövt bry sig om dem.

Det som gör hösten 2026 särskilt brådskande är att de tre stora brevlådeleverantörerna slutat vara flexibla. Gmail och Yahoo gjorde autentisering obligatorisk för massutskick redan i februari 2024, men det är först nu, när Microsoft skärpt sina egna regler för Outlook.com, Hotmail.com och Live.com sedan den 5 maj 2025, att hela ekosystemet pekar åt samma håll. Ett mejl som inte klarar kraven avvisas inte längre tyst till skräpposten, det studsar med ett felmeddelande, och i Microsofts fall ofta med SMTP-koden 550 5.7.515.

Många svenska organisationer tror fortfarande att de är undantagna eftersom de inte skickar nyhetsbrev i stor skala. Problemet är att kraven inte bara gäller marknadsavdelningens utskick. CRM-system, supportplattformar, faktureringsverktyg och interna automatiseringar skickar ofta mejl i din domäns namn utan att IT-avdelningen vet om det, och varje sådan källa måste antingen autentiseras korrekt eller exkluderas medvetet. Utan DMARC har du heller inget sätt att upptäcka om någon förfalskar din domän för att skicka nätfiske i ditt namn, vilket är den klassiska attackvektorn för både VD-bedrägerier och leverantörsbedrägerier riktade mot svenska företag.

Ett ytterligare skäl till brådskan är att hela ekosystemet nu rör sig i takt. Fram till för några år sedan kunde enskilda leverantörer agera isolerat, och en organisation som struntade i kraven märkte bara en gradvis försämrad leveransgrad. Nu när Gmail, Yahoo och Microsoft delar i princip samma minimikrav försvinner den flexibiliteten. Ett mejl som studsar hos en av de tre studsar oftast hos alla tre samtidigt, eftersom roten till problemet, bristande autentisering, är densamma oavsett mottagare. Det gör att en sen start med DMARC inte längre bara är en teknisk skuld, utan en direkt risk för att affärskritisk kommunikation helt enkelt inte kommer fram.

Sverige och Norden: dmarc-läget i siffror

Statistiken visar en marknad som rör sig, men långsamt. I april 2026 saknade 73,3 procent av svenska domäner ett effektivt DMARC-skydd, medan bara 12,4 procent hade nått fullt skydd med policyn satt till p=reject vid 100 procents enforcement. Resterande 14,3 procent låg i mellanläget, med karantän eller en gradvis upptrappning av policyn. Globalt sett låg Sverige i augusti 2026 nära det internationella genomsnittet, med en fullständig skyddsnivå kring 12,7 procent mot ett världsgenomsnitt på 11,7 procent, enligt DmarcDkim.coms sammanställning för april 2026.

Skyddsnivå	Sverige (april 2026)	Globalt (augusti 2026)	Vad det innebär
Inget effektivt skydd	73,3%	68,1%	Ingen DMARC-post, eller policy satt till none utan uppföljning
Partiellt skydd	14,3%	20,2%	Karantän eller reject vid en delvis procentsats (pct under 100)
Fullt skydd	12,4%	11,7%	p=reject vid 100% enforcement, förfalskade mejl avvisas direkt

Trenden pekar svagt uppåt. Mellan april och oktober 2026 klättrade andelen svenska domäner med fullt skydd från 12,4 till 12,9 procent, en ökning på bara en halv procentenhet på sex månader. Det låter marginellt, men det speglar hur långsam processen faktiskt är när organisationer gör rätt: de börjar i övervakningsläge, samlar rapporter under flera veckor, rättar till felkonfigurerade avsändare, och höjer policyn stegvis för att undvika att legitima mejl blockeras av misstag. Samma källa visar att andelen domäner som saknar dmarc.coms dedikerade kategori “strikt policy” (karantän eller reject vid 100 procent) låg på 23,9 procent i april, vilket ger en tydligare bild av hur många som faktiskt är på väg mot målet snarare än att bara ha publicerat en post och glömt den.

Risken med obskyddad e-post: nätfiske och vd-bedrägerier

Siffrorna ovan är inte bara en akademisk övning i e-postteknik. En domän utan DMARC-skydd går att förfalska fullständigt: en angripare skickar ett mejl med ditt företags domän i Från-fältet, och utan DMARC finns inget tekniskt hinder som stoppar det innan det landar i mottagarens inkorg. Det är exakt den mekanismen som ligger bakom vd-bedrägerier, där en angripare utger sig för att vara en chef och ber ekonomiavdelningen om en brådskande betalning, och bakom leverantörsbedrägerier, där en förfalskad faktura med en ändrad bankuppgift skickas i en befintlig leverantörs namn.

Den typen av bedrägeri är svår att stoppa med vanligt spamfilter, eftersom innehållet i sig ofta är välskrivet och saknar de klassiska varningstecknen som stavfel eller misstänkta länkar. Det som avslöjar förfalskningen är nästan alltid den tekniska avsändarinformationen, vilket är precis det DMARC är byggt för att kontrollera. En organisation med DMARC på p=reject gör det i praktiken omöjligt att skicka ett mejl som ser ut att komma direkt från den egna domänen, vilket tvingar angripare att istället registrera en liknande domän (till exempel med ett extra bindestreck eller en förväxlingsbokstav), vilket är lättare att upptäcka för både tekniska filter och vana mottagare.

Det här är också skälet till att DMARC-rapporterna i sig är värdefulla långt innan policyn höjs till reject. Redan i övervakningsläge ser du exakt vilka IP-adresser som försöker skicka mejl i din domäns namn, vilket ofta avslöjar pågående förfalskningsförsök som annars hade passerat obemärkt. Många organisationer upptäcker sitt första konkreta förfalskningsförsök redan under de första veckorna i p=none-läge, långt innan något faktiskt enforcement är på plats.

Vad Google, Yahoo och Microsoft kräver av massutskick 2026

Gränsen för att räknas som massavsändare är densamma hos Google och Microsoft: 5 000 eller fler meddelanden per dag till personliga konton. Yahoo och Apple har inte publicerat en exakt sifferbaserad gräns på samma sätt, men tillämpar motsvarande autentiseringskrav på avsändare de bedömer skickar i stor volym. Oavsett tröskelvärde gäller samma grundregler för alla fyra: giltig SPF eller DKIM, en publicerad DMARC-post, alignment mellan det synliga avsändarfältet och autentiseringsresultatet, stöd för envägs-avregistrering med ett klick, och en klagomålsfrekvens under 0,3 procent, enligt Email Deliverability Explaineds sammanställning från september 2026.

Leverantör	Tröskel för massutskick	Minimikrav på DMARC	Konsekvens vid avvikelse
Google (Gmail)	5 000+ mejl/dag	Publicerad post, minst p=none	Studsar eller flaggas som skräppost
Yahoo	Motsvarande volymkrav	Publicerad post, minst p=none	Studsar eller flaggas som skräppost
Microsoft (Outlook/Hotmail/Live)	5 000+ mejl/dag	Publicerad post, alignment krävs	Avvisas med SMTP-kod 550 5.7.515
Apple (iCloud Mail)	Ej publicerad exakt siffra	Jämförbara autentiseringskrav	Filtreras eller avvisas

Det viktiga att förstå är att en publicerad DMARC-post i sig inte räcker. Google accepterar formellt en policy satt till p=none, vilket bara innebär övervakning utan att något faktiskt blockeras, men kravet på alignment gäller ändå. Minst ett av SPF- eller DKIM-resultaten måste stämma överens med domänen i det synliga Från-fältet, annars räknas mejlet som icke-autentiserat oavsett vad DMARC-posten säger. Det är den detaljen som gör att många organisationer tror sig vara skyddade trots att de i praktiken inte är det, enligt genomgången hos Courier.

Historiskt sett var Gmail och Yahoo de två som agerade först, med sina bulk-sender-krav från februari 2024. Microsoft följde efter med Outlook.com, Hotmail.com och Live.com från den 5 maj 2025, och Apple har under 2026 anpassat iCloud Mail till jämförbara krav utan att offentliggöra ett lika exakt tröskelvärde som Google och Microsoft, enligt genomgången hos Telnyx. Skillnaden mellan leverantörerna ligger mindre i vilka tekniker som krävs, och mer i hur strikt och omedelbart de agerar när kraven inte uppfylls: Microsofts hårda avvisning med en specifik felkod kontrasterar mot Googles mjukare filtrering till skräpposten, vilket gör att ett och samma autentiseringsfel kan upplevas helt olika beroende på vilken mottagarplattform det drabbar.

Förutsättningar innan du börjar

Innan du rör en enda DNS-post behöver du ha koll på vilka system som faktiskt skickar mejl i din domäns namn. Det är den vanligaste orsaken till att en DMARC-utrullning havererar: någon glömmer bort en tjänst, höjer policyn för tidigt, och viktiga mejl börjar studsa utan förvarning.

• Adminbehörighet till din DNS-zon (Cloudflare, Loopia, One.com, Azure DNS, Route 53 eller motsvarande)
• Adminbehörighet i Microsoft 365 admin center eller Google Workspace Admin-konsolen, beroende på vilken plattform ni använder för e-post
• dig eller motsvarande DNS-sökverktyg, exempelvis BIND dnsutils 9.18 eller senare
• Node.js 22 LTS om du vill köra det övervakningsskript vi bygger längre ner i guiden
• OpenSSL 3.x, i de fall din e-postleverantör inte genererar DKIM-nycklar automatiskt och du behöver skapa dem själv
• En lista över alla tjänster som skickar mejl i din domäns namn: CRM, fakturering, nyhetsbrev, supportsystem, interna skript
• Minst två till fyra veckors tålamod, eftersom DMARC ska rullas ut gradvis och aldrig forceras direkt till reject

Du behöver inte köpa någon kommersiell DMARC-plattform för att komma igång. Aggregerade rapporter är XML-filer som går att läsa manuellt, även om det blir opraktiskt i stora organisationer med hundratals avsändare. I den här guiden visar vi både den manuella vägen och hur du automatiserar tolkningen med ett eget skript.

Tänk också på DNS-zonens TTL-värden (time to live) innan du börjar. Om din nuvarande TTL är satt till ett dygn eller mer kan det vara värt att tillfälligt sänka den till exempelvis 300 sekunder under själva utrullningsfasen. Det gör att ändringar du gör i SPF-, DKIM- och DMARC-posterna slår igenom globalt på minuter istället för timmar, vilket sparar väsentlig tid när du behöver justera något snabbt efter att ha upptäckt ett fel i rapporterna. Höj TTL-värdet igen till ett normalt läge när policyn är stabil på p=reject.

Steg 1 till 4: Kartlägg källor och publicera SPF-posten

Steg 1. Kartlägg alla e-postkällor. Gå igenom fakturering, CRM, HR-system, nyhetsbrevsverktyg, supportplattform och interna skript. Fråga varje avdelning specifikt, eftersom marknad, ekonomi och IT ofta har olika tjänster som skickar mejl utan att någon annan vet om det.

Steg 2. Samla in varje tjänsts SPF-mekanism. De flesta större leverantörer publicerar sin egen include-sats. Microsoft 365 använder till exempel include:spf.protection.outlook.com och Google Workspace använder include:_spf.google.com. Tredjepartsverktyg som skickar nyhetsbrev eller transaktionsmejl har egna mekanismer du hittar i deras dokumentation.

Spara ner alla mekanismer i ett dokument innan du rör DNS-zonen. Det är lätt att missa en källa i brådskan, och ett samlat dokument gör det också enklare för kollegor att förstå varför SPF-posten ser ut som den gör långt senare, när ingen längre kommer ihåg exakt varför en viss include-sats lades till.

Steg 3. Skriv ihop SPF-posten och publicera den som TXT-post på roten av din domän. Posten måste börja med v=spf1 och avslutas med antingen -all (strikt, rekommenderas i produktion) eller ~all (mjuk, lämplig under test).

exempel.se.    TXT    "v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:sendgrid.net -all"

Steg 4. Kontrollera lookup-gränsen. SPF tillåter max tio DNS-uppslag per kontroll. Varje include räknas, och om du staplar för många tredjepartstjänster riskerar du att SPF-kontrollen misslyckas helt med felet permerror. Håll antalet include-satser lågt genom att platta ut kedjor där det går, och slå ihop flera mindre avsändare under en gemensam relätjänst om möjligt.

dig TXT exempel.se +short
dig TXT spf.protection.outlook.com +short

Steg 5 till 7: Aktivera och publicera DKIM

Steg 5. Aktivera DKIM-signering hos varje leverantör. Microsoft 365 och Google Workspace har inbyggda funktioner för detta i adminkonsolen, oftast under säkerhet eller e-postautentisering. Aktivera signering för varje domän du äger, inte bara huvuddomänen.

Steg 6. Publicera den publika nyckeln som en DNS TXT-post under en selector. Leverantören ger dig själva selector-namnet, till exempel selector1._domainkey, och du klistrar in nyckeln de genererat. Använd 2048-bitars nycklar där leverantören tillåter det. 1024-bitars nycklar fungerar fortfarande men ger ett svagare skydd och fasas successivt ut av fler mottagare.

selector1._domainkey.exempel.se.    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Steg 7. Verifiera att signaturen faktiskt läggs på utgående mejl. Skicka ett testmejl till en extern adress och granska de fullständiga mejlhuvudena. Du letar efter en DKIM-Signature-rad, och om du skickar till Gmail kan du öppna mejlet, klicka på de tre punkterna och välja “visa original” för att se autentiseringsresultatet direkt.

Gör samma test från varje källa du kartlade i steg 1, inte bara från huvudmejlsystemet. Ett vanligt mönster är att den vanliga mejlklienten signerar korrekt medan ett glömt faktureringssystem eller en gammal supportplattform fortsätter skicka osignerade mejl i bakgrunden, osynligt för de flesta tills DMARC-rapporterna avslöjar det.

Steg 8 till 10: Publicera DMARC i övervakningsläge

Steg 8. Publicera din första DMARC-post med policyn satt till none. Det här steget är det viktigaste i hela processen, eftersom det ger dig insyn utan att riskera att blockera legitima mejl. Posten läggs som TXT på _dmarc.exempel.se.

_dmarc.exempel.se.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; pct=100"

Steg 9. Konfigurera en mottagande brevlåda för de aggregerade rapporterna (rua). Många stora mottagare, inklusive Google och Microsoft, skickar en sammanfattande rapport per dygn och avsändardomän. Skapa en dedikerad adress, inte en personlig inkorg, eftersom volymen snabbt blir ohanterlig manuellt.

Om organisationen skickar mejl från flera domäner, exempelvis ett huvudvarumärke och ett eller två produktvarumärken, är det ofta enklare att samla alla rua-rapporter i en och samma brevlåda och sedan sortera med mappregler baserat på vilken domän rapporten gäller. Det ger en samlad överblick utan att behöva logga in på flera olika postlådor varje vecka.

Steg 10. Låt posten stå i minst två till fyra veckor innan du rör något mer. Du behöver den tiden för att samla in ett representativt urval av både vanliga arbetsveckor och eventuella månadsvisa utskick, exempelvis fakturering som bara körs en gång per månad.

Steg 11 till 12: Tolka rapporterna och fixa alignment-fel

Steg 11. Öppna de aggregerade rapporterna. De kommer som gzippade XML-filer, och varje rapport listar vilka IP-adresser som skickat mejl i din domäns namn, hur många meddelanden det rörde sig om, och om de klarade SPF och DKIM.

<record>
  <row>
    <source_ip>40.107.22.58</source_ip>
    <count>214</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>exempel.se</header_from>
  </identifiers>
</record>

Steg 12. Identifiera avsändare som inte klarar alignment och åtgärda dem. Det vanligaste felet är att en tredjepartstjänst skickar mejl med er domän i Från-fältet men signerar med sin egen DKIM-domän, vilket bryter alignment även om SPF formellt klarar sig. Lösningen är oftast att be leverantören aktivera anpassad DKIM-signering (ofta kallat “custom DKIM” eller “domain alignment”) för just er domän, snarare än att de använder sin egen delade signatur.

Steg 13 till 14: Höj policyn till quarantine och sedan reject

Steg 13. Höj policyn till quarantine med en låg procentsats. Istället för att gå direkt till 100 procent, börja med pct=10 och öka gradvis varje vecka om rapporterna fortsätter se rena. Det begränsar skadan om något du missat fortfarande skickar oautentiserade mejl.

_dmarc.exempel.se.    TXT    "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"

Steg 14. Gå till fullt p=reject när rapporterna är rena i minst två veckor i rad. Det här är målet hela utrullningen siktar mot: förfalskade mejl i din domäns namn avvisas direkt av mottagande server, utan att det belastar din egen infrastruktur eller riskerar att legitim trafik filtreras bort.

Fira inte för tidigt när du väl är på p=reject. Sätt en återkommande kalenderpåminnelse, exempelvis kvartalsvis, för att granska rapporterna igen. Nya avsändartjänster tillkommer över tid, personal byts ut, och ett system som fungerade perfekt vid lanseringen kan sluta signera korrekt efter en uppgradering hos leverantören utan att någon i organisationen informeras om det i förväg.

_dmarc.exempel.se.    TXT    "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s"

Steg 15 till 16: MTA-STS, BIMI och ett eget övervakningsskript

Steg 15. Lägg till MTA-STS och BIMI när autentiseringen är stabil. MTA-STS tvingar fram krypterad överföring mellan mejlservrar och skyddar mot nedgraderingsattacker, medan BIMI låter din verifierade logotyp visas i mottagarens inkorg som ett extra förtroendesignal. Ingen av dem ersätter DMARC, de bygger ovanpå ett redan fungerande skydd. Enligt DDMARCs produktlogg har flera leverantörer under hösten 2026 börjat erbjuda hostad MTA-STS-policy över HTTPS med automatiska certifikat, samt hostade BIMI-tillgångar, vilket gör den här delen betydligt enklare att komma igång med än för ett år sedan.

_mta-sts.exempel.se.    TXT    "v=STSv1; id=20261018000000"
default._bimi.exempel.se.    TXT    "v=BIMI1; l=https://exempel.se/logo.svg"

Steg 16. Bygg ett litet skript som granskar dina DNS-poster löpande. Det här är grunden i det kompletta projektet längre ner i guiden, ett Node.js-skript som slår upp SPF, DKIM och DMARC och flaggar om något saknas eller är felkonfigurerat, utan att du behöver logga in i en kommersiell plattform för en snabb hälsokontroll.

Tänk på de sexton stegen ovan som en linjär process första gången du gör den, men som en cykel du återvänder till varje gång organisationen lägger till en ny mejltjänst. En ny marknadsföringsplattform eller ett nytt CRM-system ska alltid gå igenom samma granskning innan den får skicka mejl i produktionsdomänens namn, annars riskerar hela det arbete du lagt ner på att nå p=reject att undergrävas av en enda ny, oautentiserad källa.

Komplett arbetsprojekt: ett skript som granskar dina DNS-poster

Istället för att manuellt köra dig varje gång du vill kontrollera läget kan du bygga ett litet Node.js-skript som gör samma kontroll automatiskt för en eller flera domäner. Skriptet nedan kräver bara Node.js 22 LTS och det inbyggda dns-biblioteket, inga externa paket behövs, vilket gör det enkelt att släppa in i en befintlig server utan att dra in ett helt beroendeträd bara för en DNS-kontroll.

Tanken är inte att skriptet ska ersätta en kommersiell DMARC-plattform för stora organisationer med hundratals avsändare, utan att ge mindre och medelstora organisationer, eller en enskild IT-avdelning som vill ha en snabb hälsokontroll, ett sätt att se status utan extra kostnad. Du kan köra det manuellt vid behov, eller lägga in det i ett schemalagt jobb som larmar om något förändras.

import { resolveTxt } from "node:dns/promises";

async function hamtaTxt(namn) {
  try {
    const poster = await resolveTxt(namn);
    return poster.map((rad) => rad.join(""));
  } catch {
    return [];
  }
}

async function granskaDomain(domain) {
  const spf = (await hamtaTxt(domain)).filter((p) => p.startsWith("v=spf1"));
  const dmarc = (await hamtaTxt(`_dmarc.${domain}`)).filter((p) => p.startsWith("v=DMARC1"));

  console.log(`\nDomän: ${domain}`);

  if (spf.length === 0) {
    console.log("  SPF: SAKNAS");
  } else {
    console.log(`  SPF: ${spf[0]}`);
  }

  if (dmarc.length === 0) {
    console.log("  DMARC: SAKNAS");
  } else {
    const post = dmarc[0];
    const policy = post.match(/p=(\w+)/)?.[1] ?? "okänd";
    console.log(`  DMARC: ${post}`);
    console.log(`  Policy: ${policy}${policy === "none" ? " (övervakning, inget enforcement)" : ""}`);
  }
}

const domaner = process.argv.slice(2);
for (const domain of domaner) {
  await granskaDomain(domain);
}

Spara filen som granska-dmarc.mjs och kör den med en eller flera domäner som argument:

node granska-dmarc.mjs exempel.se annandomain.se

Ett exempel på utskrift för en domän som ligger i övervakningsläge ser ut ungefär så här:

Domän: exempel.se
  SPF: v=spf1 include:spf.protection.outlook.com -all
  DMARC: v=DMARC1; p=none; rua=mailto:[email protected]
  Policy: none (övervakning, inget enforcement)

Utöka skriptet gärna med en kontroll som skickar ett larm, exempelvis via Slack eller mejl, om policyn plötsligt försvinner från DNS-svaret. Det händer oftare än man tror vid DNS-migreringar eller byte av hostingleverantör, och är en av de vanligaste orsakerna till att ett väl fungerande DMARC-skydd tystnar utan att någon märker det på flera veckor. Ett enkelt sätt att automatisera det är att schemalägga skriptet som ett cron-jobb en gång per dygn och bara skriva ut något om resultatet skiljer sig från föregående körning, så du slipper läsa samma oförändrade utskrift varje morgon.

Ett annat naturligt steg är att låta skriptet läsa domänlistan från en textfil istället för kommandoradsargument, vilket gör det lättare att hantera tiotals domäner samtidigt om organisationen äger flera varumärken. Du kan också bygga ut kontrollen till att verifiera DKIM-selectorn specifikt, genom att slå upp selector._domainkey.domain för varje känd selector och flagga om nyckeln saknas eller är ovanligt kort, vilket ofta är ett tecken på en gammal 1024-bitars nyckel som bör roteras.

DMARC-taggar: en fullständig referenstabell

En DMARC-post består av flera taggar separerade med semikolon, och det är lätt att bli osäker på vad var och en faktiskt styr när man ser en lång post för första gången. Tabellen nedan går igenom samtliga taggar som används i stegen ovan, plus några du troligen stöter på i andras konfigurationer även om vi inte använder dem i grundexemplen.

Tagg	Betydelse	Exempelvärde
v	Protokollversion, alltid DMARC1	v=DMARC1
p	Policy för huvuddomänen	none, quarantine eller reject
sp	Underpolicy för subdomäner som saknar egen post	sp=reject
pct	Hur stor andel av mejlen policyn tillämpas på	pct=10 till pct=100
rua	Mottagaradress för aggregerade rapporter	rua=mailto:[email protected]
ruf	Mottagaradress för forensiska rapporter	ruf=mailto:[email protected]
adkim	Alignment-läge för DKIM, s (strikt) eller r (avslappnad)	adkim=s
aspf	Alignment-läge för SPF, s (strikt) eller r (avslappnad)	aspf=s
fo	Vilka händelser som ska trigga forensiska rapporter	fo=1

Två taggar förtjänar extra uppmärksamhet eftersom de ofta misstolkas. pct styr inte hur stor andel av din e-post som autentiseras, utan hur stor andel av de mejl som redan misslyckats med autentiseringen som faktiskt ska behandlas enligt policyn. Vid pct=10 och p=quarantine hamnar alltså ungefär en tiondel av de felaktiga mejlen i karantän, medan resten fortfarande levereras som vanligt, vilket är precis den gradvisa inkörning hela metoden i den här guiden bygger på. Den andra är skillnaden mellan strikt och avslappnad alignment: avslappnat läge (standard om inget anges) godtar att domänen i autentiseringen är en subdomän till Från-domänen, medan strikt läge kräver en exakt matchning tecken för tecken.

Vanliga fallgropar vid DMARC-utrullning

De flesta misstag i en DMARC-utrullning har samma rotorsak: otålighet. Policyn höjs snabbare än rapporterna hinner visa helhetsbilden, eller en subdomän glöms bort tills den plötsligt studsar trafik under en kampanj. Håll koll på följande sex fallgropar och du undviker de flesta akuta incidenter.

• Att hoppa direkt till p=reject. Utan att först samla rapporter i övervakningsläge riskerar du att blockera legitima avsändare du inte kände till, exempelvis ett faktureringssystem som bara körs en gång i kvartalet.
• Att glömma subdomäner. En DMARC-post på huvuddomänen skyddar inte automatiskt subdomäner som nyhetsbrev.exempel.se om inte en egen underpolicy (sp=) sätts eller en egen post publiceras.
• Att överskrida SPF:s gräns på tio DNS-uppslag. För många staplade include-satser gör att hela SPF-kontrollen går sönder med permerror, vilket i praktiken är sämre än att inte ha någon SPF-post alls.
• Att blanda ihop strikt och avslappnad alignment. Att sätta adkim=s och aspf=s (strikt) utan att först kontrollera att alla avsändare verkligen signerar med exakt rätt domän kan sänka godkännandefrekvensen onödigt mycket.
• Att inte sätta en mottagande adress för rua-rapporter. Utan en adress som faktiskt tas emot och läses är hela poängen med övervakningsläget bortkastad, eftersom du då aldrig ser vilka avsändare som faktiskt finns där ute.
• Att tro att DMARC ersätter spamfilter. DMARC skyddar din egen domän från att utnyttjas, men stoppar inte nätfiske som skickas från en helt annan, liknande domän (till exempel exempel-se.com istället för exempel.se).

Felsökning: vanliga problem och lösningar

Även en noggrant planerad utrullning stöter på problem. De flesta går att lösa på under en timme om man känner till orsaken, men kan annars ligga och dra ut processen med veckor eftersom symptomet ofta dyker upp i en rapport flera dagar efter att den faktiska orsaken uppstod. Här är de åtta vanligaste du bör känna till innan du fastnar på dem själv.

• SPF-kontrollen ger permerror. Räkna antalet include-satser med dig och platta ut kedjor. Slå ihop flera mindre tjänster bakom en relä-SMTP om du äger infrastrukturen.
• DKIM-signaturen saknas helt på utgående mejl. Kontrollera att signeringen faktiskt är aktiverad i adminkonsolen, inte bara att nyckeln är publicerad i DNS. Många glömmer det sista steget.
• DMARC-rapporter kommer aldrig in. Kontrollera att mottagande brevlåda inte filtrerar bort rapporterna som skräppost, och att adressen i rua= är korrekt stavad utan extra mellanslag.
• Legitima mejl börjar studsa efter att policyn höjdes. Sänk tillbaka till en lägre pct-nivå omedelbart och gå igenom de senaste rapporterna för att hitta vilken källa som inte är autentiserad.
• Alignment misslyckas trots att både SPF och DKIM visar pass separat. Kontrollera att domänen i DKIM-signaturens d=-fält matchar Från-domänen, inte bara leverantörens egen domän.
• DNS-posten syns inte efter publicering. TTL-värden och cachning kan göra att det tar upp till ett dygn innan ändringen slår igenom globalt. Testa från flera olika DNS-resolvers, inte bara din egen.
• Flera DMARC-poster av misstag på samma domän. Enligt specifikationen ska bara en post finnas på _dmarc-noden. Om flera finns ogiltigförklaras ofta hela kontrollen av mottagande server.
• Forensiska rapporter (ruf) kommer inte in alls. Många stora mottagare, inklusive Google, har slutat skicka forensiska rapporter av integritetsskäl. Förlita dig istället primärt på de aggregerade rapporterna (rua).

Avancerade tips för stora organisationer

De sexton stegen och felsökningslistan ovan räcker gott för en enskild organisation med ett fåtal domäner, men ju större och mer komplex miljön är, desto fler specialfall dyker upp. Nedanstående tips riktar sig till IT-avdelningar som hanterar flera varumärken, dotterbolag eller en blandning av molntjänster och egen infrastruktur.

I en koncern med flera varumärken och dussintals subdomäner blir komplexiteten snabbt en annan storleksordning. Sätt alltid en explicit underpolicy med sp= på huvuddomänens DMARC-post, även om den är identisk med huvudpolicyn, så att det inte råder någon tvekan om vad som gäller för subdomäner som aldrig fick en egen post. Separata affärsområden bör också ha egna rua-adresser snarare än en gemensam brevlåda för hela koncernen, eftersom volymen annars blir ohanterlig och ansvaret för att faktiskt agera på rapporterna tenderar att försvinna mellan stolarna.

För organisationer som hanterar känslig kommunikation, exempelvis inom vård, finans eller offentlig sektor, är det värt att utvärdera strikt alignment (adkim=s; aspf=s) som standard snarare än undantag. Strikt läge kräver exakt domänmatchning istället för att även godta underdomänmatchning, vilket stänger en känd kryphål där en angripare registrerar en subdomän som formellt matchar en avslappnad regel. Kombinera det med regelbunden granskning av BIMI-loggan, eftersom en förlegad eller felaktig logotyp i mottagarens inkorg undergräver precis det förtroende BIMI är tänkt att bygga upp.

Slutligen, dokumentera varje DNS-ändring i en separat logg, oberoende av din vanliga DNS-leverantörs historik. När något går fel tre veckor senare, och det gör det ibland, är det ovärderligt att snabbt kunna se exakt vilken post som ändrades, av vem, och varför.

Organisationer som redan arbetar med NIS2-krav bör notera att e-postautentisering sällan nämns explicit i lagtexten, men i praktiken faller rakt in under kraven på grundläggande cyberhygien och skydd mot nätfiske som en av de vanligaste ingångspunkterna för intrång. Att kunna visa upp en fungerande DMARC-policy med historik över flera månaders rapporter är ett konkret, lätt att dokumentera bevis på att organisationen tagit ett rimligt tekniskt skydd på allvar, vilket är precis den typen av dokumentation en tillsynsmyndighet eller revisor efterfrågar.

Vanliga frågor

Vad är skillnaden mellan SPF, DKIM och DMARC?

SPF listar vilka servrar som får skicka mejl för din domän. DKIM signerar varje mejl kryptografiskt så innehållet går att verifiera. DMARC binder ihop de två och bestämmer vad mottagaren ska göra om kontrollerna misslyckas, samtidigt som den skickar dig rapporter om resultaten.

Måste mitt företag ha DMARC 2026?

Formellt krävs det bara om du skickar i de volymer Google, Yahoo och Microsoft definierar som massutskick. I praktiken bör alla organisationer som skickar mejl i sitt eget domännamn ha minst en DMARC-post i övervakningsläge, eftersom det är det enda sättet att upptäcka om någon förfalskar domänen för nätfiske.

Vad händer om jag inte uppfyller Googles och Yahoos krav?

Mejl till Gmail- och Yahoo-adresser riskerar att studsa helt eller hamna i skräppost, oavsett hur relevant innehållet är. Microsoft går längre och avvisar aktivt icke-autentiserad massutskick till Outlook.com, Hotmail.com och Live.com med felkoden 550 5.7.515.

Hur lång tid tar det att gå från p=none till p=reject?

Räkna med minst fyra till åtta veckor för en organisation av normal storlek, och betydligt längre för en koncern med många avsändarsystem. Att skynda på processen är den vanligaste orsaken till att legitima mejl plötsligt börjar studsa.

Vad är BIMI och behöver jag det?

BIMI låter din verifierade logotyp visas bredvid mejlet i mottagarens inkorg. Det kräver i regel att du redan har DMARC på p=quarantine eller p=reject. Det är inte obligatoriskt, men stärker förtroendet och minskar risken att mottagaren förväxlar legitima mejl med nätfiske.

Vad är MTA-STS och skiljer det sig från DMARC?

MTA-STS handlar om transportsäkerhet, det tvingar fram krypterad överföring mellan mejlservrar och skyddar mot nedgraderingsattacker. DMARC handlar istället om avsändaridentitet. De två löser olika problem och kompletterar varandra snarare än att ersätta varandra.

Kan jag ha flera DMARC-poster på samma domän?

Nej. Specifikationen tillåter bara en DMARC-post per domän på _dmarc-noden. Om flera poster av misstag publiceras samtidigt ogiltigförklarar många mottagande servrar hela kontrollen, vilket i praktiken innebär att du förlorar skyddet helt tills felet rättas till.

Hur ofta bör jag granska DMARC-rapporterna?

Under den första övervakningsfasen bör du granska rapporterna minst en gång i veckan. När policyn är fullt genomförd på p=reject räcker det oftast med en månadsvis genomgång, plus ett automatiskt larm om policyn av någon anledning försvinner från DNS.

Kostar det något att komma igång med DMARC, SPF och DKIM?

Grundteknikerna i sig är gratis. DNS-poster kostar ingenting extra att publicera utöver vad du redan betalar för din DNS-hosting, och både SPF, DKIM och DMARC går att tolka manuellt utan några licenskostnader. Det som kostar är framför allt tid, och i större organisationer eventuellt en kommersiell plattform som automatiserar rapportanalysen när volymen av avsändare blir för stor för att hantera för hand.