Defaults.Exposed › Åtgärder › DMARC (skydd mot e-postförfalskning)

Hur du fixar DMARC (skydd mot e-postförfalskning)

DMARC är den enda inställningen som faktiskt berättar för världens e-postleverantörer att BLOCKERA e-postmeddelanden som förfalskar ditt företagsnamn. SPF och DKIM kontrollerar låsen; DMARC bestämmer vad som händer när en förfalskning misslyckas kontrollen — kasta den, flagga den eller låt den passera. Satt fel är din domän fullt förfalskningsbar; satt rätt stoppas utpekande vid inkorgen.

Slutsats för ditt företag: Utan DMARC-verkställighet kan en bedragare skicka e-post som ser exakt ut att komma från ditt företag — till dina kunder, anställda och leverantörer — och det landar i deras inkorg, inte deras skräppost. Människor blir lurade i ditt namn, och de skuldbelägger dig.

Vad detta kan kosta dig

En bedragare mailar din kund en realistisk faktura 'från din ekonomiavdelning' med sina egna bankuppgifter. Kunden betalar den. Du får reda på det veckor senare när de jagar de varor de redan betalat för — och de håller dig ansvarig.
Ett falskt 'brådskande betalnings'-mejl går till din ekonomiansvarige, som verkar komma från dig som ägare. De överför pengarna innan någon tänker dubbelkolla — och när de väl landat på ett bedragares konto återfås de nästan aldrig.
Ett stort prospekts IT-team kör en säkerhetskontroll av din domän innan de skriver på. Det returnerar 'e-post oskyddad — kan förfalskas.' Du förlorar affären till en konkurrent vars domän klarade kontrollen.
Din domän används i en phishingvåg. Kunder som lurades lämnar ilskna recensioner och varnar andra. Rykteskadan överlever attacken med månader.
Till och med din genuina e-post börjar sorteras till skräppost, för Google och Yahoo litar alltmer — och avvisar nu ibland — domäner utan verkställd DMARC.

Varför det spelar roll. E-post var aldrig byggt för att bevisa vem som verkligen skickade det, så att förfalska 'från'-adressen är trivialt. DMARC är den enda kontrollen som förvandlar 'vi kan upptäcka förfalskningar' till 'förfalskningar blockeras' — och den ger dig också de dagliga rapporter som avslöjar vem som skickar e-post som ditt varumärke. Stora brevlådeleverantörer behandlar nu en saknad eller overksam DMARC-policy som en trust-signal mot dig, så det här påverkar om din egen e-post levereras också.

Vad DMARC är, i klartext

E-post har en smutsig hemlighet: “från”-raden är bara inskriven text. Vem som helst, var som helst, kan skriva ditt företagsnamn och din adress i “från”-fältet på ett e-postmeddelande och skicka det. Internet var aldrig designat för att stoppa dem.

Det finns tre inställningar som tillsammans löser det. Tänk på dem som ett kontorsbygges säkerhet:

SPF är en lista på vem som tillåts komma in genom ytterdörren (vilka e-posttjänster som får skicka som du).
DKIM är ett manipuleringssäkert sigill som bevisar att meddelandet inte ändrades under transport.
DMARC är säkerhetsvakten som kontrollerar listan och sigillet — och avgörande, bestämmer vad som ska hända när de inte stämmer: låt det igenom, skicka det till skräppost eller vänd det vid dörren.

Du kan ha listan (SPF) och sigillet (DKIM) och ändå inte ha någon vakt. Det är den enda vanligaste och farligaste situationen: låsen finns, men ingenting verkställer dem. DMARC är verkställigheten. Det är skillnaden mellan “vi kan avgöra att det här e-postmeddelandet är falskt” och “det falska e-postmeddelandet når aldrig din kund.”

Vad det här kan kosta dig

Det här är inte teoretiskt. Här är de konkreta sätten en oskyddad domän förvandlas till riktiga pengar och riktiga skador:

Den falska fakturabedrägeri. En bedragare mailar din kund vad som ser ut exakt som en äkta faktura från ditt ekonomiteam — samma namn, samma domän, professionell layout — men med sina egna bankuppgifter. Eftersom din domän inte är verkställd landar den i inkorgen, inte skräppost. Kunden betalar. Du upptäcker det veckor senare när de frågar var deras beställning är. Pengarna är vanligtvis borta, och kunden håller ofta dig ansvarig för intrånget.
VD-bedrägeri-överföringen. Ett e-postmeddelande verkar komma från dig, ägaren, till din ekonomiansvarige: “Kan du skicka den här betalningen brådskande, jag är i möte.” Det ser helt äkta ut för att det är din adress — bara förfalskad. Betalningen går ut. Det här mönstret — Business Email Compromise — är ett av de dyraste bedrägerierna som drabbar små företag, just för att e-postmeddelandet genuint verkar komma från din egen domän, så det seglar rakt förbi misstänksamhet.
Det förlorade kontraktet. En seriös potentiell kund kör en säkerhets- eller inköpskontroll innan de skriver på. Deras verktyg rapporterar din domän som “förfalskningsbar — ingen e-postautentiseringsverkställighet.” Den enda röda flaggan kan räcka för att ge kontraktet till en konkurrent vars domän klarade kontrollen. Du hör aldrig ens den verkliga anledningen.
Rykteskadan du inte kan ångra. Din domän sveps in i en phishingkampanj. Dussintals av människor som lurades i ditt namn publicerar varningar och recensioner. Attacken varar en vecka; frågan “är det här företaget ens säkert?” dröjer kvar i månader.
Din egen e-post går till skräppost. Google och Yahoo litar nu aktivt inte på domäner utan verkställd DMARC. Offerter, fakturor och svar som du genuint skickade börjar tyst landa i skräppostmappar. Affärer stannar och du förstår aldrig varför.

Vad det faktiskt är (och vad “bra” ser ut som)

DMARC lever som en enda textrad i din domäns inställningar — en DNS “TXT”-post publicerad på det speciella namnet _dmarc.dindomän. Inuti den finns ett par korta instruktioner. Två av dem spelar mest roll, och de är precis de två saker den här bedömningen kontrollerar.

1. Policyn (p=) — vaktens order. Det här är den tungviktade delen av kontrollen. Det kan vara en av tre saker:

p=none — bevaka endast. Vakten noterar vem som kom igenom men stoppar ingen. Det här skyddar dig mot ingenting; det är ett övervakningssteg, inte en färdig installation. (Vår motor betygsätter det som underkänt — bättre än ingen DMARC alls, men inget skydd.)
p=quarantine — skicka förfalskningar till skräppost. Verkligt skydd, men en bestämd angripare räknar med att folk kollar sin skräppostmapp. Ett solitt mellansteg — ger ungefär halvt betyg.
p=reject — avvisa förfalskningar vid dörren. Det förfalskade e-postmeddelandet levereras aldrig. Det här är det enda alternativet som fullt ut skyddar dig och ger fullt betyg.

Vad “bra” ser ut som: p=reject. Allt annat lämnar ett gap.

Två tekniska detaljer vår kontroll också tittar på, värda att känna till så att du inte fastnar:

Subdomän-policyn (sp=). Du kan sätta en stark policy för din huvuddomän men av misstag lämna subdomäner (som mail.dindomän eller news.dindomän) helt öppna. Vår motor straffar detta hårt — en domän med p=reject men sp=none betygsätts ned nära att inte ha någon verkställighet alls, för angripare kommer helt enkelt att förfalska en subdomän istället. God praxis är att låta sp ärva din starka huvudpolicy, eller sätta den till reject uttryckligen.
Procentandelen (pct=). Under en noggrann utrullning kan du tillämpa verkställighet på bara en bråkdel av e-post (t.ex. pct=25). Det är ett legitimt övergångsverktyg, men en partiell utrullning ger bara partiellt skydd, och vår betygsättning återspeglar det — det stiger stadigt när du rör dig från 25% mot 100%, men fullt betyg kräver full täckning.

2. Rapporteringsadressen (rua=) — din synlighet. Det är den andra kontrollen på den här sidan. rua=-taggen ber varje e-postleverantör i världen att skicka dig en daglig sammanfattning av vem som försökte skicka e-post som din domän — dina egna system och eventuella utpekare. Utan den flyger du blint: du har ingen aning om vem som missbrukar ditt namn. Med den upptäcker företag regelbundet mellan 5 och 50 obehöriga avsändare dag ett.

Vad “bra” ser ut som för rapportering: en giltig rua=mailto:-adress (eller en rapporteringstjänsts https:-URL) som faktiskt tar emot rapporterna. Vår kontroll validerar formatet — en felstavad eller felformad adress innebär att rapporterna tyst går ingenstans, vilket betygsätts som ett partiellt eller underkänt resultat även om en tagg tekniskt sett är “på plats.”

Så här åtgärdar du det (gratis, ~30 minuter fördelat på två veckor)

Skicka det här avsnittet till den som hanterar din domän, webbplats eller IT — åtgärden är helt gratis. Vi tar bara betalt för att övervaka att det förblir korrekt över tid, för att hantera en portfölj av domäner eller för en revision. Själva ändringen kostar ingenting.

Den gyllene regeln: hoppa aldrig direkt till reject. Slå på övervakning först, titta på rapporterna, bekräfta att din riktiga e-post känns igen, strama sedan åt. Gjort i den här ordningen är det säkert; gjort i hast kan det sortera bort din egen e-post.

Steg 1 — Se till att SPF och DKIM är på plats först. DMARC förlitar sig på dem. Om något av dem saknas, ta hand om det innan du verkställer DMARC (se SPF- och DKIM-sidorna).

Steg 2 — Publicera en övervakningspost med rapportering aktiverad. Lägg till en DNS TXT-post:

Värd / namn: _dmarc.dindomän (din DNS-leverantör kan visa det som bara _dmarc)
Typ: TXT
Värde: v=DMARC1; p=none; rua=mailto:dmarc@dindomän; adkim=s; aspf=s

Det här bevakar och rapporterar utan att blockera något än. Delarna adkim=s; aspf=s begär strikt justering — utelämna dem till en början om du är osäker, och lägg till dem när din e-post bekräftats ren.

Steg 3 — Läs rapporterna i ~2 veckor. Råa DMARC-rapporter är täta XML. Använd en gratis rapporteringstjänst (till exempel dmarcian eller Postmarks gratis DMARC-verktyg) för att förvandla dem till en läsbar instrumentpanel. Bekräfta att varje legitim avsändare — din brevlådeleverantör, nyhetsbrevverktyg, CRM, helpdesk, fakturaapp — klarar kontrollen. Åtgärda eventuella äkta avsändare som inte gör det.

Steg 4 — Flytta till quarantine. När din riktiga e-post är ren, ändra p=none till p=quarantine. Titta ytterligare några dagar.

Steg 5 — Flytta till reject. Ändra slutligen p=quarantine till p=reject. Du är nu fullt skyddad. Den slutliga posten ser ut så här:

v=DMARC1; p=reject; rua=mailto:dmarc@dindomän; adkim=s; aspf=s

Steg 6 — Glöm inte subdomäner. Se till att du inte har lämnat sp=none på plats. Om du inte publicerar någon sp alls ärver subdomäner din huvud-p=-policy, vilket är vad du vill.

Plattformsanteckningar:

Google Workspace / Microsoft 365: Båda stöder fullt DMARC. DMARC-posten i sig går i din DNS-leverantör, inte i Google eller Microsofts adminkonsol — se till att SPF och DKIM är aktiverade i adminkonsolen först, publicera sedan DMARC TXT-posten hos din registrar/DNS-värd.
Cloudflare: DNS > Poster > Lägg till post > TXT, namn _dmarc, klistra in värdet. Cloudflare erbjuder också inbyggd DMARC-hantering som kan ställa in det här och samla in rapporterna åt dig.
Vanliga värdar / registrarer: Leta efter “DNS”, “DNS-zon” eller “Avancerad DNS”, lägg till en TXT-post med namnet _dmarc och värdet ovan. Spridning tar vanligtvis några minuter till en timme.

Vanliga misstag

Stanna vid p=none. Det vanligaste felet med stor marginal. Övervakning är starten, inte slutet — en domän fast på none är fortfarande fullt förfalskningsbar. Vår motor betygsätter det som underkänt av just det skälet.
Hoppa direkt till reject utan övervakning. Det motsatta misstaget. Utan rapporteringsfasen kanske du inte inser att en legitim avsändare (ofta ett nyhetsbrev eller faktureringsverktyg) inte är justerad — och du börjar blockera din egen e-post.
Glömma subdomänpolicyn. En stark p=reject med sp=none lämnar en sidodörr vidöppen; angripare förfalskar då helt enkelt en subdomän istället.
En trasig rapporteringsadress. En felstavad rua= (eller en som saknar mailto:-prefixet) innebär att rapporterna går ingenstans och att du förblir blind utan att inse det. Formatet måste vara en giltig mailto:- eller https:-URI, annars levereras rapporterna aldrig.
“Vi skickar ingen e-post så vi skippar det.” En icke-sändande domän är ett prima mål just för att ingen bevakar den. Publicera en strikt reject-policy för att låsa den helt.

En notering om betygsättning

Policy-kontrollen (p=) är ett av de tyngst vägda objekten i hela bedömningen — för att det är den enda viktigaste faktorn i om ditt företag kan utges för att vara av någon annan. reject ger fullt betyg; quarantine ger ungefär hälften; none och en saknad post betygsätts som underkänt. En svagare subdomänpolicy eller en partiell pct=-utrullning drar ned betyget för att matcha den verkliga skyddsnivån du faktiskt har.

Rapporterings-kontrollen (rua=) bär verklig vikt också, men tänk på det mindre som en ruta att bocka av och mer som verktyget som låter dig nå reject säkert. Aktivera det samtidigt som din övervakningspost, och det betalar sig i synlighet dag ett.

Konfigurera det hos din leverantör

Steg för steg för populära leverantörer:

Vanliga frågor

Jag är inte alls teknisk — kan jag faktiskt lösa det här?

Ja, men du behöver inte göra det personligen. Åtgärden är ett par rader som läggs till i din domäns inställningar, och den är gratis. Den enklaste vägen är att skicka avsnittet 'Så här åtgärdar du det' nedan till den som driver din webbplats eller ditt IT-stöd. Det tar dem vanligtvis under en timme, fördelat på ett par veckor av säker övervakning.

Kan det hända att min egen e-post sluta levereras om jag aktiverar DMARC?

Det kan hända — men bara om du hoppar över den säkra utrullningen. Hela poängen med att börja på 'övervaka endast' (p=none) med rapportering aktiverad är att titta i två veckor och bekräfta att varje legitim avsändare (din brevlåda, ditt nyhetsbrevverktyg, din fakturaapp) korrekt känns igen INNAN du byter till blockering. Gjort i den ordningen påverkas inte din riktiga e-post. Att rusa direkt till 'reject' utan att kontrollera rapporterna är det enda vanliga misstaget som bryter leveransen.

Vi har redan SPF och DKIM inställda. Räcker inte det?

Nej — och det här är den viktigaste punkten att förstå. SPF och DKIM är låsen; DMARC är instruktionen som säger 'om låsen inte stämmer, avvisa e-postmeddelandet.' Utan DMARC på 'reject' kan en mottagarserver märka att ett e-postmeddelande är förfalskat och ändå leverera det. SPF och DKIM är förutsättningar för att DMARC ska fungera, men på egen hand stoppar de inte ett förfalskat e-postmeddelande från att nå inkorgen.

Vad är skillnaden mellan 'none', 'quarantine' och 'reject'? Vilket behöver jag?

'none' övervakar och rapporterar bara — det stoppar ingenting, så det skyddar dig inte. 'quarantine' skickar förfalskningar till skräppostmappen. 'reject' vägrar dem direkt, så de anländer aldrig. 'reject' är målet och den enda inställningen som ger fullt betyg. 'quarantine' är ett rimligt mellansteg; 'none' är en startpunkt för de första veckorna, inte ett slutmål.

Vad är det här 'rua'-rapporteringssaken, och behöver jag det?

rua-taggen ber e-postleverantörer skicka dig en daglig sammanfattning av varje system som försökte skicka e-post som din domän — inklusive bedragarna. Det är hur företag upptäcker de 5 till 50 obehöriga avsändarna som typiskt missbrukar en domän dag ett. Den bär ensam mindre vikt än policyn, men det är hur du säkert rör dig mot 'reject' utan att bryta din riktiga e-post, så aktivera den samtidigt.

Vi skickar knappt e-post, eller skickar ingen e-post från den här domänen alls. Behöver vi fortfarande DMARC?

Speciellt då. En domän som skickar lite eller ingen riktig e-post är ett perfekt, lågbullersmål för bedragare att utge sig för att vara, för ingen bevakar den. En domän du aldrig skickar e-post från bör publicera en strikt reject-policy — det är en ren, lågriskseger som stänger dörren helt.