Technical10 min leestijd28 februari 2026

E-mailheaders lezen en begrijpen: een technische deep-dive

Leer hoe je e-mailheaders ontleedt om deliverability-problemen, spoofing en routeringfouten op te sporen.

Wat zijn e-mailheaders?

Elke e-mail die je verstuurt of ontvangt bevat een verborgen schat aan informatie: de headers. Terwijl de meeste gebruikers alleen het "Van", "Aan" en "Onderwerp" zien, bevatten de volledige headers het complete verhaal van een e-mail — van verzending tot bezorging.

Headers zijn als de vrachtbrief van een pakketje: ze vertellen precies welke route het heeft afgelegd, wie het heeft aangeraakt, en of er onderweg iets mis is gegaan.

De anatomie van een e-mailheader

Laten we een typische header van boven naar beneden ontleden. Belangrijk: headers worden in omgekeerde volgorde gelezen — de onderste regel is het begin van de reis, de bovenste het einde.

From: Support <support@voorbeeld.nl>
To: klant@bedrijf.com
Subject: Uw ticket is opgelost
Date: Sat, 28 Feb 2026 05:59:58 +0100
Message-ID: <unique-id@voorbeeld.nl>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

De belangrijkste headers uitgelegd

1. Received-headers: de routekaart

Elke mailserver die het bericht verwerkt, voegt een Received-header toe. Dit is je broodkruimelspoor.

E-mailroute (tijd in ms)

▓▓▓ 0ms — Afzender → MTA-out (voorbeeld.nl)

▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 130ms — MTA-out → Mail-gateway (bedrijf.com)

▓▓ 10ms — Mail-gateway → Inbox-server

Wat te controleren:

Tijdsverschillen: Een vertraging van minuten tussen twee hops kan duiden op greylisting of queue-problemen
IP-adressen: Komt het bron-IP overeen met de verwachte mailserver?
TLS-versies: Wordt het bericht versleuteld overgedragen? ESMTPS = goed, ESMTP (zonder S) = onversleuteld

2. Authentication-Results: de beveiligingscheck

Dit is misschien wel de belangrijkste header voor deliverability. Hier zie je of SPF, DKIM en DMARC geslaagd zijn.

Check	Betekenis	Pass =	Fail =
SPF	Is het IP geautoriseerd om namens dit domein te versturen?	✅ Server is geautoriseerd	❌ Mogelijk spoofing
DKIM	Is de digitale handtekening geldig?	✅ Bericht is ongewijzigd	❌ Bericht gewijzigd of verkeerde sleutel
DMARC	Komen SPF/DKIM overeen met het From-domein?	✅ Alignment is correct	❌ Domein-mismatch

Pro tip: Een e-mail kan SPF en DKIM afzonderlijk passeren, maar toch DMARC falen als er geen alignment is. Dit gebeurt vaak bij forwarding of bij het gebruik van externe mailservices zonder juiste configuratie.

3. Return-Path: het bounceadres

De Return-Path (ook wel envelope-from) is het adres waar bounces naartoe gaan. Dit is niet hetzelfde als het From-adres dat de ontvanger ziet.

Return-Path: <bounce+abc123@voorbeeld.nl>
From: Support <support@voorbeeld.nl>

Bij MailBelly gebruiken we VERP (Variable Envelope Return Path) — elk uitgaand bericht krijgt een uniek bounce-adres, zodat we exact weten welk bericht is gebounced.

4. Message-ID: de unieke vingerafdruk

Elke e-mail heeft een uniek Message-ID. Dit is essentieel voor:

Threading: Antwoorden refereren naar het originele Message-ID via In-Reply-To en References
Deduplicatie: Servers gebruiken het om duplicaten te herkennen
Debugging: Je kunt een specifiek bericht traceren door de hele keten

5. X-headers: de geheime informatie

Veel mailsystemen voegen custom headers toe met het X- prefix:

X-Spam-Score: 2.1
X-Spam-Status: No
X-Mailer: MailBelly/2.0
X-Originating-IP: 198.51.100.7
X-Google-DKIM: pass

Google voegt specifieke headers toe:

X-Gm-Message-State: Interne Google tracking
X-Google-Smtp-Source: Verificatie van Google's eigen servers

Microsoft voegt toe:

X-MS-Exchange-Organization-AuthSource: Exchange authenticatiebron
X-MS-Exchange-Organization-SCL: Spam Confidence Level (0-9)

Praktijk: problemen diagnosticeren

Scenario 1: E-mail komt in spam

Je stuurt e-mails, maar ze belanden in de spamfolder van je klant. Check de headers:

Authentication-Results: mx.google.com;
    dkim=fail (body hash did not verify);
    spf=softfail;
    dmarc=fail
X-Spam-Score: 8.7

Diagnose: DKIM faalt omdat de body is gewijzigd (mogelijk door een mailinglijst of een tussenliggende server die een footer toevoegt). SPF geeft een softfail — waarschijnlijk ontbreekt het IP in je SPF-record.

Oplossing:

Controleer of je SPF-record het juiste IP bevat
Verifieer dat geen tussenliggende servers de body wijzigen na DKIM-signing
Overweeg ARC (Authenticated Received Chain) voor forwarding-scenario's

Scenario 2: Vertraging bij bezorging

Een klant klaagt dat e-mails pas na 30 minuten aankomen:

Received: from inbox.klant.nl (10.0.0.1)
    by store.klant.nl; Sat, 28 Feb 2026 06:30:00 +0100
Received: from gateway.klant.nl (10.0.0.2)
    by inbox.klant.nl; Sat, 28 Feb 2026 06:00:15 +0100
Received: from mta.voorbeeld.nl (203.0.113.42)
    by gateway.klant.nl; Sat, 28 Feb 2026 06:00:10 +0100

Diagnose: De vertraging van 30 minuten zit tussen inbox.klant.nl en store.klant.nl — een intern probleem bij de ontvanger. Dit is niet jouw schuld als verzender.

Bezorgvertraging per hop

▓ 0s — Jouw MTA → Gateway ontvanger

▓ 5s — Gateway → Inbox server

▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 1800s — Inbox → Store (PROBLEEM!)

Scenario 3: Spoofing detecteren

Je ontvangt een verdacht bericht dat claimt van je bank te komen:

From: Klantenservice <info@mijnbank.nl>
Return-Path: <phisher@kwaadaardig.ru>
Received: from smtp.kwaadaardig.ru (185.100.87.xxx)
Authentication-Results: mx.jouwmail.nl;
    spf=fail;
    dkim=none;
    dmarc=fail (policy=reject)

Diagnose: Alles wijst op spoofing:

Return-Path komt niet overeen met From-domein
Het bron-IP is uit een onverwacht netwerk
SPF faalt, geen DKIM, DMARC faalt
Als de bank p=reject heeft ingesteld, zou dit bericht nooit bezorgd mogen worden

Tools voor headeranalyse

Handmatig

In de meeste e-mailclients kun je de volledige headers bekijken:

Gmail: Open bericht → drie puntjes → "Origineel weergeven"
Outlook: Open bericht → Bestand → Eigenschappen → Internetheaders
Apple Mail: Weergave → Bericht → Alle headers

Online tools

Google Admin Toolbox: Parseert Received-headers en toont timing
MXToolbox Header Analyzer: Gedetailleerde analyse met waarschuwingen
Mail Header Analyzer (whatismyipaddress.com): Eenvoudig en snel

Programmatisch

python
import email
from email import policy

with open('bericht.eml', 'r') as f:
    msg = email.message_from_file(f, policy=policy.default)

# Alle Received-headers
for received in msg.get_all('Received', []):
    print(received)

# Authentication results
print(msg.get('Authentication-Results'))

# DKIM verificatie
print(msg.get('DKIM-Signature'))

Headers in MailBelly

Bij MailBelly maken we headeranalyse automatisch en visueel. Wanneer een bericht binnenkomt, parseren we alle headers en tonen we:

Authenticatiestatus: Groen/rood indicatoren voor SPF, DKIM en DMARC
Routevisualisatie: Een tijdlijn van server-hops met vertragingen
Beveiligingswaarschuwingen: Automatische alerts bij failed checks
Bounce-analyse: Koppeling tussen bounce-berichten en originele headers via VERP

Dit betekent dat je geen headerexpert hoeft te zijn — MailBelly doet het zware werk voor je.

Best practices

Monitor Authentication-Results actief: Stel alerts in voor DKIM/SPF failures op je eigen domein
Bewaar headers bij incidenten: Als je een deliverability-probleem onderzoekt, bewaar altijd de volledige headers
Controleer Received-chains bij vertragingen: De timestamps vertellen je exact waar de bottleneck zit
Let op header-injectie: Sanitize altijd user input die in headers terechtkomt (zoals het Subject-veld)
Gebruik ARC bij forwarding: Authenticated Received Chain behoudt authenticatieresultaten bij doorsturen

Conclusie

E-mailheaders zijn de zwarte doos van e-mailcommunicatie. Ze bevatten alle informatie die je nodig hebt om problemen te diagnosticeren, spoofing te detecteren en je deliverability te optimaliseren. Met de kennis uit dit artikel kun je elke e-mail als een detective ontleden — en dat is precies wat je nodig hebt als je serieus bent over e-mailbeheer.

#email#headers#debugging#deliverability#security

Klaar om te beginnen?

Start gratis met MailBelly. Geen creditcard nodig.

Gratis account aanmaken →