Forside › E-mail forensics · Gennemgået oktober 2026 · Af John Nielsen
Om en mail er ægte, afgøres bedst ved at finde den samme mail i flere uafhængige kilder og kontrollere, at de stemmer overens. Headerne er en vigtig del, men de er kun ét lag. Den stærkeste vurdering kombinerer mailen i postkassen, serverens transportspor, Message-ID, postkassens egne egenskaber og, hvor det er muligt, modpartens eksemplar. Hvis alle kilder peger samme vej, er konklusionen robust. Hvis en mail kun findes som en udskrift eller en videresendt kopi, er det sjældent muligt at sige meget.
Den tekniske headeranalyse med SPF, DKIM, DMARC og Received-kæden er gennemgået i Analyse af mail-headere, og grundbegreberne findes på digitalbevissikring.dk. Denne artikel beskriver den samlede metode, hvor headerne er ét af flere spor. De specialiserede spørgsmål har egne artikler: falske domæner dokumenteres i Lookalike-domæner, ændringer efter afsendelse i Redigerede mails, og metoden anvendt på konkrete forløb står i Fakturasvindel: hvilken part var kompromitteret? og CEO-svindel: analyse af mailtråden.
Spørgsmålet skal præciseres
“Er mailen ægte?” dækker typisk over et af flere forskellige spørgsmål:
- Blev mailen faktisk sendt og modtaget, eller er den fremstillet bagefter?
- Er indholdet det samme, som da den blev sendt, eller er tekst, dato eller vedhæftning ændret?
- Kom den fra den påståede afsenders system, eller er afsenderen forfalsket?
- Blev den sendt af den person, der står som afsender?
De første tre kan ofte besvares teknisk. Det fjerde kan kun besvares delvist, fordi en ægte konto kan være brugt af en anden. Skelnen mellem forfalsket afsender, lookalike-domæne og overtaget konto er behandlet i Kompromitteret konto, spoofing eller lookalike-domæne?.
Kilde 1: mailen i postkassen
Udgangspunktet er mailen sikret direkte fra postkassen, ikke en udskrift, et skærmbillede eller en videresendt kopi. I Microsoft 365 eller Google Workspace bør den hentes via en eDiscovery- eller eksportfunktion, så både indhold og egenskaber bevares. Valget af format har betydning for, hvad der kan efterprøves; se Mailformater i forensics.
Kontrollér, at mailen ligger i den forventede mappe, og at dens egenskaber passer med forløbet. En modtaget mail har typisk leveringstid og transportheadere. En mail, der er oprettet direkte i postkassen, fx ved import eller via en API, kan mangle transportheadere eller have egenskaber, der ikke passer med en normal modtagelse.
Kilde 2: serverens transportspor
Mailsystemets transportlogs registrerer modtagelse og levering uafhængigt af postkassen. Findes der en hændelse med samme Message-ID, afsender, modtager, tidspunkt og omtrent samme størrelse, er det et stærkt spor for, at mailen faktisk passerede systemet på det tidspunkt. Fravær af en hændelse, hvor der burde være en, er tilsvarende et alvorligt problem for mailens ægthed. Transportsporet opbevares kun i begrænset tid; se Message trace og transportlogs.
Kilde 3: Message-ID
Message-ID er en id, som afsenderens system normalt sætter, når mailen oprettes. Den har typisk en lokal del og et domæne, og formatet er karakteristisk for hvert mailsystem. Undersøg:
- Formatet. Passer det med det system, den påståede afsender bruger? En Message-ID i et format, der hører til en anden mailtjeneste, kræver en forklaring.
- Entydighed. Findes samme Message-ID i flere postkasser, fx hos afsender og modtager, er det den samme mail.
- Tråden. Svar og videresendelser henviser til tidligere Message-ID’er i headerne In-Reply-To og References. En mail, der påstås at være et svar, bør henvise til en mail, der findes.
Message-ID kan forfalskes af den, der fremstiller en mail, men den skal så også passe med alle andre kilder, hvilket er langt sværere.
Kilde 4: postkassens egne egenskaber
Postkassesystemet gemmer oplysninger om hvert emne, som ikke er en del af selve mailen: hvornår emnet blev oprettet i postkassen, hvornår det blev leveret, og hvornår det sidst blev ændret. Disse egenskaber kan vise, om tidsforløbet er sandsynligt. En mail, der påstås modtaget for et år siden, men som blev oprettet i postkassen i sidste uge, kræver en forklaring, fx en import eller en flytning. Tegn på efterfølgende ændring er behandlet i Redigerede mails.
Auditloggen kan supplere med handlinger på emnet, hvis postkasselogning var slået til.
Kilde 5: modpartens eller tredjemands eksemplar
Det stærkeste enkeltbevis er ofte, at samme mail findes hos både afsender og modtager. Afsenderens eksemplar i Sendt post og modtagerens eksemplar i indbakken er skrevet af to forskellige systemer. Stemmer de overens i Message-ID, tidspunkt, emne, indhold og vedhæftningers hashværdier, er det meget vanskeligt at have fremstillet dem uafhængigt. Afviger de, viser forskellene præcist, hvor uoverensstemmelsen ligger.
Andre uafhængige eksemplarer kan findes hos medmodtagere, i et arkivsystem, i backup eller i en journalføringspostkasse.
Kilde 6: headerne
Headeranalysen indgår som ét lag: Viser Authentication-Results og en efterprøvet DKIM-signatur, at mailen kom fra en server med ret til at sende for domænet, og at brødteksten er uændret siden signeringen? Er Received-kæden sammenhængende? Resultatet vægtes sammen med de øvrige kilder.
Samlet vurdering
- Samme Message-ID og indhold hos afsender og modtager · Ægte og uændret
- Transporthændelse med samme Message-ID og tid · Mailen passerede systemet
- Gyldig DKIM-signatur fra afsenderdomænet · Indhold uændret siden afsendelse fra domænet
- Oprettelsestid i postkassen langt efter påstået modtagelse · Import, flytning eller fremstilling; kræver forklaring
- Ingen transporthændelse, hvor sporet dækker perioden · Alvorlig tvivl om modtagelse via systemet
- Kun udskrift eller skærmbillede · Ægthed kan ikke vurderes teknisk
Hvert fund vurderes med de mulige alternative forklaringer, og konklusionen formuleres med en grad af sikkerhed, der svarer til, hvor mange uafhængige kilder der er. Om skalaer for konklusioner, se Konklusionsgrader.
Typiske fejl i vurderingen
- Headerne vurderes alene. En bestået DKIM-kontrol viser, at mailen kom fra domænets server, men ikke at kontoen var under ejerens kontrol, og ikke at postkassens eksemplar er det samme, som blev fremlagt.
- Den fremlagte version er ikke den sikrede. Et bilag i PDF kan afvige fra mailen i postkassen. Sammenlign altid bilaget med det sikrede eksemplar.
- Fravær af spor tolkes for hårdt. Manglende transportspor kan skyldes, at søgevinduet er udløbet, eller at mailen kom ad en anden vej, fx via en anden konto eller en mobilklient med egen afsendelse.
- Tidszoner blandes. Visningen i mailklienten bruger lokal tid, mens headere og logs ofte er i UTC.
- Kun én parts materiale. Når kun den ene part har leveret materiale, bør det fremgå, at modpartens eksemplar ikke har været tilgængeligt, og hvad det kunne have afklaret.
Sikringsrækkefølge
- Transportspor, fordi de udløber først.
- Mailen fra modtagerens postkasse med egenskaber.
- Mailen fra afsenderens postkasse, hvis den er tilgængelig.
- DKIM-nøglen fra DNS, før den roteres.
- Auditlog for postkasserne.
- Andre eksemplarer i arkiv, backup eller hos medmodtagere.
Dokumentation
Rapporten bør beskrive hver kilde, hvordan den er sikret, og hvad den viser for sig. Derefter samles fundene i en vurdering, der tydeligt angiver, hvilke spørgsmål der kan besvares, og hvilke der ikke kan. Er det kun muligt at sige, at der ikke er fundet tegn på forfalskning i de tilgængelige kilder, skal det formuleres sådan og ikke som et bevis for ægthed.
Kilder og versioner
- RFC 5322: Internet Message Format
- RFC 8601: Authentication-Results-headeren
- Microsoft Learn: Message trace i Exchange Online
Senest gennemgået: oktober 2026.
Næste skridt
- PST og OST: struktur, slettede emner og korruption
- Exchange Server lokalt og hybrid: logkilder
- IMAP-postkasser hos webhoteller: sikring og serverlogs
Del af: E-mail forensics
Læs også: Message trace og transportlogs: leveringsspor på serversiden · Kompromitteret konto, spoofing eller lookalike-domæne? Sådan skelnes de
→ E-mail forensics · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
