Analyse af mail‑headere, SPF, DKIM og DMARC

Forside › E-mail forensics · Gennemgået oktober 2026 · Af John Nielsen

En mail-header kan ikke læses ud fra ét felt. Den tekniske analyse bygger på tre lag: den rute, mailen har taget (Received-kæden), modtagerserverens egne kontrolresultater (Authentication-Results) og den kryptografiske DKIM-signatur, som kan efterprøves selvstændigt. Tilsammen kan de vise, om mailen er afleveret fra en server, der havde ret til at sende for domænet, og om indholdet er ændret siden. De kan ikke vise, hvilken person der skrev den.

Denne artikel går i dybden med de tre lag. Hvordan headerne indgår i den samlede vurdering af, om en mail er ægte, står i Er mailen ægte? En samlet metode. Grundbegreberne er beskrevet i Mail-headere: hvem sendte mailen?.

Udgangspunktet: den originale mail

Analysen kræver mailen med alle headere i uændret form, fx som EML- eller MSG-fil eksporteret fra postkassen eller hentet via eDiscovery. En videresendt mail, en udskrift eller en PDF har mistet de oprindelige headere, og en mail, der er åbnet og gemt igen i en mailklient, kan have fået ændret kodning eller linjeskift, så DKIM-signaturen ikke længere kan efterprøves. Den praktiske fremgangsmåde for brugere er beskrevet i Sådan gemmer du en mail korrekt. I Microsoft 365 er en eksport via Microsoft Purview eDiscovery ofte det mest robuste udgangspunkt.

Sikr helst både modtagerens og afsenderens eksemplar. Afsenderens kopi i Sendt post har ingen Received-linjer fra modtagersiden, men kan indeholde interne headere, der mangler hos modtageren.

Received-kæden

Hver server, der håndterer mailen, tilføjer en Received-linje øverst. Kæden læses derfor nedefra og op. Pålideligheden afhænger af, hvem der har skrevet linjen:

Øverste linjer, skrevet af modtagerens egne servere · Høj, så længe modtagerens systemer ikke er kompromitteret
Linjen, hvor modtagerens server modtog fra internettet · Den afgørende: viser den IP-adresse, der faktisk afleverede mailen
Linjer længere nede · Skrevet af afsenderens eller mellemliggende servere og kan i princippet være forfalsket

Den afgørende linje er grænsen mellem modtagerens infrastruktur og omverdenen. Her registrerer modtagerens server den IP-adresse, forbindelsen kom fra, og den værdi kan afsenderen ikke selv bestemme. Alt under den grænse er påstande fra fremmede systemer.

Kontrollér også, at tidsstemplerne i kæden er i fornuftig rækkefølge, når tidszonerne er omregnet. Spring bagud i tid eller store huller kan have naturlige forklaringer som forsinket levering, køer i et filter eller et forkert serverur, men de skal forklares. Om tidszoner og formater, se Tidsstempler og tidszoner.

Authentication-Results

Modtagerserveren skriver resultatet af sine kontroller i headeren Authentication-Results. Et typisk indhold er spf=pass med konvolutdomænet, dkim=pass med det signerende domæne og selector, og dmarc=pass med From-domænet.

Headeren indledes med et id for den server, der har skrevet den (authserv-id). Kun resultater med modtagerens eget id er troværdige. En afsender kan selv indsætte en Authentication-Results-header med pæne resultater. Modtagerens server bør fjerne sådanne headere, men det skal kontrolleres i det konkrete materiale.

SPF

SPF kontrollerer, om den afleverende IP-adresse må sende for domænet i konvolutadressen (MAIL FROM, synlig som Return-Path), ikke nødvendigvis den synlige afsender i From. SPF bryder typisk ved videresendelse, fordi den videresendende server har en anden IP-adresse. Et SPF-resultat skal desuden vurderes ud fra domænets SPF-post på afsendelsestidspunktet, som kan være ændret siden.

DMARC

DMARC binder kontrollerne til den synlige From-adresse. DMARC består, hvis SPF eller DKIM består, og det kontrollerede domæne stemmer overens med From-domænet (alignment). Domænets politik (none, quarantine eller reject) siger, hvad modtageren bør gøre ved fejl. Den siger intet om, hvorvidt en bestemt mail er ægte.

DKIM-signaturen i detaljer

DKIM-Signature indeholder blandt andet disse felter:

d= · Det domæne, der har signeret
s= · Selector, der peger på den offentlige nøgle i DNS
a= · Algoritme, typisk rsa-sha256
c= · Kanonisering, fx relaxed/relaxed
h= · Listen over headere, der indgår i signaturen
bh= · Hashværdi af mailens brødtekst
b= · Selve signaturen
t= og x= · Tidspunkt for signering og eventuelt udløb
l= · Valgfrit: kun de første l bytes af brødteksten er dækket

Det betyder i praksis:

bh= dokumenterer brødteksten. Er teksten ændret efter afsendelse, passer værdien ikke.
h= viser, hvilke headere der er beskyttet. Er From, Subject og Date med, er de dækket. Headere uden for listen kan være ændret uden at bryde signaturen.
l= betyder, at tekst efter den signerede del ikke er beskyttet. Findes feltet, skal det indgå i vurderingen.
t= er sat af afsenderens server og bekræfter ikke i sig selv tidspunktet over for tredjemand, men skal passe med resten af kæden.

En gyldig DKIM-signatur viser, at mailen er signeret af en server med adgang til domænets private nøgle, og at de dækkede dele er uændrede. Den viser ikke, hvem der sad ved tastaturet, og heller ikke, at kontoen ikke var overtaget.

Nøglerotation: efterprøv tidligt

DKIM-signaturen kan kun efterprøves, så længe den offentlige nøgle findes i DNS under selector._domainkey efterfulgt af domænet. Mange udbydere roterer nøgler, og gamle selectors fjernes. Derfor:

Hent nøglen straks med et DNS-opslag af typen TXT, fx med dig eller nslookup.
Gem svaret med tidspunkt, den forespurgte DNS-server og en hashværdi.
Efterprøv signaturen med et uafhængigt værktøj, fx et open source-bibliotek til DKIM, og gem værktøjets output og version.

Er nøglen allerede fjernet, kan den sommetider findes i historiske DNS-data fra tredjepart, men kilden skal dokumenteres. En signatur, der ikke længere kan efterprøves, er ikke det samme som en falsk signatur, og rapporten bør skelne tydeligt mellem de to.

ARC

Når mails passerer mailinglister, videresendelser eller sikkerhedsfiltre, brydes SPF og ofte DKIM. ARC (Authenticated Received Chain) lader hver mellemstation registrere, hvad den så:

ARC-Authentication-Results: kontrolresultaterne ved den pågældende station.
ARC-Message-Signature: en signatur over mailen, som den så ud.
ARC-Seal: en signatur over ARC-kæden med et resultat (none, pass eller fail).

Feltet i= nummererer stationerne. ARC gør det muligt at se, at mailen bestod kontrollerne, før den blev ændret undervejs, forudsat at den mellemliggende station er troværdig.

Typiske fund og fejlkilder

From og Return-Path er forskellige domæner. Det er almindeligt ved nyhedsbreve og systemmails, men relevant ved en påstået personlig mail.
DKIM er signeret af et andet domæne end From, fx en mailtjeneste. Se på DMARC-alignment, før der konkluderes.
Message-ID har et domæne, der ikke passer med den påståede afsenders mailsystem.
Et sikkerhedsfilter hos modtageren har omskrevet links eller vedhæftninger, så bh= ikke længere passer. Det er en teknisk forklaring, ikke et tegn på forfalskning.
Headere er gengivet i en mailklients visning, hvor lange linjer er foldet eller kodning ændret. Arbejd altid på den rå fil.

Dokumentation

Rapporten bør gengive de relevante headere ordret, angive hvilket eksemplar der er analyseret, og hvilke værktøjer og DNS-svar der er brugt. Konklusionen formuleres som det, de tekniske lag viser, og med de forbehold, der følger af, at en konto kan være overtaget. Hvordan teknisk ægthed indgår i en bredere vurdering af forfalskning, er beskrevet i Kan digitale beviser forfalskes?.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: E-mail forensics

Læs også: Anonym afsender: hvilke spor findes, og hvem har dem · PST og OST: struktur, slettede emner og korruption

→ E-mail forensics · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik