Lese headere: hvor kom denne e-posten fra?

Modul 1: Hvordan e-post fungerer · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du åpne headerne til en e-post, lese Received-linjene i riktig rekkefølge og finne ut fra Authentication-Results om SPF, DKIM og DMARC stemte.

Nøkkelbegreper: headere (headers), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, X-headere, kilde eller originalmelding

Det du vanligvis ikke ser

E-postprogrammet ditt viser noen få linjer av en e-post: avsender, emne, dato, mottakere. I virkeligheten har hver e-post titalls headere (headers) øverst, før selve teksten. De blir lagt til av programmet til avsenderen og av hver server som e-posten er innom underveis. Sammen utgjør de reiseloggen til e-posten.

Den som kan lese headere, kan svare på mye selv: er denne e-posten virkelig fra banken min? Hvorfor kom den først etter to timer? Hvorfor havnet den i spam? Stemmer min egen DKIM? Mange oppgaver i dette kurset ber deg se på headere. I denne leksjonen lærer du hvordan.

Åpne headere

Hvert program har sin egen knapp for dette:

På en telefon går det vanligvis ikke. Send i så fall e-posten videre til deg selv som vedlegg, eller åpne den i webmailen.

Et eksempel

Jan mottar en e-post fra Anna. Slik ser de viktigste headerne ut (forkortet):

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Received-linjer: nedenfra og opp

Hver server som sender e-posten videre, setter en Received:-linje øverst. Den eldste står altså nederst, den nyeste øverst. Les dem nedenfra og opp for å følge reisen:

1. Nederste linje: Annas bærbare (IP 198.51.100.77, hennes hjemmetilkobling) leverer til out.hosting.example, med ESMTPSA (A-en står for authenticated: hun logget inn) og TLS 1.3. Klokken 10:15:04.
2. Midterste linje: out.hosting.example (192.0.2.25) leverer til mx1.mailprovider.example, MX-en til example.net. Klokken 10:15:07.
3. Øverste linje: mailserveren legger e-posten internt i Jans mailboks (LMTP). Klokken 10:15:09.

En Received-linje har alltid formen from <hvem som tilbød den> by <hvem som tok imot den> with <protokoll>; <tidspunkt>. I parentes etter from står det den mottakende serveren selv observerte: det reelle navnet (PTR) og den reelle IP-adressen. Den delen er pålitelig så langt du stoler på den mottakende serveren. Det avsenderen selv oppga (helo=) kan ikke kontrolleres.

To praktiske triks:

• Finne forsinkelser: sammenlign tidspunktene. Er det to timer mellom to linjer, har e-posten stått like lenge i en kø der. Vær oppmerksom på tidssoner (+0100, +0000).
• Finne den reelle avsenderserveren: finn den øverste Received-linjen som er skrevet av en server hos mottakeren selv, og se hva som står etter from der. Alt under det er skrevet av den sendende siden og kan i teorien være diktet opp. I eksempelet er 192.0.2.25 serveren som leverte hos mottakeren; det er den SPF og omdømmet vurderes mot.

Adressene

Et kjent triks blant svindlere: en From som ligner på banken din, med en Reply-To til en helt annen adresse. Se ved tvil alltid på domenet i From og i Return-Path, og på Authentication-Results.

Authentication-Results: mottakerens vurdering

Den mottakende serveren setter i Authentication-Results (RFC 8601) hva kontrollene ga:

• spf=pass smtp.mailfrom=example.com: IP-adressen til serveren som leverte, står i SPF-recorden til domenet i Return-Path.
• dkim=pass header.d=example.com header.s=x: DKIM-signaturen til domenet example.com, med nøkkel (selector) x, stemmer.
• dmarc=pass header.from=example.com: domenet i From er justert med en vellykket SPF eller DKIM, så DMARC er godkjent.

Andre utfall du kan se: fail (stemmer ikke), softfail (SPF ender på ~all og IP-en står ikke der), neutral, none (ingen record), temperror (midlertidig DNS-feil) og permerror (recorden er ødelagt, for eksempel to SPF-recorder). Hva disse betyr nøyaktig og hvordan du fikser dem, står i modul 4.

Vær oppmerksom på: stol bare på Authentication-Results fra mottakerens egen server (navnet først, her mx1.mailprovider.example). En forfalsket e-post kan sende med sin egen, diktede Authentication-Results. Gode servere fjerner den, men ikke alle gjør det.

DKIM-Signature: selve signaturen

Headeren DKIM-Signature er selve signaturen. To felt trenger du ofte:

• d= domenet som signerer (her example.com);
• s= selectoren, navnet på nøkkelen (her x).

Med disse finner du den offentlige nøkkelen i DNS: x._domainkey.example.com. I oppgaver og ved problemer må du ofte slå opp nøyaktig disse to verdiene. En e-post kan ha flere DKIM-signaturer, for eksempel en fra ditt eget domene og en fra utsendingstjenesten. I leksjon 4.3 går vi dypere inn i dette.

Noen ganger ser du også ARC-Seal, ARC-Message-Signature og ARC-Authentication-Results. ARC (RFC 8617) er en måte mellomstasjoner, som en e-postliste eller en videresendingsserver, dokumenterer hva kontrollene var før de endret e-posten. Du trenger ikke kunne lese dem ennå.

X-headere

Headere som begynner med X- er ikke standardiserte. Spamfiltre setter inn sin score der, som X-Spam-Status: No, score=1.2 eller X-Spam-Flag: YES. Det hjelper å se hvorfor noe havnet i spam. De varierer mellom leverandører.

Oppsummering

• Headere er reiseloggen til en e-post. Åpne dem med "vis original", "meldingskilde" eller noe lignende.
• Les Received-linjer nedenfra og opp. Linjen som mottakerens server skrev, forteller hvilken IP som leverte.
• Return-Path er envelope sender (SPF), From er den synlige avsenderen (DMARC), Reply-To er hvor svar går.
• Authentication-Results gir vurderingen av SPF, DKIM og DMARC; stol bare på den fra den mottakende serveren.
• I DKIM-Signature står d= (domene) og s= (selector); sammen gir de plasseringen til nøkkelen: s._domainkey.d.

Quiz

Oppgave

Oppgave Z1.5: La headere bli tolket. Send deg selv en e-post fra en annen adresse (for eksempel fra jobbadressen til privatadressen din, eller omvendt), åpne headerne og lim dem inn i skjemaet. Har du ikke en annen adresse, bruk eksempelfilen kopregels-1.txt som følger med oppgaven. Fyll deretter inn selv: IP-adressen til serveren som leverte hos mottakeren, domenet i Return-Path, domenet og selectoren til DKIM-signaturen, og utfallet av SPF, DKIM og DMARC. Programmet tolker de samme headerne, slår opp DKIM-nøkkelen live og setter sitt resultat ved siden av ditt. Headerne dine blir ikke lagret.

Les mer

Trinnene i disse artiklene gjelder for panelene til WebOké; hos andre leverandører fungerer det på lignende måte.

• Kontrollere om e-post har kommet frem med e-postsporing i DirectAdmin
• DirectAdmin-veiledning 9.3: E-mail Tracking: hvor ble det av e-posten min?
• Er denne e-posten virkelig fra WebOké? Gjenkjenne phishing og bruke aksjonskoden
• Gratis DNS-kurs 4.4: DKIM: signaturen under e-posten din
• RFC 5322 (oppbygningen av en e-post), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)