Hoppa till innehåll
TextArray1.41.0
100% lokalt

E-postheaderanalysator

Spåra en e-posts leveransväg och kontrollera dess SPF-, DKIM- och DMARC-resultat.

Inmatning
Utmatning
Relaterade verktyg
HTTP Header ParserUtvecklarverktyg
E-postutdragareUtvecklarverktyg
E-post offert stripperTextrensning
i18n nyckel diffUtvecklarverktyg
TOML till JSON-omvandlareUtvecklarverktyg
SQL till JSONUtvecklarverktyg
E-postheaderanalysator
Klistra in de rå huvudena från ett e-postmeddelande och det här verktyget rekonstruerar hur det faktiskt kom till din inkorg. Det följer kedjan av "Received"-rader från ursprungsservern till den slutliga leveranshemmet i den ordning som meddelandet reste och visar fördröjningen mellan varje steg. På så sätt kan du med en blick se var en långsam leverans fastnade.
Alternativen styr vad rapporten innehåller. Slå på Received-kedjan för att se varje hopp med sin tidsstämpel och markera det långsammaste steget. Autentiseringssektionen läser headern "Authentication-Results" och rapporterar de SPF-, DKIM- och DMARC-resultat som en mottagande server redan har beräknat. Kuvertavsnittet hämtar From, To, Subject och Message-ID och avkodar MIME encoded-word-headers (de "=?UTF-8?B?…?="-sekvenser som e-postklienter använder för icke-ASCII-ämnen och namn) tillbaka till läsbar text. När ett spamfilter har lagt till en poäng – ett X-Spam-Score- eller X-Spam-Status-header – visas den också. Verktyget flaggar också en avvikelse mellan den synliga From-adressen och Return-Path – ett vanligt tecken på en förfalskad eller felkonfigurerad avsändare.
Headers kan klistras in med Windows (CRLF) eller Unix (LF) radslut. Veckade headerrader (fortsättningar som börjar med ett mellanslag eller tabb) viks ut automatiskt innan bearbetning. Datum som en e-postserver skrev i ett format som webbläsaren inte kan tolka visas oförändrat snarare än att gissa. Detta säkerställer att fördröjningsberäkningen aldrig i hemlighet uppfinner ett falskt nummer.
Allt körs i din webbläsare: headers innehåller ofta riktiga IP-adresser, interna värdnamn och avsändardetaljer, och ingen av detta laddas upp någonstans. Kopiera rapporten, hämta den som en .txt-fil eller skicka den direkt till ett annat verktyg för att fortsätta undersökningen.
FAQ
Varför börjar kedjan längst ner i de inklistrade huvudena?
Varje server lägger till sitt eget "Received"-rad, så det senaste hoppet är alltid först i rå text. Verktyget kastar denna ordning för att visa vägen som meddelandet faktiskt reste: från avsändaren till din inkorg.
Vad betyder SPF-, DKIM- och DMARC-resultaten?
Det är kontroller som den mottagande e-postservern redan har utfört och registrerat i headern "Authentication-Results": SPF bekräftar att sändservern är auktoriserad att skicka för den domänen. DKIM verifierar att en kryptografisk signatur inte manipulerades. DMARC kombinerar båda mot domänens policy. Verktyget läser och visar dessa resultat – det kör inte kontrollerna själv igen.
Vad betyder en From / Return-Path-avvikelse?
From-adressen är vad du ser i din inkorg; Return-Path är där bounces går och ställs ofta in av den faktiska sändningsinfrastrukturen. En annan domän är inte alltid skadlig – många legitima tjänster skickar för en domän – men det är värt att kontrollera mot SPF/DKIM/DMARC-resultaten ovan.
Varför visar vissa hopp "okänd tid"?
En "Received"-header utan ett tolkningsbar slutdatum eller med ett icke-standardformat kan inte tidas tillförlitligt. I stället för att gissa markerar verktyget det som okänt och exkluderar det från fördröjningsberäkningen.
Laddas mina e-postheaders upp någonstans?
Nej. Headerbearbetning, datumberäkning och MIME-avkodning körs alla lokalt i din webbläsare – ingenting som du klistrar in här skickas till en server.