Czytanie nagłówków e-maili, żeby wykryć podszycie

Każdy e-mail niesie w nagłówkach pełny ślad: serwery, przez które przeszedł, wyniki uwierzytelniania i prawdziwego nadawcę koperty. Płynne czytanie ich to najszybszy sposób, by potwierdzić albo obalić podejrzenie podszycia — i kluczowa umiejętność przy segregacji zgłoszeń phishingowych.

Gdzie znaleźć surowe nagłówki

Wyświetlana wiadomość ukrywa wszystko, co przydatne. Sięgnij po surowe źródło:

• Gmail — Pokaż oryginał.
• Outlook — Plik → Właściwości → Nagłówki internetowe (albo Pokaż źródło wiadomości).
• Apple Mail — Widok → Wiadomość → Surowe źródło.
• Wiersz poleceń — obejrzyj plik .eml bezpośrednio.

Ścieżkę dostarczenia czyta się od dołu do góry: najstarszy przeskok jest na dole, Received: serwera odbierającego na samej górze.

Tożsamości, które mają znaczenie

Są dwie wartości „od”, a phishing wykorzystuje właśnie różnicę między nimi:

• Nadawca koperty (Return-Path / MAIL FROM) — używany do trasowania i odbić; sprawdzany przez SPF.
• From z nagłówka (From:) — to, co użytkownik widzi w programie pocztowym.

Podszycie zwykle pokazuje zaufany From:, podczas gdy Return-Path wskazuje zupełnie gdzie indziej.

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

Nazwa wyświetlana (IT Helpdesk) jest w pełni kontrolowana przez napastnika i niczego nie dowodzi.

Odczytywanie Authentication-Results

Zdecydowanie najważniejszy nagłówek to Authentication-Results, dodany przez Twój serwer odbierający (ufaj tylko temu z własnej domeny, na samej górze):

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

Czytaj uważnie:

• spf=pass jest tu pułapką — przeszedł dla sketchy-host.ru, a nie dla widocznego yourbank.example. SPF sprawdza kopertę, nie From:.
• dkim=fail — brak ważnego podpisu wyrównanego z domeną z From:.
• dmarc=fail (p=reject) — oto werdykt, który się liczy: uwierzytelnienie widocznej domeny nie jest wyrównane. Wiadomość, która mimo dmarc=fail trafia do skrzynki, wymaga uwagi.

Zawsze porównuj domenę, którą dany mechanizm faktycznie uwierzytelnił (smtp.mailfrom, header.d), z domeną z From:. Uwierzytelnienie bez wyrównania nic nie znaczy.

Śledzenie trasy przez Received

Każdy przeskok dopisuje na górze linię Received:. Czytaj od dołu:

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 ...

Czerwone flagi:

• Adres IP pierwszego przeskoku geolokalizuje się daleko od miejsca, w którym nadawca rzekomo jest.
• Sfałszowane HELO (localhost albo nazwa hosta niezgodna z odwrotnym DNS).
• Podejrzane luki albo skoki stref czasowych w znacznikach czasu.
• Pierwszy zaufany przeskok to Twój własny MX — wszystko poniżej pochodzi od napastnika i da się sfałszować, więc odpowiednio to waż.

Inne poszlaki w nagłówkach

• Rozbieżny Reply-To — From: wygląda na współpracownika, ale Reply-To kieruje odpowiedzi na adres zewnętrzny. Klasyk w BEC i oszustwie na prezesa.
• Domena Message-ID niezgodna z domeną wysyłającą.
• Nagłówki X-Mailer / X-PHP-Script zdradzające narzędzie do masowej wysyłki albo skrypt PHP na przejętym serwerze.
• Unicode/punycode w domenie z From: (xn--) — atak homograficzny.

Szybka lista kontrolna

1. Czy domena z From: == domena Return-Path?           (rozbieżność = podejrzane)
2. Authentication-Results: dmarc=pass i wyrównane?      (fail = podejrzane)
3. Jaką domenę faktycznie uwierzytelniły SPF/DKIM?      (musi zgadzać się z From:)
4. Czy Reply-To różni się od From:?                     (tak = podejrzane)
5. Skąd pochodzi najniższy przeskok Received?           (nieoczekiwana geo = podejrzane)
6. Punycode/homoglify w domenie z From:?                (tak = podejrzane)

Pojedynczy nagłówek rzadko sam dowodzi podszycia. Werdykt płynie z wyrównania: czy domena, która się uwierzytelniła, zgadza się z tą, którą widzi człowiek? DMARC istnieje właśnie po to, by zautomatyzować to porównanie — ale przy poczcie przychodzącej z cudzych domen wciąż trzeba je czytać ręcznie.

Jak pomaga GottaPhish

Czytanie nagłówków to umiejętność reaktywna i ekspercka, a większość użytkowników nigdy ich nie ogląda. GottaPhish i jego zespół ekspertów zasypują tę przepaść: realistyczny symulowany phishing — luki w wyrównaniu, podmiana Reply-To, domeny łudząco podobne — plus pulpity pokazujące dokładnie, kto zgłosił, kto kliknął, a kto podał dane logowania. Nasi eksperci pomagają przy wdrożeniu, projektują scenariusze ćwiczące dokładnie te sztuczki nagłówkowe, których używają prawdziwi napastnicy, i pomagają interpretować wyniki — wyostrzając procedury segregacji dla zespołów technicznych, podczas gdy szkolenia uczą wszystkich pozostałych widocznych sygnałów kryjących się za tymi nagłówkami.