Ga naar inhoud
TextArray1.41.0
100% lokaal

E-mailheaderanalyzer

Volg het leveringspad van een e-mail en controleer de SPF-, DKIM- en DMARC-resultaten.

Invoer
Uitvoer
Gerelateerde tools
HTTP Header ParserOntwikkelaarstools
E-mailextractorOntwikkelaarstools
E-mail offertestripperTekst opschonen
i18n sleutel diffOntwikkelaarstools
TOML naar JSON-converterOntwikkelaarstools
SQL naar JSONOntwikkelaarstools
E-mailheaderanalyzer
Plak de onbewerkte headers van een e-mail in en dit hulpmiddel reconstrueert hoe deze werkelijk in uw inbox zijn aangekomen. Het volgt de reeks "Received"-regels van de bronserver tot de laatste afleveringshop in de volgorde waarin het bericht is gereisd en toont de vertraging tussen elke stap. Op die manier kunt u in een oogopslag zien waar een trage aflevering vast is komen te zitten.
De opties bepalen wat het rapport bevat. Schakel de Received-keten in om elke hop met het bijbehorende tijdstempel weer te geven en de langzaamste stap te markeren. De verificatiesectie leest de header "Authentication-Results" en rapporteert de SPF-, DKIM- en DMARC-uitkomsten die een ontvangende server al heeft berekend. De envelopsectie haalt From, To, Subject en Message-ID op en decodeert MIME encoded-word-headers (de "=?UTF-8?B?…?="-sequenties die e-mailclients gebruiken voor niet-ASCII-onderwerpen en namen) terug naar leesbare tekst. Wanneer een spamfilter een score heeft toegevoegd – een X-Spam-Score- of X-Spam-Status-header – wordt deze ook weergegeven. Het hulpmiddel markeert ook een verschil tussen het zichtbare From-adres en het Return-Path – een veelvoorkomend teken van een vervalsde of foutief geconfigureerde afzender.
Headers kunnen worden geplakt met Windows (CRLF) of Unix (LF) regeleindes. Gevouwen headerregels (vervolgingen die beginnen met een spatie of tab) worden voor verwerking automatisch ontvouwd. Datums die een mailserver in een indeling heeft geschreven die de browser niet kan ontleden, worden ongewijzigd weergegeven in plaats van te raden. Dit zorgt ervoor dat de vertragingsberekening nooit stilzwijgend een verkeerd getal verzint.
Alles wordt in uw browser uitgevoerd: headers bevatten vaak echte IP-adressen, interne hostnamen en afzendergegevens, en geen hiervan wordt ergens geüpload. Kopieer het rapport, download het als .txt-bestand of stuur het rechtstreeks naar een ander hulpmiddel om het onderzoek voort te zetten.
FAQ
Waarom begint de keten onderaan de geplakte headers?
Elke server voegt zijn eigen "Received"-regel toe, dus het nieuwste hop staat altijd eerst in de ruwe tekst. Het hulpmiddel keert deze volgorde om zodat het pad wordt weergegeven zoals het bericht werkelijk is gereisd: van afzender naar uw inbox.
Wat betekenen SPF-, DKIM- en DMARC-resultaten?
Dit zijn controles die de ontvangende mailserver al heeft uitgevoerd en in de header "Authentication-Results" heeft geregistreerd: SPF bevestigt dat de verzendserver gemachtigd is om voor dat domein te verzenden. DKIM verifieert dat een cryptografische handtekening niet is gewijzigd. DMARC combineert beide controles tegen het domeinbeleid. Het hulpmiddel leest en toont deze resultaten – het voert de controles zelf niet opnieuw uit.
Wat betekent een From / Return-Path-verschil?
Het From-adres is wat u in uw inbox ziet; Return-Path is waar terugkeer gaat en wordt vaak ingesteld door de werkelijke verzendinfrastructuur. Een ander domein is niet altijd kwaadwillig – veel legitieme services verzenden namens een domein – maar het is de moeite waard om dit te controleren tegen de SPF/DKIM/DMARC-resultaten hierboven.
Waarom geven enkele hops "onbekend moment" weer?
Een "Received"-header zonder parseerbare einddatum of met een niet-standaardformaat kan niet betrouwbaar worden getimed. In plaats van te raden, markeert het hulpmiddel dit als onbekend en sluit het uit van de vertragingsberekening.
Worden mijn e-mailheaders ergens geüpload?
Nee. Headerverwerking, datumberekening en MIME-decodering worden allemaal lokaal in uw browser uitgevoerd – niets wat u hier plakt, wordt naar een server verzonden.