Summary

Det här verktyget låter dig analysera e-posthuvud genom att läsa det råa headerblocket från valfritt e-postmeddelande och visa om SPF, DKIM och DMARC faktiskt godkändes, baserat på raden Authentication-Results som den mottagande e-postservern redan har beräknat. Det räknar också relähopp från Received-raderna och uppskattar transporttiden mellan dem när tidsstämplarna tillåter det. Klistra in headers från Gmails Visa original, Outlooks visa källkod eller Apple Mails Alla headers. Ingenting laddas upp, tolkningen körs i din webbläsare, och det krävs ingen registrering.

Analysera e-posthuvud: kontrollera SPF, DKIM och DMARC direkt

Klistra in headerblocket från valfritt e-postmeddelande, så läser den här analysatorn av det som den mottagande e-postservern redan har kontrollerat: SPF, DKIM, DMARC, antal relähopp och transporttid mellan hoppen.

Analysera dina headers

Analysera e-posthuvud

Klistra in hela det råa headerblocket nedan. Tolkning och poängsättning körs helt i din webbläsare, ingenting laddas upp.

Klistra in det råa headerblocket från ett e-postmeddelande (Visa källkod, Visa original eller Meddelandeinformation). Kontrollen körs bara i din webbläsare.

-
Klistra in headers ovan för att se resultatet
SPF, DKIM och DMARC läses från raden Authentication-Results.
    Så fungerar det

    Vad poängen faktiskt läser av

    Authentication-Results, uppläst

    Analysatorn letar efter den mottagande serverns Authentication-Results-rad och läser av värdena spf=, dkim= och dmarc= som redan har beräknats där. Den kör inga egna DNS-uppslag, utan litar på den e-postleverantör som faktiskt tog emot meddelandet och skrev raden.

    Relähopp, räknade

    Varje Received-rad är ett hopp mellan e-postservrar, lästa i ordning från nederst till överst. När två eller fler hopp har en tolkningsbar tidsstämpel uppskattar verktyget också transporttiden mellan första och sista hoppet, och hoppar hellre över siffran än gissar om en tidsstämpel inte går att tolka.

    Körs i din webbläsare, inte på våra servrar

    Headers kan innehålla interna värdnamn, ärendenummer och IP-adresser som du helst inte vill klistra in i ett slumpmässigt webbformulär. Det här verktyget skickar aldrig texten någonstans. Regex-tolkningen, poängsättningen och räkningen av hopp körs allihop klientsidan, i fliken du läser just nu.

    Vanliga frågor om headerkontrollen

    Är den här e-posthuvudanalysatorn gratis att använda?
    Ja. Det krävs ingen registrering och det finns ingen gräns för antal analyser. Poängen bygger på att headertexten tolkas i din webbläsare, så det finns ingen kostnad per körning att begränsa på vår sida.
    Var hittar jag de råa headers för ett e-postmeddelande?
    I Gmail öppnar du meddelandet och väljer Visa original. I Outlook använder du Visa, sedan Visa källkod, eller panelen för meddelandeinformation. I Apple Mail går du via Visa, Meddelande, Alla headers. Kopiera hela blocket, inklusive Authentication-Results och varje Received-rad.
    Sparar ni headers jag klistrar in här?
    Nej. Textfältet läses av JavaScript som körs på din enhet. Ingenting laddas upp, loggas eller skickas till våra servrar. Det enda nätverksanropet den här sidan gör är den anonyma sidvisningssignal som finns på alla sidor på webbplatsen.
    Varför säger den att ingen Authentication-Results-header hittades?
    Vissa mottagande servrar lägger inte till den raden, och vidarebefordrade eller exporterade kopior tappar den ibland på vägen. Kontrollera originalkopian i den inkorg där meddelandet först landade, inte en vidarebefordrad kopia klistrad från ett ärende eller en tråd.
    SPF godkändes men DMARC underkändes. Vad betyder det?
    DMARC kontrollerar inriktning (alignment), inte bara att SPF och DKIM var för sig blir godkända. SPF kan bli godkänt på kuvertavsändaren samtidigt som den synliga From-domänen inte matchar den tillräckligt väl för domänägarens DMARC-policy. Ett DMARC-underkännande här betyder oftast att From-domänen och den autentiserade domänen skiljer sig åt.
    Garanterar en poäng på 100 att avsändaren är legitim?
    Nej. Det betyder att meddelandet klarade de tekniska kontroller som den mottagande e-postservern redan körde: den sändande servern var auktoriserad för domänen, och signaturen och inriktningen stämde. Det säger ingenting om avsikt. Autentiserad nätfiske från en komprometterad eller efterliknande domän förekommer fortfarande.
    Varför saknas transporttiden eller visar klockglapp?
    Received-tidsstämplar sätts av varje reläs egen klocka, och klockor går fel över tid. Om ett hopps klocka visar en tidigare tid än det föregående, eller om en header saknar en tolkningsbar tidsstämpel, hoppar verktyget över siffran istället för att visa en det inte kan stå för.
    Säger antalet relähopp något i sig självt?
    Inte särskilt mycket på egen hand. De flesta B2B-utskick passerar två till fyra reläer mellan ursprungsservern och din inkorg. Ett högre antal är inte automatiskt misstänkt, men ett okänt värdnamn i kedjan är värt en extra titt mot avsändarens kända infrastruktur.

    Följ infrastrukturen bakom dina egna utskick

    Den här kontrollen läser någon annans headers i efterhand. Notification Harbor är för utskicken du själv styr: domain warmup, spårbarhet på transaktionsnivå, och SPF, DKIM och DMARC rätt konfigurerat från första utskicket, inte diagnostiserat efter ett klagomål.

    Se hur Notification Harbor fungerar
    notificationharbor
    Kom igång gratis