Email header analyseren
Email header analyseren is eenvoudig: plak de ruwe headers van een bericht en je ziet wie het echt heeft verstuurd, of SPF, DKIM en DMARC zijn geslaagd en welke route het van server naar server aflegde. De tool leest wat de ontvangende mailserver al in de headers heeft vastgelegd. Het is een leeshulp en geen oordeel over de vraag of een bericht veilig is.
Een e-mailheader analyseren, stap voor stap
- Open het bericht in je mailapp, kies “Origineel weergeven” of “Bron bekijken” en kopieer het headerblok (alles boven de lege regel vóór de berichttekst).
- Plak het in Ruwe e-mailheaders (tot 200.000 tekens). Met Wissen maak je het veld leeg.
- Druk op Headers analyseren. Lijkt niets in de tekst op een header, dan krijg je een melding en kun je opnieuw plakken.
- Lees de Resultaten: onderwerp en datum, daarna de kaarten Echte afzender, Authenticatie en Route. De pijl terug brengt je naar de geplakte tekst, Opnieuw beginnen wist alles.
E-mail header Gmail en Outlook vinden
Open het bericht in Gmail, gebruik het menu met drie puntjes, kies “Origineel weergeven” en kopieer het headerblok bovenaan. In Outlook zoek je de eigenschappen of berichtdetails van het bericht (in klassiek Outlook: Bestand, dan Eigenschappen; in het nieuwe Outlook: Weergave, dan Berichtdetails weergeven). Menunamen verschillen per versie, en de meeste andere mailapps hebben een vergelijkbare optie om de bron te bekijken.
Waar komt een mail echt vandaan? De kaart Echte afzender
Hoe herken je een nepmail? Begin bij deze kaart. Drie adressen kunnen verschillen, en juist die verschillen zijn nuttig. Return-Path is waar bounces naartoe gaan en wordt ingesteld door de server die het bericht echt verstuurde. From is de naam en het adres die je in je inbox ziet. Reply-To is waar je antwoord naartoe gaat, en Sender verschijnt als het bericht namens het From-adres is verstuurd. De kaart toont ook het Eerste openbare IP-adres in de route.
Eronder kunnen twee opmerkingen staan. “From en Return-Path staan op hetzelfde domein” is het verwachte geval. “From en Return-Path staan op verschillende domeinen” is een signaal om beter te kijken, maar nieuwsbrief- en mailingdiensten doen dit legitiem. “Antwoorden gaan naar een ander domein dan dat in From” verdient een tweede blik voordat je antwoordt.
SPF, DKIM en DMARC: de uitkomsten uitgelegd
De kaart Authenticatie toont elke controle als badge, plus de vastgelegde eigenschappen zoals smtp.mailfrom, header.d en header.from. SPF vraagt of de verzendende server namens het domein mocht versturen, DKIM of het bericht is ondertekend en de handtekening klopt, en DMARC of het eigen beleid van het domein het bericht accepteert.
- Geslaagd: de ontvangende server voerde de controle uit en die slaagde.
- Mislukt: de controle mislukte; de server was niet geautoriseerd of de handtekening klopte niet.
- Softfail: alleen bij SPF; de server is waarschijnlijk niet geautoriseerd, maar het domein eist geen weigering.
- Neutraal: het domein doet geen uitspraak.
- Geen: het domein publiceerde niets om mee te vergelijken.
- Tijdelijke fout en Permanente fout: de server kon de controle niet afmaken, bijvoorbeeld doordat een DNS-opzoeking verliep of het record kapot is.
- Beleid: de uitkomst werd bepaald door het eigen beleid van de ontvangende server.
- Niet geverifieerd: er is een DKIM-handtekening, maar geen enkele server legde er een resultaat voor vast.
- Niet gevonden: de headers bevatten geen resultaat voor die controle.
De resultaten komen uit de bovenste Authentication-Results-header, inclusief de Outlook-variant zonder server-id. Is er geen, dan valt SPF terug op Received-SPF en DKIM op de DKIM-Signature-header.
De route van een e-mail lezen (Received-regels)
Elke server die het bericht verwerkt, voegt bovenaan een Received-regel toe. De kaart Route draait ze om, zodat de oudste schakel vooraan staat, en toont per schakel de verzendende server (van), de IP-adressen, de ontvangende server (door), het protocol, de tijd in UTC en hoeveel later het was dan de vorige schakel. De samenvatting noemt het aantal servers en de totale tijd onderweg.
Een lange pauze tussen twee schakels laat zien waar het bericht heeft gewacht, bijvoorbeeld in een wachtrij of een spamfilter. Met Ruwe waarden tonen zie je onder elke rij de exacte headertekst.
Wat deze tool niet kan
Ze controleert geen handtekeningen en zoekt niets op in DNS. Ze meldt de uitkomsten die de ontvangende mailserver in de headers heeft geschreven. Een vervalst bericht kan binnenkomen met nepregels voor Authentication-Results, dus alleen de bovenste regel, toegevoegd door je eigen provider, is betrouwbaar; regels van daarvoor zijn door anderen geschreven en kunnen vervalst zijn. De tool geeft geen garantie dat een bericht veilig of onveilig is en zoekt niet op waar een IP-adres zich bevindt.
Je headers worden in je browser gelezen. Er wordt niets geüpload of opgeslagen. Afgekapte of kapotte headers geven geen fouten: omgevouwen regels en gecodeerde namen en onderwerpen worden gedecodeerd, en het lezen stopt bij de lege regel vóór de berichttekst.
Veelgestelde vragen
Hoe analyseer ik een e-mailheader?
Kopieer het volledige headerblok uit het bericht, plak het in “Ruwe e-mailheaders” en druk op “Headers analyseren”. Het resultatenscherm zet de belangrijke regels op een rij: de kaart “Echte afzender” (Return-Path, From, Reply-To), de kaart “Authenticatie” (SPF, DKIM, DMARC) en de kaart “Route” met elke server waar het bericht langs kwam. Met “Ruwe waarden tonen” zie je de exacte headertekst achter elke rij.
Waar vind ik de headers in Gmail of Outlook?
Open in Gmail het bericht, gebruik het menu met drie puntjes en kies “Origineel weergeven”; kopieer dan het headerblok bovenaan. In Outlook zoek je de eigenschappen of berichtdetails (Bestand, dan Eigenschappen, in klassiek Outlook; Weergave, dan Berichtdetails weergeven, in het nieuwe). Menunamen verschillen per versie.
Hoe zie ik waar een mail echt vandaan komt?
Kijk op de kaart “Echte afzender” naar het Return-Path en het “Eerste openbare IP-adres in de route”. Het Return-Path wordt ingesteld door de server die het bericht echt verstuurde, en het eerste openbare IP-adres is het vroegste externe adres in de Received-regels. Beide kunnen van een maildienst zijn in plaats van een persoon, en een vervalst bericht kan de regels vervalsen die het vanaf het begin meedraagt. Zie ze dus als aanwijzingen, niet als bewijs.
Kan ik het IP-adres van de afzender uit een header halen?
Vaak zie je een IP-adres, maar niet altijd dat van de afzender zelf. De tool toont de IP-adressen in elke Received-regel en markeert het eerste openbare in de route. Verstuurt iemand via Gmail, Outlook of een nieuwsbriefdienst, dan hoort dat adres bij de mailserver en niet bij zijn telefoon of computer. De tool zoekt geen locatie op bij een IP-adres.
Hoe herken ik een nepmail?
Vergelijk de identiteiten en lees de authenticatieresultaten. Er verschijnt een waarschuwing als From en Return-Path op verschillende domeinen staan, of als antwoorden naar een ander domein gaan dan dat in From. Kijk daarna naar SPF, DKIM en DMARC: een “Mislukt” bij DMARC voor een bericht dat van een bank of een bekende zou komen, is een alarmsignaal. Bij nieuwsbrieven zijn verschillende domeinen normaal, dus gebruik de opmerkingen als aanleiding om beter te kijken, niet als oordeel.
Wat is een SPF softfail?
Bij een softfail geeft het SPF-record van het verzendende domein aan dat de server die het bericht aflevert waarschijnlijk niet geautoriseerd is, zonder te eisen dat het wordt geweigerd. Ontvangende servers accepteren zulke mail vaak en markeren haar, dus een softfail is een waarschuwing en geen bewijs van vervalsing. “Mislukt” is de strengere uitkomst, en “Neutraal” betekent dat het domein geen uitspraak doet.
Waarom staat er “Niet geverifieerd”, “Geen” of “Niet gevonden” in een header?
“Niet geverifieerd” betekent dat er een DKIM-handtekening is, maar geen server er een resultaat voor vastlegde. “Geen” betekent dat het domein niets publiceerde om mee te vergelijken. “Niet gevonden” betekent dat de headers helemaal geen resultaat voor die controle bevatten, wat gebeurt als de ontvangende server er geen vastlegt of als je maar een deel van de headers plakte. “Beleid”, “Tijdelijke fout” en “Permanente fout” zijn uitkomsten die de server zelf schreef.
Kan ik de regels Authentication-Results in een header vertrouwen?
Alleen de bovenste, die door je eigen mailprovider is toegevoegd. Regels van eerder in de route zijn door andere servers geschreven en kunnen door de afzender worden vervalst. Deze tool leest die regels zoals ze zijn vastgelegd; ze controleert geen handtekeningen en bevraagt zelf geen DNS, maar meldt wat je provider al heeft besloten.
Is de tool gratis, en worden mijn headers geüpload?
De tool is gratis en heeft geen account nodig. De headers worden in je browser gelezen en niet geüpload of opgeslagen. Geplakte tekst is beperkt tot 200.000 tekens, veel meer dan een normaal headerblok.
Aanbevolen
-
Yubico Security Key C NFCEen nepmail ontdekt? Beveilig je accounts met een fysieke sleutel.
-
YubiKey 5C NFCEen veelzijdige sleutel voor beheer- en werkaccounts, bestand tegen phishing.
-
Belkin USB-C-hub met 4 poorten (100 W)Meer poorten voor de laptop waarmee je mailproblemen uitzoekt.
Help de tools gratis te houden. ✨
Afbeeldingen dienen ter illustratie. Als Amazon-Partner verdien ik aan in aanmerking komende aankopen.
