E-mailheaders lezen om vervalsing te herkennen

Elke e-mail draagt in haar headers een volledig spoor: de servers die zij passeerde, de authenticatieresultaten en de echte envelopafzender. Ze vlot kunnen lezen is de snelste manier om een vermoede vervalsing te bevestigen of te ontkrachten, en het is een kernvaardigheid bij het triëren van gemelde phishing.

Waar u de ruwe headers vindt

Het weergegeven bericht verbergt alles wat nuttig is. Haal de ruwe bron op:

• Gmail — Origineel weergeven.
• Outlook — Bestand → Eigenschappen → Internetkoppen (of Berichtbron weergeven).
• Apple Mail — Weergave → E-mail → Onbewerkte bron.
• Opdrachtregel — bekijk het .eml-bestand rechtstreeks.

Voor het bezorgpad leest u headers van onder naar boven: de oudste hop staat onderaan, de Received: van de ontvangende server bovenaan.

De identiteiten die ertoe doen

Er zijn twee «van»-waarden, en phishing buit precies het gat ertussen uit:

• Envelopafzender (Return-Path / MAIL FROM) — gebruikt voor routering en bounces; gecontroleerd door SPF.
• Header-From (From:) — wat de gebruiker in zijn programma ziet.

Een vervalsing toont doorgaans een betrouwbaar From: terwijl het Return-Path ergens anders heen wijst.

Return-Path: <[email protected]>
From: "IT Helpdesk" <[email protected]>

De weergavenaam (IT Helpdesk) wordt volledig door de aanvaller bepaald en bewijst niets.

Authentication-Results lezen

De veruit belangrijkste header is Authentication-Results, toegevoegd door uw ontvangende server (vertrouw alleen die van uw eigen domein, bovenaan):

Authentication-Results: mx.yourcompany.example;
  spf=pass (sender IP is 198.51.100.10) [email protected];
  dkim=fail header.d=yourbank.example;
  dmarc=fail (p=reject) header.from=yourbank.example

Lees hem zorgvuldig:

• spf=pass is hier een valstrik — het slaagde voor sketchy-host.ru, niet voor het zichtbare yourbank.example. SPF controleert de envelop, niet het From:.
• dkim=fail — geen geldige handtekening die uitlijnt met het From:-domein.
• dmarc=fail (p=reject) — dit is het oordeel dat telt: de authenticatie van het zichtbare domein lijnt niet uit. Een bericht dat ondanks dmarc=fail in de inbox belandt, verdient onderzoek.

Vergelijk altijd het domein dat elk mechanisme daadwerkelijk authenticeerde (smtp.mailfrom, header.d) met het From:-domein. Authenticatie zonder uitlijning betekent niets.

Het pad volgen met Received

Elke hop plaatst een Received:-regel bovenaan. Lees van onderen op:

Received: from mail.evilrelay.ru (mail.evilrelay.ru [203.0.113.7])
    by mx.yourcompany.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.evilrelay.ru ...

Rode vlaggen:

• Het IP van de eerste hop ligt geografisch ver van waar de afzender beweert te zijn.
• Een vervalste HELO (localhost, of een hostnaam die niet klopt met reverse DNS).
• Verdachte gaten of tijdzonesprongen in de tijdstempels.
• De eerste vertrouwde hop is uw eigen MX — alles daaronder is door de aanvaller aangeleverd en vervalsbaar, weeg het dienovereenkomstig.

Andere aanwijzingen in de headers

• Afwijkend Reply-To — From: lijkt een collega, maar Reply-To stuurt antwoorden naar een extern adres. Klassiek bij BEC en CEO-fraude.
• Message-ID-domein dat niet bij het verzendende domein past.
• X-Mailer / X-PHP-Script-headers die een bulktool of een PHP-script op een gekaapte host verraden.
• Unicode/punycode in het From:-domein (xn--), een homografische aanval.

Een snelle triagelijst

1. Is From:-domein == Return-Path-domein?              (verschil = verdacht)
2. Authentication-Results: dmarc=pass en uitgelijnd?    (fail = verdacht)
3. Welk domein authenticeerden SPF/DKIM werkelijk?      (moet matchen met From:)
4. Wijkt Reply-To af van From:?                         (ja = verdacht)
5. Waar komt de onderste Received-hop vandaan?          (onverwachte geo = verdacht)
6. Punycode of homoglyfen in het From:-domein?          (ja = verdacht)

Eén enkele header bewijst zelden op zichzelf een vervalsing. Het oordeel komt uit de uitlijning: past het domein dat authenticeerde bij het domein dat de mens ziet? DMARC bestaat juist om die vergelijking te automatiseren — maar bij inkomende post van andere domeinen moet u het nog altijd met de hand lezen.

Hoe GottaPhish helpt

Headers lezen is een reactieve vaardigheid voor specialisten, en de meeste gebruikers zien ze nooit. GottaPhish en zijn expertteam overbruggen dat gat: realistische gesimuleerde phishing — uitlijningsgaten, verwisselde Reply-To, gelijkende domeinen — plus dashboards die precies rapporteren wie meldde, klikte of inloggegevens invulde. Onze experts begeleiden de inrichting, ontwerpen scenario’s die juist de headertrucs van echte aanvallers beproeven en helpen de resultaten te duiden — zo scherpen technische teams hun triage-playbooks aan, terwijl de training iedereen anders de zichtbare signalen achter die headers leert.