Läsa avsändare och headers

Modul 3: Känna igen phishing · Lästid: 13 minuter

Lärandemål: Efter den här lektionen kan du bedöma avsändaren av ett mejl utifrån visningsnamnet, From-adressen, Reply-To, Return-Path, Received-raderna och resultatet av SPF, DKIM och DMARC i Authentication-Results.
Nyckelbegrepp: visningsnamn, From, Reply-To, Return-Path, Received, Authentication-Results, SPF/DKIM/DMARC-resultat, uppriktning (alignment)

Vad du ser och vad som egentligen står där

Ett e-postprogram visar oftast bara en liten del av avsändaren: ett namn, ibland en adress. Bakom det ligger ett block tekniska rader som du inte ser, headers. Där står vem mejlet säger sig vara, vart svar ska skickas, via vilka servrar det kommit och vad din e-postserver har kontrollerat.

Du behöver inte vara tekniker för att läsa dem. Du behöver känna till sex stycken:

De första tre kan en avsändare skriva precis vad den vill i. Först vid de tre sista sker en faktisk kontroll.

Visningsnamnet säger ingenting

Det visningsnamnet är bara text. Vem som helst kan som namn använda "Mijnbank Klantenservice" eller namnet på din vd. Många e-postprogram, särskilt på mobilen, visar bara namnet. Ett känt knep är en adress i namnet:

From: "info@mijnbank.example" <noreply@aanvaller.example>

Du ser info@mijnbank.example, men den riktiga adressen står mellan de vinklade parenteserna. Klicka eller tryck därför alltid på namnet för att se hela adressen.

Även själva From-adressen kan förfalskas: i e-postprotokollet får en server ange vilken From-adress som helst. Om det lyckas utan att hamna i skräppostmappen beror på SPF, DKIM och DMARC för domänen som imiteras. Det är vad resten av den här lektionen handlar om.

Reply-To: svar till någon annan

Med Reply-To säger ett mejl: "svara inte till mig, utan till den här adressen." Nyhetsbrev och webbformulär använder det normalt. Bedragare använder det för att ta över en konversation. Mejlet kommer från en äkta eller äkta-liknande adress, men ditt svar, med de begärda uppgifterna eller bekräftelsen av betalningen, går till angriparen.

From: Leverancier Meel <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>

Kontrollera alltid adressen i svarsfönstret vid en begäran om pengar eller uppgifter, innan du klickar på Skicka.

Return-Path, Received och vägen

Det Return-Path är adressen dit felmeddelanden skickas. Det kallas även kuvertavsändare: adressen på kuvertets utsida, medan From står på själva brevet. Det är den domänen som SPF kontrollerar. Vid nyhetsbrev och fakturor från ett bokföringsprogram är Return-Path ofta en domän från utskicksleverantören. Det är normalt.

Varje server som skickar vidare mejlet lägger till en Received-rad överst. Du läser dem alltså underifrån och upp: den understa raden är början på vägen, den översta den sista stationen (din egen e-postserver). Observera: det är bara de översta raderna, som din egen leverantör har lagt till, som du kan lita på. Längre ner kan en avsändare ha skickat med påhittade rader.

Authentication-Results: kontrollresultatet

Din egen e-postserver kontrollerar vid mottagning tre saker (mer förklaring i modul 4 och DNS-kursen):

• SPF: fick den här servern skicka mejl för domänen i Return-Path?
• DKIM: stämmer den digitala signaturen, och från vilken domän är den (d= eller header.d=)?
• DMARC: hör minst en av dessa två godkända kontroller ihop med domänen i From? Det kallas uppriktning (alignment). "Hör ihop med" betyder: samma registrerbara domän (lektion 3.2). mail.mijnbank.example är uppriktad med mijnbank.example (samma registrerbara domän).

Resultatet står i Authentication-Results. Lita bara på raden med namnet på din egen e-postserver först; en avsändare kan också själv skicka med en sådan rad.

Den viktigaste lärdomen: dmarc=pass betyder bara "det här mejlet kommer verkligen från domänen i From". Det säger ingenting om huruvida den domänen går att lita på. En angripare med sin egen lookalike-domän kan ha allt prydligt på pass.

I praktiken: så här ser det ut

Tre efterbildade headerblock, förkortade till de rader som spelar roll. Mottagaren är Bakkerij Example; den egna e-postservern heter mx1.example.com.

Exempel 1: äkta.

Return-Path: <bounce-7731@mail.mijnbank.example>
Received: from out3.mail.mijnbank.example (out3.mail.mijnbank.example [198.51.100.40])
	by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 09:14:06 +0100
Authentication-Results: mx1.example.com;
	spf=pass smtp.mailfrom=mail.mijnbank.example;
	dkim=pass header.d=mijnbank.example header.s=sel2026;
	dmarc=pass (p=reject) header.from=mijnbank.example
From: Mijnbank <info@mijnbank.example>
To: info@example.com
Subject: Din årsöversikt 2026 är klar

From-domänen är mijnbank.example och DKIM är signerat av mijnbank.example och Return-Path hör till samma domän: båda är uppriktade, DMARC godkänns. Mejlet kommer verkligen från den domänen. Gå ändå till banken via din egen bokmärke för årsöversikten.

Exempel 2: förfalskad avsändare.

Return-Path: <x7@mailer.aanvaller.example>
Received: from mailer.aanvaller.example (mailer.aanvaller.example [203.0.113.66])
	by mx1.example.com with ESMTP; Sun, 08 Nov 2026 10:02:41 +0100
Authentication-Results: mx1.example.com;
	spf=pass smtp.mailfrom=mailer.aanvaller.example;
	dkim=none;
	dmarc=fail (p=none) header.from=leverancier.example
From: Leverancier Meel <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>
Subject: Nytt kontonummer

SPF godkänns, men för aanvaller.example, inte för From-domänen. Det finns ingen signatur. DMARC misslyckas alltså. Eftersom leverantören har p=none levererades mejlet ändå. Med p=reject hade det avvisats. Dessutom tillkommer Reply-To till en annan domän. Falskt.

Exempel 3: lookalike med allt på pass.

Return-Path: <service@mijnbank-veilig.example>
Received: from smtp.mijnbank-veilig.example (smtp.mijnbank-veilig.example [192.0.2.77])
	by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 11:20:13 +0100
Authentication-Results: mx1.example.com;
	spf=pass smtp.mailfrom=mijnbank-veilig.example;
	dkim=pass header.d=mijnbank-veilig.example header.s=k1;
	dmarc=pass (p=reject) header.from=mijnbank-veilig.example
From: Mijnbank Klantenservice <service@mijnbank-veilig.example>
Subject: Bekräfta dina uppgifter för det nya betalkortet

Allt godkänns, för angriparen har ställt in allt korrekt för sin egen domän. Men mijnbank-veilig.example är inte mijnbank.example som tillhör den riktiga banken. Falskt.

Öppna headers själv. I webbmejl baserad på Roundcube (som hos WebOké) öppnar du meddelandet och väljer i menyn Mer (de tre punkterna) alternativet Visa källkod. Andra program kallar det till exempel "Visa original" eller "Meddelandekälla". Sök i texten efter Authentication-Results. På mobilen går det ofta inte; öppna då mejlet i webbmejl på en dator.

Sammanfattning

• Visningsnamn, From och Reply-To skriver avsändaren själv. Titta alltid på den riktiga adressen och på Reply-To innan du svarar.
• Return-Path är kuvertadressen som SPF kontrollerar mot. Received-rader läser du underifrån och upp; lita bara på raden från din egen leverantör.
• Authentication-Results visar resultatet av SPF, DKIM och DMARC. DMARC kontrollerar om SPF eller DKIM är uppriktad med From-domänen.
• dmarc=fail hos en känd domän är ett starkt tecken på förfalskning.
• dmarc=pass bevisar bara att mejlet kommer från From-domänen. Kontrollera alltid om den domänen är den äkta.

Quiz

Uppgift

Uppgift A3.3: Läsa headers. Du får tre headerblock. Fyll i per block: domänen i Return-Path, domänen för DKIM-signaturen (d=), DMARC-resultatet och om mejlet är äkta eller falskt. Programmet rättar och visar vid fel var i raden svaret finns.

Läs mer

Stegen i WebOkés artiklar gäller för WebOkés miljö; hos andra leverantörer fungerar det på liknande sätt.

• Vad är DMARC? Förklaring i vanligt språk
• Mitt e-postmeddelande kommer inte fram eller hamnar i skräppost: så tar du reda på varför
• Offentlig e-postkontroll (SPF, DMARC, MX) av en domän: https://www.weboke.se/e-postkontroll, och e-posttestet från internet.nl: https://internet.nl
• DNS-kurs, lektionerna 4.3 SPF, 4.4 DKIM och 4.5 DMARC: https://www.weboke.se/dns-cursus
• RFC 8601, Authentication-Results: https://www.rfc-editor.org/rfc/rfc8601