Läsa e-posthuvuden för att upptäcka förfalskning

Varje e-postmeddelande bär i sina huvuden ett fullständigt spår: servrarna det passerat, autentiseringsresultaten och den verkliga kuvertavsändaren. Att läsa dem obehindrat är snabbaste sättet att bekräfta eller avfärda en misstänkt förfalskning, och en kärnfärdighet vid triage av rapporterat nätfiske.

Var du hittar råa huvuden

Det renderade meddelandet döljer allt användbart. Hämta råkällan:

• Gmail — Visa original.
• Outlook — Arkiv → Egenskaper → Internethuvuden (eller Visa meddelandekälla).
• Apple Mail — Visa → E-post → Råformat.
• Kommandoraden — inspektera .eml-filen direkt.

För leveransvägen läses huvuden nedifrån och upp: det äldsta hoppet står längst ned, den mottagande serverns Received: överst.

Identiteterna som spelar roll

Det finns två ”från”-värden, och nätfisket utnyttjar just glappet mellan dem:

• Kuvertavsändare (Return-Path / MAIL FROM) — används för routning och studsar; kontrolleras av SPF.
• Huvudets From (From:) — det användaren ser i sin klient.

En förfalskning visar typiskt ett trovärdigt From: medan Return-Path pekar någon helt annanstans.

Return-Path: <[email protected]>
From: "IT Helpdesk" <[email protected]>

Visningsnamnet (IT Helpdesk) styrs helt av angriparen och bevisar ingenting.

Läsa Authentication-Results

Det i särklass viktigaste huvudet är Authentication-Results, tillagt av er mottagande server (lita bara på det från er egen domän, överst):

Authentication-Results: mx.yourcompany.example;
  spf=pass (sender IP is 198.51.100.10) [email protected];
  dkim=fail header.d=yourbank.example;
  dmarc=fail (p=reject) header.from=yourbank.example

Tolka noggrant:

• spf=pass är här en fälla — den godkändes för sketchy-host.ru, inte för det synliga yourbank.example. SPF kontrollerar kuvertet, inte From:.
• dkim=fail — ingen giltig signatur som justerar mot From:-domänen.
• dmarc=fail (p=reject) — det är domen som räknas: den synliga domänens autentisering justerar inte. Ett meddelande som ändå når inkorgen trots dmarc=fail förtjänar granskning.

Jämför alltid den domän varje mekanism faktiskt autentiserade (smtp.mailfrom, header.d) mot From:-domänen. Autentisering utan justering betyder ingenting.

Spåra vägen med Received

Varje hopp lägger till en Received:-rad överst. Läs nedifrån:

Received: from mail.evilrelay.ru (mail.evilrelay.ru [203.0.113.7])
    by mx.yourcompany.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.evilrelay.ru ...

Varningsflaggor:

• Ursprungshoppets IP geolokaliseras långt från där avsändaren påstår sig vara.
• En förfalskad HELO (localhost, eller ett värdnamn som inte stämmer med omvänd DNS).
• Misstänkta luckor eller tidszonshopp i tidsstämplarna.
• Det första betrodda hoppet är er egen MX — allt under det kommer från angriparen och går att förfalska, så vikta därefter.

Andra tecken i huvudena

• Avvikande Reply-To — From: ser ut som en kollega, men Reply-To styr svaren till en extern adress. Klassiskt vid BEC och vd-bedrägeri.
• Message-ID-domän som inte matchar den sändande domänen.
• X-Mailer / X-PHP-Script-huvuden som avslöjar ett massutskicksverktyg eller ett PHP-skript på en kapad värd.
• Unicode/punycode i From:-domänen (xn--), ett homografangrepp.

En snabb triage-checklista

1. Är From:-domänen == Return-Path-domänen?             (skillnad = misstänkt)
2. Authentication-Results: dmarc=pass och justerad?      (fail = misstänkt)
3. Vilken domän autentiserade SPF/DKIM egentligen?       (måste matcha From:)
4. Skiljer sig Reply-To från From:?                      (ja = misstänkt)
5. Var kommer det nedersta Received-hoppet ifrån?        (oväntad geo = misstänkt)
6. Punycode eller homoglyfer i From:-domänen?            (ja = misstänkt)

Ett enskilt huvud bevisar sällan en förfalskning på egen hand. Domen kommer ur justeringen: matchar domänen som autentiserade den domän människan ser? DMARC finns just för att automatisera den jämförelsen — men på inkommande post från andra domäner måste ni fortfarande läsa den för hand.

Så hjälper GottaPhish

Att läsa huvuden är en reaktiv expertfärdighet, och de flesta användare ser dem aldrig. GottaPhish och dess expertteam överbryggar det glappet: realistiskt simulerat nätfiske — justeringsglapp, utbytt Reply-To, snarlika domäner — plus instrumentpaneler som visar exakt vilka som rapporterade, klickade eller lämnade uppgifter. Våra experter hjälper till med uppsättningen, utformar scenarier som prövar just de huvudknep angripare verkligen använder och hjälper er tolka resultaten — så att tekniska team skärper sina triage-rutiner medan utbildningen lär alla andra de synliga varningstecknen bakom huvudena.