Så skyddar en korrekt DMARC policy er domän mot spoofing
Utan en korrekt konfigurerad dmarc policy kan vem som helst skicka bedrägerier i er domäns namn – något som blivit allt vanligare mot svenska B2B-företag. Den här guiden går igenom hur ni läser en dmarc record, väljer rätt policy-nivå och genomför en dmarc check utan att riskera att era egna riktade utskick fastnar i spamfiltret.
- En dmarc record utan rätt policy skyddar inte er domän – p=none är bara övervakning.
- Gå stegvis från none till quarantine till reject, och verifiera SPF/DKIM-alignment för varje avsändarsystem innan ni skärper.
- "dmarc policy not enabled" är vanligare än man tror och lämnar B2B-domäner öppna för e-postbedrägerier.
- En dedikerad subdomän för cold outreach minskar risken att en policy-skärpning stör ordinarie e-post.
- Regelbunden dmarc check och granskning av rapporter är minst lika viktigt som själva uppsättningen.
Varför DMARC är kritiskt för B2B-avsändare
Under de senaste åren har e-postbedrägerier riktade mot svenska B2B-företag ökat kraftigt – falska fakturor, VD-bedrägerier och phishing som ser ut att komma från er egen domän. Om er domän saknar ett DMARC-record kan i princip vem som helst skicka e-post som verkar komma från er säljavdelning eller ekonomiavdelning, vilket skadar både mottagarnas förtroende och er egen avsändarrenommé.
För ett företag som bedriver riktad cold email mot specifika beslutsfattare är det här extra känsligt. En mottagande organisation som ser att er domän saknar skydd, eller att SPF och DKIM inte är korrekt uppsatta, riskerar att flagga hela domänen som misstänkt – oavsett hur personlig och relevant kampanjen är. En korrekt uppsatt dmarc policy är därför inte bara ett säkerhetsverktyg utan en förutsättning för att legitima B2B-utskick ska nå fram.
Så läser ni en dmarc record
En dmarc record är en TXT-post i DNS på _dmarc.dindomän.se som talar om för mottagande mailservrar hur de ska hantera e-post som inte klarar SPF- eller DKIM-kontroll, och vart rapporter om detta ska skickas. En minimal record ser ut ungefär så här: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-rapporter@dindomän.se.
- v=DMARC1 – protokollversion, alltid samma värde
- p= – policy för domänen (none, quarantine eller reject)
- sp= – separat policy för subdomäner
- pct= – hur stor andel av e-posten som omfattas av policyn (bra vid gradvis infasning)
- rua= – adress för sammanfattade dagliga rapporter (aggregate reports)
- ruf= – adress för detaljerade felrapporter (forensic reports, används sällan i praktiken)
- aspf= / adkim= – strikt (s) eller avslappnad (r) alignment för SPF respektive DKIM
DMARC policy-nivåer: från none till reject
DMARC-policyn har tre nivåer. p=none innebär endast övervakning – ingen e-post blockeras, men ni får rapporter om vem som skickar e-post i ert namn. p=quarantine skickar e-post som inte klarar kontrollen till mottagarens skräppostmapp. p=reject avvisar den helt. En dmarc quarantine policy är ofta det klokaste mellansteget: den stoppar de flesta spoofingförsök utan att riskera att legitim e-post – till exempel svar från era egna säljare via en tredjepartsplattform – försvinner spårlöst.
Många svenska domäner fastnar dock i p=none i månader eller år, vilket i praktiken innebär att dmarc policy not enabled – domänen har en record, men den skyddar ingenting. Rekommendationen är att gå från none till quarantine med pct=25 eller pct=50 under några veckor, granska rapporterna, och därefter höja gradvis till pct=100 och slutligen reject när ni är säkra på att alla legitima avsändarkällor (CRM, ESP, faktureringssystem) är korrekt autentiserade.
Siffrorna är indikativa, baserade på erfarenhet från riktade B2B-kampanjer, inte en formell branschundersökning.
Dmarc check i praktiken – verktyg och vanliga fel
En dmarc check tar några minuter: kör dig TXT _dmarc.dindomän.se i terminalen, eller använd ett webbaserat verktyg för att se hur er record tolkas. Kontrollera samtidigt att SPF-posten inkluderar alla system som skickar e-post i ert namn (CRM, cold email-plattform, faktureringstjänst) och att DKIM-nycklarna är publicerade och aktiva för samma system.
Det vanligaste felet är att SPF eller DKIM tekniskt sett godkänns, men att domänen i From-fältet inte matchar den autentiserade domänen (alignment). Om er cold email-plattform skickar via en delad IP med SPF godkänt för "mail.leverantör.se" men mottagaren ser "info@dinfirma.se" i From-fältet, klarar meddelandet inte DMARC-alignment även om SPF tekniskt passerade.
Siffrorna är indikativa uppskattningar från löpande DMARC-granskningar av B2B-domäner, inte en vetenskaplig studie.
Vanliga misstag när B2B-företag inför DMARC
De flesta problem uppstår inte vid själva uppsättningen av dmarc record, utan i hur infasningen sköts efteråt.
- Att hoppa direkt till p=reject utan att först granska rapporter i p=none eller quarantine
- Att glömma subdomäner som används för landningssidor eller nyhetsbrev (sp=-taggen)
- Att inte inkludera cold email-verktyget eller CRM:et i SPF-posten
- Att blanda transaktionell e-post och cold outreach på samma avsändardomän utan separat subdomänstrategi
- Att aldrig läsa de aggregerade rapporterna (rua) – domänen "skyddas" på papper men ingen granskar avvikelserna
Checklista: så säkrar LDM avsändardomänen för riktade kampanjer
På LDM sätter vi alltid upp DMARC innan en kunds domän används för riktad cold email-utskick, oavsett volym. Grundprincipen är att skilja på huvuddomänen (fakturor, interna system) och en dedikerad subdomän för utskick, så att en eventuell policy-skärpning för utskicksdomänen aldrig påverkar den ordinarie e-posttrafiken.
- Publicera SPF och DKIM för alla avsändarsystem innan DMARC-record läggs till
- Starta med p=none och rua=mailto: till en adress som faktiskt granskas varje vecka
- Höj till p=quarantine med pct=25–50 efter 2–4 veckors ren rapportering
- Separera subdomän för cold outreach med egen sp=-policy
- Sikta på p=reject för huvuddomänen inom en till två månader
- Följ upp dmarc quarantine policy-rapporter löpande – inte bara vid uppsättning
Vanliga frågor
Vad är skillnaden mellan SPF, DKIM och DMARC?
SPF listar vilka servrar som får skicka e-post för er domän, DKIM signerar meddelandet kryptografiskt så mottagaren kan verifiera att det inte manipulerats, och DMARC talar om vad mottagaren ska göra om varken SPF eller DKIM stämmer med avsändardomänen samt skickar rapporter tillbaka till er.
Vad betyder "dmarc policy not enabled"?
Det betyder oftast att domänen antingen saknar en dmarc record helt, eller att policyn står på p=none, det vill säga endast övervakning utan att någon e-post faktiskt blockeras eller karantänsätts. Ni får rapporter, men domänen är i praktiken oskyddad mot spoofing.
Är p=reject farligt för våra egna cold email-kampanjer?
Bara om SPF och DKIM inte är korrekt inställda för det verktyg ni skickar från. Om alignment är i ordning skyddar reject er utan att påverka legitima utskick – riskerna uppstår när ni skärper policyn innan alla avsändarkällor är verifierade.
Hur ofta bör vi göra en dmarc check?
Direkt efter varje förändring i era e-postsystem (nytt CRM, ny cold email-plattform, ny leverantör) samt löpande varje månad, eftersom leverantörer ibland byter avsändande IP-intervall eller DKIM-nycklar utan att meddela er.
Behöver vi DMARC om vi bara skickar B2B cold email i liten skala?
Ja – domänens sårbarhet för spoofing har inget med volym att göra, och en liten men riktad kampanj är ofta känsligare för att mottagarens säkerhetsfilter tolkar autentiseringsproblem som ett tecken på bedrägeri.
Vad är en dmarc quarantine policy och när ska vi använda den?
Det är policyn p=quarantine, där e-post som fallerar autentisering skickas till mottagarens skräppostmapp istället för att avvisas helt. Den fungerar bra som mellansteg innan p=reject, eftersom ni fortfarande kan granska rapporter och rätta till felkonfigurationer utan att riskera att tappa legitim e-post helt.
Vill du använda det här i din outreach?
Vi visar hur det fungerar för ditt segment och din produkt — innan arbetet börjar.
Prata med oss