Odczytywanie nadawcy i nagłówków
Moduł 3: Rozpoznawanie phishingu · Czas czytania: 13 minut
Cel lekcji: Po tej lekcji będą Państwo potrafili ocenić nadawcę wiadomości e-mail na podstawie nazwy wyświetlanej, adresu From, Reply-To, Return-Path, linii Received oraz wyniku SPF, DKIM i DMARC w polu Authentication-Results.
Najważniejsze pojęcia: nazwa wyświetlana, From, Reply-To, Return-Path, Received, Authentication-Results, wynik SPF/DKIM/DMARC, wyrównanie (alignment)
Co widać, a co jest naprawdę zapisane
Program pocztowy zwykle pokazuje tylko niewielką część informacji o nadawcy: nazwę, czasem adres. Za tym kryje się blok technicznych linii, których Państwo nie widzą, czyli nagłówki. Zapisane jest w nich, za kogo podaje się nadawca, dokąd mają trafiać odpowiedzi, przez jakie serwery wiadomość przeszła oraz co sprawdził Państwa serwer pocztowy.
Nie trzeba być informatykiem, aby je odczytać. Potrzebnych jest sześć elementów:
| Nagłówek | Co to jest | Kto go wypełnia |
|---|---|---|
| Nazwa wyświetlana | Nazwa przed adresem, na przykład Mojbank | Nadawca, dowolnie wybrana |
From | Widoczny adres nadawcy | Nadawca |
Reply-To | Adres, na który trafia odpowiedź po kliknięciu Odpowiedz | Nadawca |
Return-Path | Techniczny adres nadawcy dla komunikatów o błędach (nadawca koperty) | Państwa serwer pocztowy, na podstawie danych podanych przez nadawcę |
Received | Jedna linia na każdy serwer, który przekazał wiadomość dalej | Każdy serwer na trasie |
Authentication-Results | Wynik SPF, DKIM i DMARC | Państwa serwer pocztowy |
Pierwsze trzy pola nadawca może wypełnić dowolnie. Dopiero przy ostatnich trzech pojawia się kontrola.
Nazwa wyświetlana niczego nie dowodzi
Nazwa wyświetlana to zwykły tekst. Każdy może wpisać jako nazwę "Obsługa klienta Mojbank" albo imię i nazwisko Państwa dyrektora. Wiele programów pocztowych, zwłaszcza w telefonie, pokazuje wyłącznie tę nazwę. Znanym trikiem jest umieszczenie adresu wewnątrz nazwy:
From: "info@mojbank.example" <noreply@aanvaller.example>Widoczne jest info@mojbank.example, ale prawdziwy adres znajduje się w nawiasach ostrokątnych. Dlatego zawsze należy kliknąć lub stuknąć w nazwę, aby zobaczyć pełny adres.
Również sam adres From może zostać sfałszowany: w protokole pocztowym serwer może podać dowolny adres From. To, czy uda się to zrobić bez wylądowania w folderze ze spamem, zależy od ustawień SPF, DKIM i DMARC domeny, która jest podszywana. O tym jest reszta tej lekcji.
Reply-To: odpowiedź trafia do kogoś innego
Dzięki polu Reply-To wiadomość mówi: "nie odpowiadaj mnie, lecz na ten adres". Newslettery i formularze na stronach internetowych normalnie z tego korzystają. Oszuści używają tego, aby przejąć rozmowę. Wiadomość pochodzi z prawdziwego lub pozornie prawdziwego adresu, ale Państwa odpowiedź z żądanymi danymi lub potwierdzeniem płatności trafia do atakującego.
From: Dostawca Mąki <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>Przy prośbie o pieniądze lub dane zawsze należy sprawdzić adres w oknie odpowiedzi, zanim klikną Państwo Wyślij.
Return-Path, Received i trasa wiadomości
Return-Path to adres, na który trafiają komunikaty o błędach. Nazywany jest również nadawcą koperty: to adres na zewnętrznej stronie koperty, podczas gdy From znajduje się na samym liście. To właśnie tę domenę sprawdza SPF. Przy newsletterach i fakturach z programu księgowego Return-Path często wskazuje na domenę usługi wysyłkowej. To normalne.
Każdy serwer, który przekazuje wiadomość dalej, dopisuje linię Received na górze. Czyta się je więc od dołu do góry: najniższa linia to początek trasy, najwyższa to ostatni przystanek (Państwa własny serwer pocztowy). Uwaga: zaufać można wyłącznie najwyższym liniom, dodanym przez Państwa własnego dostawcę. Poniżej nadawca może dołączyć zmyślone linie.
Authentication-Results: wynik kontroli
Państwa własny serwer pocztowy przy odbiorze sprawdza trzy rzeczy (więcej wyjaśnień w module 4 oraz w kursie DNS):
- SPF: czy ten serwer miał prawo wysyłać pocztę dla domeny podanej w Return-Path?
- DKIM: czy podpis cyfrowy się zgadza i z jakiej domeny pochodzi (
d=lubheader.d=)? - DMARC: czy przynajmniej jedna z tych dwóch pomyślnych kontroli należy do domeny podanej w polu From? Nazywa się to wyrównaniem (alignment). "Należy do" oznacza: ta sama domena rejestrowalna (lekcja 3.2).
mail.mojbank.examplejest wyrównana zmojbank.example(ta sama domena rejestrowalna).
Wynik znajduje się w polu Authentication-Results. Proszę ufać wyłącznie linii, na początku której widnieje nazwa Państwa własnego serwera pocztowego; nadawca może dołączyć własną, podobną linię.
| Wynik | Znaczenie |
|---|---|
pass | Kontrola zakończona pomyślnie |
fail | Kontrola nieudana: brak uprawnień albo niezgodny podpis |
softfail (SPF) | Prawdopodobnie brak uprawnień, ale domena nie chce stanowczo odrzucać (~all) |
none | Nie było nic do sprawdzenia: brak rekordu lub brak podpisu |
Najważniejsza lekcja: dmarc=pass oznacza jedynie "ta wiadomość rzeczywiście pochodzi z domeny podanej w From". Nie mówi nic o tym, czy tej domenie można ufać. Atakujący z własną domeną łudząco podobną do oryginału może mieć wszystko ustawione na pass.
W praktyce: tak to wygląda
Trzy odtworzone bloki nagłówków, skrócone do linii, które mają znaczenie. Odbiorcą jest Piekarnia Example; własny serwer pocztowy nazywa się mx1.example.com.
Przykład 1: prawdziwa wiadomość.
Return-Path: <bounce-7731@mail.mijnbank.example>
Received: from out3.mail.mijnbank.example (out3.mail.mijnbank.example [198.51.100.40])
by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 09:14:06 +0100
Authentication-Results: mx1.example.com;
spf=pass smtp.mailfrom=mail.mijnbank.example;
dkim=pass header.d=mijnbank.example header.s=sel2026;
dmarc=pass (p=reject) header.from=mijnbank.example
From: Mijnbank <info@mijnbank.example>
To: info@example.com
Subject: Je jaaroverzicht 2026 staat klaarDomena w From to mijnbank.example, podpis DKIM pochodzi z mijnbank.example, a Return-Path należy do tej samej domeny: obie wartości są wyrównane, DMARC kończy się pomyślnie. Wiadomość rzeczywiście pochodzi z tej domeny. Mimo to po roczne podsumowanie proszę przejść przez własną zakładkę do strony banku.
Przykład 2: sfałszowany nadawca.
Return-Path: <x7@mailer.aanvaller.example>
Received: from mailer.aanvaller.example (mailer.aanvaller.example [203.0.113.66])
by mx1.example.com with ESMTP; Sun, 08 Nov 2026 10:02:41 +0100
Authentication-Results: mx1.example.com;
spf=pass smtp.mailfrom=mailer.aanvaller.example;
dkim=none;
dmarc=fail (p=none) header.from=leverancier.example
From: Dostawca Mąki <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>
Subject: Nieuw rekeningnummerSPF kończy się pomyślnie, ale dla domeny aanvaller.example, nie dla domeny z From. Brak podpisu. DMARC więc zawodzi. Ponieważ dostawca ma ustawione p=none, wiadomość i tak została dostarczona. Przy p=reject zostałaby odrzucona. Do tego dochodzi jeszcze Reply-To wskazujące na inną domenę. Fałszywka.
Przykład 3: domena łudząco podobna, wszystko na pass.
Return-Path: <service@mijnbank-veilig.example>
Received: from smtp.mijnbank-veilig.example (smtp.mijnbank-veilig.example [192.0.2.77])
by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 11:20:13 +0100
Authentication-Results: mx1.example.com;
spf=pass smtp.mailfrom=mijnbank-veilig.example;
dkim=pass header.d=mijnbank-veilig.example header.s=k1;
dmarc=pass (p=reject) header.from=mijnbank-veilig.example
From: Mijnbank Klantenservice <service@mijnbank-veilig.example>
Subject: Proszę potwierdzić swoje dane w celu wydania nowej karty płatniczejWszystko kończy się pomyślnie, ponieważ atakujący poprawnie skonfigurował ustawienia dla własnej domeny. Ale mijnbank-veilig.example to nie to samo co mijnbank.example prawdziwego banku. Fałszywka.
Samodzielne otwieranie nagłówków. W poczcie webowej opartej na Roundcube (jak u WebOké) proszę otworzyć wiadomość i w menu Więcej (trzy kropki) wybrać Pokaż źródło. Inne programy nazywają to na przykład "Pokaż oryginał" albo "Źródło wiadomości". W tekście proszę wyszukać Authentication-Results. Na telefonie często nie jest to możliwe; proszę wtedy obejrzeć wiadomość w poczcie webowej na komputerze.
Podsumowanie
- Nazwę wyświetlaną, From i Reply-To wpisuje sam nadawca. Przed udzieleniem odpowiedzi zawsze należy sprawdzić prawdziwy adres oraz pole Reply-To.
- Return-Path to adres koperty, który sprawdza SPF. Linie Received czyta się od dołu do góry; zaufać można wyłącznie tym dodanym przez własnego dostawcę.
- Authentication-Results podaje wynik SPF, DKIM i DMARC. DMARC sprawdza, czy SPF lub DKIM jest wyrównane z domeną w From.
dmarc=failprzy znanej domenie to mocny sygnał fałszerstwa.dmarc=passdowodzi jedynie, że wiadomość pochodzi z domeny podanej w From. Zawsze należy sprawdzić, czy ta domena jest prawdziwa.
Quiz
Zadanie
Zadanie A3.3: Czytanie nagłówków. Otrzymają Państwo trzy bloki nagłówków. Dla każdego z nich należy podać: domenę w Return-Path, domenę podpisu DKIM (d=), wynik DMARC oraz informację, czy wiadomość jest prawdziwa czy fałszywa. Program sprawdza odpowiedzi i w razie błędu wskazuje linię, w której znajduje się poprawna odpowiedź.
Więcej informacji
Kroki opisane w artykułach WebOké dotyczą środowiska WebOké; u innych dostawców działanie jest podobne.
- Czym jest DMARC? Wyjaśnienie w prostych słowach
- Wiadomość e-mail nie dociera lub trafia do spamu: jak to sprawdzić
- Publiczne sprawdzenie poczty e-mail (SPF, DMARC, MX) dla domeny: https://www.weboke.pl/sprawdz-e-mail, oraz test poczty internet.nl: https://internet.nl
- Kurs DNS, lekcje 4.3 SPF, 4.4 DKIM i 4.5 DMARC: https://www.weboke.pl/dns-cursus
- RFC 8601, Authentication-Results: https://www.rfc-editor.org/rfc/rfc8601
