Defaults.Exposed › Fikser › DMARC (E-postforfalskelsesbeskyttelse)

Slik fikser du DMARC (E-postforfalskelsesbeskyttelse)

DMARC er den ene innstillingen som faktisk forteller verdens e-postleverandører å BLOKKERE e-poster som forfalsker virksomhetens navn. SPF og DKIM sjekker låsene; DMARC bestemmer hva som skjer når en forfalskning feiler sjekken — kast den, flagg den, eller la den gjennom. Satt feil er domenet ditt fullt forfalskbart; satt riktig stoppes imitasjon ved innboksen.

Bunnlinjen for virksomheten din: Uten DMARC-håndhevelse kan en kriminell sende e-post som ser nøyaktig ut som den kom fra virksomheten din — til kunder, ansatte og leverandører — og den lander i innboksen, ikke søppelpost. Folk lures i ditt navn, og de gir deg skylden.

Hva dette kan koste deg

En svindler sender kunden din en ekte-utseende faktura 'fra regnskapsavdelingen din' med sine egne bankdetaljer. Kunden betaler. Du finner det ut uker senere når de jager varene de allerede betalte for — og de holder deg ansvarlig.
En falsk «hastebetaling»-e-post sendes til din økonomiansvarlige, tilsynelatende fra deg som eier. De overfører pengene før noen tenker på å dobbeltsjekke — og når de er på kriminelens konto er det nesten aldri mulig å få dem tilbake.
Et stort prospekts IT-team kjører en sikkerhetsjekk på domenet ditt før de signerer. Det kommer tilbake med «e-post ikke beskyttet — kan forfalskes.» Du taper avtalen til en konkurrent hvis domene bestod.
Domenet ditt brukes i en phishing-bølge. Kunder som ble lurt legger igjen sinte anmeldelser og advarer andre. Omdømmeskaden varer måneder etter angrepet.
Til og med din genuine e-post begynner å bli søppelpostet, fordi Google og Yahoo i økende grad mistror — og nå noen ganger avviser — domener uten håndhevet DMARC.

Hvorfor det er viktig. E-post ble aldri bygget for å bevise hvem som virkelig sendte det, så å forfalske «fra»-adressen er trivielt. DMARC er den eneste kontrollen som forvandler «vi kan oppdage falske» til «falske blir blokkert» — og det gir deg også de daglige rapportene som avslører hvem som sender e-post som merket ditt. Store postboksleverandører behandler nå en manglende eller uhåndhevet DMARC-policy som et tillitssignal mot deg, så dette påvirker om din egen e-post leveres også.

Hva DMARC er, i enkle ord

E-post har en skitten hemmelighet: «fra»-linjen er bare inntastet tekst. Hvem som helst, hvor som helst, kan skrive din virksomhets navn og adresse i «fra»-feltet på en e-post og sende den. Internett ble aldri designet for å stoppe dem.

Det er tre innstillinger som, til sammen, fikser dette. Tenk på dem som sikkerheten i en bygning:

SPF er en liste over hvem som har lov til å komme inn hoveddøren (hvilke e-posttjenester kan sende som deg).
DKIM er et manipulasjonssikkert segl som beviser at meldingen ikke ble endret underveis.
DMARC er sikkerhetsavdelingen som sjekker listen og seglet — og, avgjørende, bestemmer hva som skjer når de ikke stemmer: la det gjennom, send det til søppelpost, eller avvis det ved døren.

Du kan ha listen (SPF) og seglet (DKIM) og likevel ikke ha noen vakt. Det er den vanligste og farligste situasjonen: låsene finnes, men ingenting håndhever dem. DMARC er håndhevelsen. Det er forskjellen mellom «vi kan se at denne e-posten er falsk» og «denne falske e-posten når aldri kunden din.»

Hva dette kan koste deg

Dette er ikke teoretisk. Her er de konkrete måtene et ubeskyttet domene blir til ekte penger og ekte skade:

Falsk-faktura-svindelen. En kriminell sender kunden din en e-post som ser nøyaktig ut som en genuin faktura fra regnskapsavdelingen din — samme navn, samme domene, profesjonelt oppsett — men med sine egne bankdetaljer. Fordi domenet ditt ikke er håndhevet, lander det i innboksen, ikke søppelpost. Kunden betaler. Du oppdager det uker senere når de spør etter bestillingen. Pengene er vanligvis borte, og kunden holder deg ofte ansvarlig for bruddet.
Direktørsvindelen. En e-post ser ut til å komme fra deg, som eier, til din økonomiansvarlige: «Kan du skyve denne betalingen gjennom raskt, jeg er i møte.» Den ser helt ekte ut fordi det er adressen din — bare forfalsket. Betalingen sendes ut. Dette mønsteret — Business Email Compromise — er en av de kostbareste svindeltypene som rammer små virksomheter, nettopp fordi e-posten genuint kommer fra ditt eget domene, slik at den seiler rett gjennom mistanken.
Den tapte kontrakten. Et seriøst prospekt kjører en sikkerhets- eller innkjøpssjekk før de signerer. Verktøyet rapporterer at domenet ditt er «forfalskbart — ingen e-postautentiseringshåndhevelse.» Det ene røde flagget kan være nok til å gi kontrakten til en konkurrent hvis domene bestod. Du hører aldri den virkelige grunnen.
Omdømmeskaden du ikke kan angre. Domenet ditt dras inn i en phishing-kampanje. Dusinvis av folk som ble lurt i ditt navn legger ut advarsler og anmeldelser. Angrepet varer en uke; «er dette selskapet trygt?»-spørsmålet henger i måneder.
Din egen e-post som havner i søppelpost. Google og Yahoo stoler nå aktivt ikke på domener uten håndhevet DMARC. Tilbud, fakturaer og svar du genuint sendte, begynner stille å lande i søppelpostmapper. Avtaler staller og du forstår aldri hvorfor.

Hva det faktisk er (og hva «bra» ser ut som)

DMARC lever som én enkelt tekstlinje i domenets innstillinger — en DNS «TXT»-post publisert ved det spesielle navnet _dmarc.dittdomene. Inne i den er noen korte instruksjoner. To av dem betyr mest, og de er nøyaktig de to tingene denne vurderingen sjekker.

1. Policyen (p=) — vaktens ordre. Dette er den tungt-vektede delen av kontrollen. Den kan være en av tre ting:

p=none — se bare. Vakten noterer hvem som kom gjennom, men stopper ingen. Dette beskytter deg mot ingenting; det er en overvåkingsfase, ikke en ferdig oppsett. (Vår motor scorer dette som feil — bedre enn ingen DMARC i det hele tatt, men ingen beskyttelse.)
p=quarantine — send falske til søppelpost. Ekte beskyttelse, men en målbevisst angriper satser på at folk sjekker søppelpostmappen. Et solid mellomsteg — det gir omtrent halvt score.
p=reject — avvis falske ved døren. Den forfalskede e-posten leveres aldri. Dette er den eneste innstillingen som fullt ut beskytter deg og gir full score.

Hva «bra» ser ut som: p=reject. Alt annet etterlater et gap.

To tekniske detaljer sjekken vår også ser på, verdt å vite slik at du ikke blir tatt på senga:

Subdomain-policyen (sp=). Du kan sette en sterk policy for hoveddomenet ditt, men ved et uhell la subdomener (som mail.dittdomene eller news.dittdomene) stå åpne. Motoren vår straffer dette hardt — et domene med p=reject men sp=none scores nær å ikke ha noen håndhevelse i det hele tatt, fordi angripere rett og slett vil forfalske et subdomene i stedet. God praksis er å la sp arve din sterke hovedpolicy, eller sette den til reject eksplisitt.
Prosentandelen (pct=). Under en nøye utrulling kan du anvende håndhevelse på bare en brøkdel av e-post (f.eks. pct=25). Det er et legitimt overgangsverktøy, men en delvis utrulling gir bare delvis beskyttelse, og scoren vår reflekterer det — den stiger jevnt etter hvert som du beveger deg fra 25% mot 100%, men full score krever full dekning.

2. Rapporteringsadressen (rua=) — din synlighet. Dette er den andre kontrollen på denne siden. rua=-taggen ber hver e-postleverandør i verden om å sende deg et daglig sammendrag av hvem som prøvde å sende e-post som domenet ditt — dine egne systemer og eventuelle etterliknere. Uten det flyr du blindt: du har ingen anelse om hvem som misbruker navnet ditt. Med det oppdager virksomheter rutinemessig mellom 5 og 50 uautoriserte avsendere den aller første dagen.

Hva «bra» ser ut som for rapportering: en gyldig rua=mailto:-adresse (eller en rapporteringstjeneste https:-URL) som faktisk mottar rapportene. Sjekken vår validerer formatet — en feilstavet eller misdannet adresse betyr at rapportene stille forsvinner i ingenting, noe som scores som et delvis eller mislykket resultat selv om en tag teknisk sett er «til stede.»

Slik fikser du det (gratis, ~30 minutter spredt over to uker)

Send denne seksjonen til den som administrerer domenet, nettstedet eller IT-støtten din — fiksen er helt gratis. Vi tar bare betalt for å overvåke at det forblir riktig over tid, for å administrere en portefølje av domener, eller for en revisjon. Selve endringen koster ingenting.

Den gyldne regelen: hopp aldri rett til reject. Slå på overvåking først, se på rapportene, bekreft at den ekte e-posten din er gjenkjent, og stram deretter inn. Gjort i denne rekkefølgen er det trygt; gjort i hast kan det søppelposte din egen e-post.

Steg 1 — Sørg for at SPF og DKIM er på plass først. DMARC er avhengig av dem. Hvis enten mangler, ordne de før du håndhever DMARC (se SPF- og DKIM-sidene).

Steg 2 — Publiser en overvåkingspost med rapportering slått på. Legg til en DNS TXT-post:

Vert / navn: _dmarc.dittdomene (DNS-leverandøren din kan vise dette som bare _dmarc)
Type: TXT
Verdi: v=DMARC1; p=none; rua=mailto:dmarc@dittdomene; adkim=s; aspf=s

Dette overvåker og rapporterer uten å blokkere noe ennå. adkim=s; aspf=s-delene ber om streng justering — la dem stå ute i begynnelsen hvis du er usikker, og legg dem til når e-posten din er bekreftet ren.

Steg 3 — Les rapportene i ~2 uker. Rå DMARC-rapporter er tett XML. Bruk en gratis rapporteringstjeneste (for eksempel dmarcian eller Postmarks gratis DMARC-verktøy) for å gjøre dem om til et lesbart dashbord. Bekreft at alle legitime avsendere — e-postleverandøren din, nyhetsbrevverktøyet, CRM, helpdesk, faktureringsapp — består. Fiks eventuelle genuine avsendere som ikke gjør det.

Steg 4 — Flytt til quarantine. Når den ekte e-posten din er ren, endre p=none til p=quarantine. Se på i noen dager til.

Steg 5 — Flytt til reject. Endre endelig p=quarantine til p=reject. Du er nå fullt beskyttet. Den endelige posten ser slik ut:

v=DMARC1; p=reject; rua=mailto:dmarc@dittdomene; adkim=s; aspf=s

Steg 6 — Ikke glem subdomener. Sørg for at du ikke har latt sp=none stå. Hvis du ikke publiserer noen sp i det hele tatt, arver subdomener din hoved-p=-policy, som er det du ønsker.

Merknader per vanlig plattform:

Google Workspace / Microsoft 365: Begge støtter DMARC fullt ut. Selve DMARC-posten legges i DNS-leverandøren din, ikke i Googles eller Microsofts adminkonsoll — sørg for at SPF og DKIM er aktivert i adminkonsollen først, og publiser deretter DMARC TXT-posten hos registraren/DNS-verten din.
Cloudflare: DNS > Poster > Legg til post > TXT, navn _dmarc, lim inn verdien. Cloudflare tilbyr også innebygd DMARC-administrasjon som kan sette dette opp og samle rapportene for deg.
Vanlige verter / registrarer: Se etter «DNS», «DNS-sone» eller «Avansert DNS», legg til en TXT-post med navn _dmarc og verdien ovenfor. Spredning tar vanligvis noen minutter til en time.

Vanlige feil

Stoppe ved p=none. Den vanligste feilen suverent. Overvåking er starten, ikke slutten — et domene som sitter fast på none er fortsatt fullt forfalskbart. Motoren vår scorer det som feil av nøyaktig denne grunnen.
Hoppe rett til reject uten overvåking. Den motsatte feilen. Uten rapporteringsfasen kan du ikke innse at en legitim avsender (ofte et nyhetsbrev- eller faktureringsverktøy) ikke er justert — og du vil begynne å blokkere din egen e-post.
Glemme subdomainpolicyen. En sterk p=reject med sp=none etterlater en sidedør vidåpen; angripere forfalsker bare et subdomene i stedet.
En ødelagt rapporteringsadresse. En feilstavet rua= (eller en som mangler mailto:-prefikset) betyr at rapportene går ingen steder og du forblir blind uten å innse det. Formatet må være en gyldig mailto: eller https: URI, eller rapportene leveres aldri.
«Vi sender ikke e-post, så vi hopper over det.» Et ikke-sendende domene er et prime mål nettopp fordi ingen passer på det. Publiser en streng reject-policy for å låse det helt ned.

En merknad om scoring

Policy-sjekken (p=) er ett av de tyngst-vektede elementene i hele vurderingen — fordi det er den enkeltfaktoren som i størst grad avgjør om virksomheten din kan etterlighnes. reject gir full score; quarantine gir omtrent halvt; none og manglende post scores som feil. En svakere subdomainpolicy eller en delvis pct=-utrulling trekker scoren ned til å matche det virkelige beskyttelsesnivået du faktisk har.

Rapportering-sjekken (rua=) bærer også reell vekt, men tenk på det mindre som en boks å huke av og mer som verktøyet som lar deg nå reject trygt. Sett det opp samtidig som overvåkingsposten din, og det betaler for seg selv i synlighet fra dag én.

Sett det opp hos din leverandør

Trinn for trinn for populære leverandører:

FAQ

Jeg er overhodet ikke teknisk anlagt — er dette noe jeg faktisk kan ordne?

Ja, men du trenger ikke gjøre det personlig. Fiksen er et par linjer som legges til i domeneinnstillingene dine, og det er gratis. Den enkleste veien er å sende «Slik fikser du det»-seksjonen nedenfor til den som driver nettstedet ditt eller IT-støtten. Det tar dem vanligvis godt under en time, spredt over et par uker med trygg overvåking.

Vil det å slå på DMARC ved et uhell stoppe mine egne e-poster fra å nå frem?

Det kan det — men bare hvis du hopper over den trygge utrullingen. Hele poenget med å starte på «overvåk bare» (p=none) med rapportering slått på er å se i to uker og bekrefte at alle legitime avsendere (postboksen din, nyhetsbrevverktøyet ditt, faktureringsappen) er korrekt gjenkjent FØR du bytter til blokkering. Gjort i den rekkefølgen påvirkes ikke den ekte e-posten din. Å skynde seg rett til «reject» uten å sjekke rapportene er den ene vanlige feilen som ødelegger leveransen.

Jeg har allerede satt opp SPF og DKIM. Er ikke det nok?

Nei — og dette er det viktigste punktet å forstå. SPF og DKIM er låsene; DMARC er instruksjonen som sier «hvis låsene ikke stemmer, avvis e-posten.» Uten DMARC ved «reject» kan en mottakende server legge merke til at en e-post er forfalsket og likevel levere den. SPF og DKIM er forutsetninger for at DMARC skal virke, men alene forhindrer de ikke en forfalsket e-post fra å nå innboksen.

Hva er forskjellen mellom 'none', 'quarantine' og 'reject'? Hva trenger vi?

'none' overvåker og rapporterer bare — det stopper ingenting, så det beskytter deg ikke. 'quarantine' sender forfalskninger til søppelpostmappen. 'reject' avviser dem direkte, så de ankommer aldri. 'reject' er målet og den eneste innstillingen som gir full score. 'quarantine' er et fornuftig mellomsteg; 'none' er et startpunkt for de første ukene, ikke en destinasjon.

Hva er dette 'rua'-rapporteringsopplegget, og trenger jeg det?

rua-taggen ber e-postleverandører sende deg et daglig sammendrag av alle systemer som prøvde å sende e-post som domenet ditt — inkludert kriminelle. Det er slik virksomheter oppdager de 5 til 50 uautoriserte avsenderne som typisk misbruker et domene på dag én. Alene bærer det mindre vekt enn policyen, men det er slik du trygt beveger deg til 'reject' uten å ødelegge din ekte e-post, så sett det opp samtidig.

Vi sender knapt e-post, eller sender ikke e-post fra dette domenet i det hele tatt. Trenger vi likevel DMARC?

Spesielt da. Et domene som sender lite eller ingen ekte e-post er et perfekt, lite støyende mål for kriminelle å etterligne, fordi ingen passer på det. Et domene du aldri sender e-post fra bør publisere en streng reject-policy — det er en ren, lav-risiko gevinst som smeller igjen døren helt.