E-mailkoppen lezen: de weg die een bericht aflegt
Een bericht komt aan in een mail-app als afzender, onderwerp en inhoud — maar het deel dat het verhaal vertelt staat erboven, verstopt: de koppen. Elke server die het bericht aanraakte schreef een Received-regel, de ontvangende server die SPF, DKIM en DMARC testte schreef zijn oordeel in Authentication-Results, en Return-Path en From tonen welke envelop en welke naam werd getoond — samen vormen die regels een reislogboek.
Het reislogboek is zelfrapportage, en dát is zijn beperking én zijn waarde. Omdat elke server zijn eigen regel op zijn eigen klok schrijft, is een keten geen vonnis: tijden lopen uiteen en vallen soms weg. Juist daarom wegen de patronen die wél zichtbaar zijn in het log: een From-domein dat in geen enkele sprong voorkomt, of twee ontvangers die verschillend oordelen over één bericht, dat zie je zonder één regel te vertrouwen.
Begin bij de Mailkop-analyzator: plak de ruwe koppen van een bericht en de tijdlijn verschijnt in reisrichting — van de eerste afzendende server naar de ontvanger die jij bent, met per sprong het tijdstip dat die server voor zich noteerde, het verschil met de vorige sprong en het oordeel van elke ontvanger. De mail verlaat je browser niet: ontleden, tijdlijn en bevindingen gebeuren hier.
1. De regels die het verhaal dragen
De Received-regel is de etapij van het reislogboek: `from` noemt de server die het bericht aanleverde, `by` de server die het aannam, `with` zegt wat voor verbinding het was — SMTP, ESMTPS met TLS — en de datum is het moment dat de ontvanger voor zich noteerde. De regels staan omgekeerd: de bovenste Received is de laatste sprong, dus een reislogboek lees je van onder naar boven.
Naast de route is er de vraag wie het bericht claimt te zijn: From is de getoonde naam, Return-Path is de envelop waar bounces op terugkomen — en als die twee op verschillende domeinen wonen, is dat niet automatisch een leugen, maar wel een patroon dat je moet wegen. In de koppen van je eigen post vind je het in één minuut terug; de regels voor die domeinen staan in SPF, DKIM en DMARC uitgelegd.
2. Oordelen per ontvanger, niet per bericht
Authentication-Results is niet één oordeel maar een rij oordelen: elke ontvangende server die testte, schreef zijn eigen regel met eigen SPF-, DKIM- en DMARC-uitkomst. Daardoor wordt forwarding zichtbaar: de eerste ontvanger laat SPF slagen omdat het bericht echt van de afzender-server kwam, en de ontvanger ná de forwarding-server faalt SPF omdat het bericht nu van de forwarder komt — normaal, en als keten te lezen, niet als tegenspraak. De DKIM-signatuur overleeft forwarding meestal; SPF meestal niet.
Oordelen twee ontvangers verschillend over dezelfde methode, dan is dat een bevinding maar geen veroordeling: policies verschillen, en de laatste ontvanger in de keten — degene die jóuw post zag — weegt voor jouw oordeel het zwaarst. De analyzer zet beide oordelen per methode naast elkaar op de tijdlijn, zodat je ziet waar het oordeel omslaat zonder zelf regels te gaan vergelijken.
3. Wat je in het log kan zien
Verdachte patronen hebben hun eigen signatuur: het From-domein komt in geen enkele sprong voor en in geen enkel oordeel; de envelop komt van een ander domein dan de getoonde afzender; een ontvanger die had moeten testen schreef geen Authentication-Results; of twee Received-regels die ogenschijnlijk terug in de tijd aankomen — mailserverklokken lopen uiteen, dus een negatief tijdverschil zegt meer over de klokken dan over het bericht.
En er is dieper: de DKIM-verificatie herberekent de handtekening van het bericht zelf in je browser, de SPF-naberekening test of een verzendend IP überhaupt op de SPF van het From-domein stond, en de Mailbeveiliging laat het DMARC-beleid van de afzender-kant zien — de koppen tonen wat er gebeurde, die tools tonen wat de regels zijn.
4. Lees je eigen post zonder iets te versturen
In de koppen van een ontvangen bericht staat meer dan de afzender: je eigen adres, adressen van anderen op de regel, soms interne hostnamen en ids van de systemen die doorstuurden. Daarom draait deze analyse in je browser: de plak, de tijdlijn en de bevindingen gebeuren daar, en geen byte gaat naar onze server. Exporteer je de analyse als JSON, dan ben jij degene die bepaalt waar dat bestand heen gaat.
Voor grote vragen is er een groter beeld: bij DMARC-rapportlezer ligt het aggregaat van veel berichten uit jouw domein, bij Mailbeveiliging het record-beeld van het domein zelf — en bij één bericht dat mogelijk niet klopt, bovenstaand reislogboek, sprong voor sprong gelezen.