Et grønt «pass» beviser mindre enn du tror: slik leser du hodet i en phishing-e-post, audio
Lytt til denne veiledningen, lest opp av Finn.
Meldingen som besto alle sjekker
En kort e-post kommer fra en person i et programvareselskap du har hørt om. Den nevner virksomheten din, stiller ett vennlig spørsmål om å vinne flere kunder og slutter med «si fra hvis dette er irrelevant». Det er ingen lenker og ingen vedlegg. E-postleverandøren din viser SPF pass, DKIM pass og DMARC pass.
De fleste leser det og slapper av. Sjekkene gjorde jobben sin, og de sier likevel svært lite, fordi de svarer på et smalere spørsmål enn det du stiller. Denne veiledningen går gjennom hva hver sjekk faktisk sier, hvor i hodet du bør lete i stedet, og hva du gjør med funnene. Eksemplene kommer fra to reelle saker vi så på i september 2026. Domenenavn er erstattet med plassholdere som ender på .example, og verken personer eller virksomheter er navngitt.
Hva de tre sjekkene svarer på
| Sjekk | Spørsmålet den svarer på | Spørsmålet den ikke svarer på |
|---|---|---|
| SPF | Har avsenderserveren lov til å sende for domenet i konvoluttavsenderen? | Er domenet det selskapet det ser ut til å være? |
| DKIM | Er meldingen signert med en nøkkel som domenet i d= kontrollerer, og er den uendret? |
Hvem kontrollerer domenet? |
| DMARC | Passer domenet i synlig Fra-adresse sammen med et SPF- eller DKIM-pass? | Om Fra-domenet er til å stole på |
Alle tre bekrefter at et domene godkjente en melding. Ingen av dem sier om du bør stole på domenet. En angriper som registrerer sales-tool8.example kan publisere en feilfri SPF-post, signere med DKIM og sette DMARC-policy til none, og alle sjekker består for angriperens eget domene. I den første saken hadde det virkelige selskapet en streng DMARC-policy med reject, og den ble aldri aktivert, fordi meldingen aldri hevdet å komme fra selskapets domene noe sted en maskin leser. Etterligningen lå i visningsnavnet og selskapsnavnet i signaturen.
Et grønt pass på et lookalike-domene er hvordan en godt bygd etterligning ser ut.
Hvor du bør lete i stedet
Åpne hele hodet, ikke sammendraget. De fleste e-postprogram kaller det «vis kilde», «vis original» eller «vis topptekster».
1. Sammenlign tre navn. Visningsnavnet, adressen i From: og adressen i Return-Path:. Et visningsnavn kan si hva som helst. Domenet etter @ er identiteten som teller, og Return-Path viser hvem avsendersystemet mente var ansvarlig.
2. Les domenet, og slå det så opp. Et registreringsoppslag over RDAP gir registrar og opprettelsesdato. I den første saken var avsenderdomenet fire måneder gammelt, mens selskapet det navnga har eksistert i årevis. Et ungt domene som utgir seg for et gammelt selskap er et sterkt signal i seg selv.
3. Sammenlign DNS for avsender og det virkelige selskapet side om side. Se på navnetjenere, e-postservere, SPF og DMARC. Et ekte selskaps domener ligner ofte hverandre. Etterlignerens så ut som en helt annen organisasjon, med en annen DNS-vert, en annen e-postplattform og en svak DMARC-policy.
4. Se etter søsken. Hvis domenet ender på et siffer, prøv naboene. I den første saken brukte avsenderen nummer åtte i en nummerert serie, og alle ni domenene fantes, med samme navnetjenere, samme registrar og samme type e-postvert. Det mønsteret betyr en sendeflåte bygd for å brenne domener etter hvert som de blir blokkert, og det er sjelden tilfeldig.
5. Stol bare på din egen leverandørs dom. Hodet Authentication-Results skrives av serveren som mottok e-posten. Den øverste er din. Linjer lenger ned ble skrevet av tidligere ledd og kan forfalskes av avsenderen. RFC 8601 beskriver denne tillitsgrensen.
6. Se på hvordan den ble levert inn. I en Received-linje betyr ESMTPSA at avsenderen logget inn for å sende meldingen. Det er normalt for en ekte postboks og sier verken noe godt eller dårlig i seg selv. Det blir interessant sammen med neste punkt.
Når passet er ekte og e-posten likevel er dårlig
Den andre saken hadde motsatt form. E-posten kom fra en liten bedrifts eget domene. DKIM stemte mot domenets nøkkel, og meldingen ble sendt inn med innlogging. Ingenting var forfalsket. Bedriftens postboks var overtatt og ble brukt til å sende en falsk påloggingsside.
En gyldig signatur fra et domene beviser at noe med tilgang til domenets e-postsystem sendte meldingen. Den beviser ikke at eieren gjorde det. Her var den riktige tolkningen at domenets eier var et offer, og den riktige handlingen var å varsle dem. Behandle passet som bevis på hvem som sendte, og still deretter det neste spørsmålet, nemlig om innholdet er noe den avsenderen noen gang ville sendt. En påloggingslenke i e-post fra en rørlegger er det ikke.
En melding uten nyttelast
Den første saken hadde ingen lenke, intet vedlegg og 231 byte ren tekst. Det får den til å se harmløs ut, og den kan være vanlig kald salgs-e-post fra en slurvete leverandør. Det er også slik en totrinnsmetode åpner: et svar bekrefter at adressen er levende og leses av et menneske, og lenken eller dokumentet kommer i melding nummer to. Vi kunne ikke avgjøre hvilket det var, og vi trengte det ikke. Rådet er det samme uansett.
Ett lite kjennetegn var verdt å notere. Avsenderens egen adresse var skrevet på én måte i From-linjen og på en annen i adressen domenets egne DMARC-rapporter ble sendt til. Folk som bygger flåter i stor skala gjør slike små feil, og ekte ansatte staver sjelden sin egen adresse feil.
En rutine du kan gjenta
- Ikke svar og ikke klikk. Et svar er det en førstetrinnsmelding er ute etter.
- Åpne hele hodet og sammenlign visningsnavn, Fra-domene og Return-Path.
- Slå opp Fra-domenets registreringsdato og registrar over RDAP.
- Sammenlign DNS med det virkelige selskapets.
- Se etter nummererte eller nesten like søskendomener.
- Les din egen leverandørs
Authentication-Results, og bare den. - Hvis et pass er ekte, spør hvem sin postboks det var og om dette er noe de ville sendt.
- Rapporter det, og ta vare på originalmeldingen som fil og ikke som videresending.
Slik rapporterer du
Si fra til selskapet som etterlignes, fordi de kan handle på sitt eget merkenavn. Si fra til registraren for avsenderdomenet, hvis misbrukskontakt står i RDAP-oppføringen. Si fra til e-postplattformen som fraktet meldingen. Hvis en legitim bedrifts postboks ble brukt, si fra til den bedriften og gi dem hodene, fordi de kanskje ikke vet det.
Misbrukskontorer er ikke enige om format. Etter vår erfaring vil noen ha originalen som .eml-vedlegg, noen vil ha hodene limt inn som ren tekst, og noen tar bare imot et nettskjema. Les kontorets egne instruksjoner først. Husk også at en levert rapport ikke er det samme som en registrert, så se etter svar eller saksnummer.
Hva vi ikke gjorde
Vi så på DNS, offentlige registreringsdata og hodene i meldingene vi hadde mottatt. Vi klikket ikke på noe og svarte ikke.
Hva denne veiledningen ikke kan fortelle deg
DNS- og registreringsdata endrer seg, og alt ovenfor beskriver det vi målte i september 2026. En søskenserie som finnes i dag kan være borte neste måned. Testene reduserer usikkerheten, men kan ikke bevise hensikt. Hvis en melding ber om penger, påloggingsopplysninger eller en beslutning, verifiser den over en kanal du allerede stoler på, for eksempel et telefonnummer du har funnet selv.
Kilder
- RFC 7208, Sender Policy Framework (SPF)
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 8601, Message Header Field for Indicating Message Authentication Status
- RFC 9082 og RFC 9083, Registration Data Access Protocol (RDAP), spørreformat og JSON-svar
Standardenes tekst gjelder. Der denne veiledningen og en RFC er uenige, har RFC-en rett, og vi vil gjerne høre om det.