Czytanie nagłówków: skąd przyszła ta wiadomość?

Moduł 1: Jak działa poczta e-mail · Czas czytania: 11 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili otworzyć nagłówki wiadomości, odczytać linie Received we właściwej kolejności oraz na podstawie Authentication-Results sprawdzić, czy SPF, DKIM i DMARC zakończyły się powodzeniem.

Kluczowe pojęcia: nagłówki (headers), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, nagłówki X-, źródło lub oryginalna wiadomość

Czego zwykle Państwo nie widzą

Program pocztowy pokazuje z wiadomości tylko kilka informacji: nadawcę, temat, datę, odbiorców. W rzeczywistości każda wiadomość ma na początku, przed treścią, kilkadziesiąt nagłówków (headers). Są one dodawane przez program nadawcy oraz przez każdy serwer, który po drodze styka się z wiadomością. Razem tworzą one dziennik podróży wiadomości.

Kto potrafi czytać nagłówki, może samodzielnie odpowiedzieć na wiele pytań: czy ta wiadomość rzeczywiście pochodzi z mojego banku? Dlaczego dotarła dopiero po dwóch godzinach? Dlaczego trafiła do spamu? Czy moje własne DKIM działa poprawnie? Wiele zadań w tym kursie wymaga od Państwa przyjrzenia się nagłówkom. W tej lekcji nauczą się Państwo, jak to robić.

Otwieranie nagłówków

Każdy program ma na to inny przycisk:

Na telefonie zwykle nie jest to możliwe. Proszę wtedy przekazać wiadomość do siebie jako załącznik lub otworzyć ją w webmailu.

Przykład

Jan otrzymuje wiadomość od Anny. Tak wyglądają najważniejsze nagłówki (w skróconej formie):

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Linie Received: od dołu do góry

Każdy serwer, który przekazuje wiadomość, dopisuje linię Received: na górze. Najstarsza znajduje się więc na dole, najnowsza na górze. Proszę czytać je od dołu do góry, aby prześledzić podróż wiadomości:

1. Dolna linia: laptop Anny (IP 198.51.100.77, jej domowe łącze) dostarcza wiadomość do out.hosting.example, przy użyciu ESMTPSA (litera A oznacza authenticated: Anna się zalogowała) i TLS 1.3. O godzinie 10:15:04.
2. Środkowa linia: out.hosting.example (192.0.2.25) dostarcza wiadomość do mx1.mailprovider.example, serwera MX domeny example.net. O godzinie 10:15:07.
3. Górna linia: serwer pocztowy umieszcza wiadomość wewnętrznie w skrzynce Jana (LMTP). O godzinie 10:15:09.

Linia Received ma zawsze postać from <kto zaoferował> by <kto przyjął> with <protokół>; <czas>. W nawiasie po from znajduje się to, co zobaczył sam serwer odbierający: prawdziwa nazwa (PTR) i prawdziwy adres IP. Ta część jest wiarygodna w takim stopniu, w jakim Państwo ufają temu serwerowi odbierającemu. Natomiast to, co sam nadawca zadeklarował (helo=), nie jest możliwe do zweryfikowania.

Dwie praktyczne wskazówki:

• Wyszukiwanie opóźnienia: proszę porównać godziny. Jeśli między dwiema liniami widać dwie godziny różnicy, oznacza to, że wiadomość tyle czasu czekała w kolejce. Proszę zwrócić uwagę na strefy czasowe (+0100, +0000).
• Znajdowanie prawdziwego serwera nadawcy: proszę znaleźć najwyższą linię Received, która została zapisana przez serwer samego odbiorcy, i sprawdzić, co znajduje się tam po from. Wszystko poniżej zostało zapisane przez stronę wysyłającą i teoretycznie może być zmyślone. W przykładzie 192.0.2.25 to serwer, który dostarczył wiadomość do odbiorcy; na jego podstawie ocenia się SPF i reputację.

Adresy

Znany trik oszustów: pole From przypominające adres banku, z polem Reply-To wskazującym na zupełnie inny adres. W razie wątpliwości proszę zawsze sprawdzić domenę w polach From i Return-Path oraz Authentication-Results.

Authentication-Results: ocena odbiorcy

Serwer odbierający zapisuje w nagłówku Authentication-Results (RFC 8601) wyniki swoich kontroli:

• spf=pass smtp.mailfrom=example.com: adres IP serwera, który dostarczył wiadomość, znajduje się w rekordzie SPF domeny z pola Return-Path.
• dkim=pass header.d=example.com header.s=x: podpis DKIM domeny example.com, z kluczem (selektorem) x, jest prawidłowy.
• dmarc=pass header.from=example.com: domena w polu From jest zgodna (aligned) z pomyślnym SPF lub DKIM, więc DMARC zakończyło się powodzeniem.

Inne wyniki, które mogą się Państwo spotkać: fail (niezgodność), softfail (SPF kończy się na ~all, a adres IP nie znajduje się w rekordzie), neutral, none (brak rekordu), temperror (tymczasowy błąd DNS) oraz permerror (uszkodzony rekord, na przykład dwa rekordy SPF). Dokładne znaczenie tych wyników oraz sposób ich naprawy opisano w module 4.

Proszę pamiętać: należy ufać jedynie nagłówkowi Authentication-Results pochodzącemu od serwera samego odbiorcy (nazwa na początku, tutaj mx1.mailprovider.example). Sfałszowana wiadomość może zawierać własny, zmyślony nagłówek Authentication-Results. Dobre serwery go usuwają, ale nie wszystkie.

DKIM-Signature: podpis

Nagłówek DKIM-Signature to sam podpis. Często potrzebne są dwa pola:

• d= domena, która podpisuje (tutaj example.com);
• s= selektor, nazwa klucza (tutaj x).

Dzięki temu można znaleźć klucz publiczny w DNS: x._domainkey.example.com. W zadaniach i przy rozwiązywaniu problemów będą Państwo często musieli dokładnie te dwie wartości odnaleźć. Wiadomość może mieć kilka podpisów DKIM, na przykład jeden z Państwa domeny i jeden z usługi wysyłkowej. W lekcji 4.3 zajmiemy się tym tematem dokładniej.

Czasem widoczne są też ARC-Seal, ARC-Message-Signature i ARC-Authentication-Results. ARC (RFC 8617) to sposób, w jaki stacje pośredniczące, takie jak lista mailingowa lub serwer przekierowujący, zapisują wyniki kontroli sprzed zmiany wiadomości. Nie muszą Państwo na razie umieć ich odczytywać.

Nagłówki X-

Nagłówki rozpoczynające się od X- nie są ustandaryzowane. Filtry antyspamowe zapisują w nich swój wynik, na przykład X-Spam-Status: No, score=1.2 lub X-Spam-Flag: YES. Pomaga to ustalić, dlaczego wiadomość trafiła do spamu. Różnią się one w zależności od dostawcy.

Podsumowanie

• Nagłówki to dziennik podróży wiadomości. Proszę otworzyć je za pomocą opcji "pokaż oryginał", "źródło wiadomości" lub podobnej.
• Linie Received proszę czytać od dołu do góry. Linia zapisana przez serwer odbiorcy wskazuje, który adres IP dostarczył wiadomość.
• Return-Path to nadawca koperty (SPF), From to widoczny nadawca (DMARC), Reply-To wskazuje, dokąd trafiają odpowiedzi.
• Authentication-Results zawiera ocenę SPF, DKIM i DMARC; należy ufać wyłącznie wynikowi od serwera odbierającego.
• W DKIM-Signature znajdują się d= (domena) i s= (selektor); razem wskazują miejsce przechowywania klucza: s._domainkey.d.

Quiz

Zadanie

Zadanie Z1.5: Analiza nagłówków wiadomości. Proszę wysłać do siebie wiadomość z innego adresu (na przykład z adresu służbowego na prywatny lub odwrotnie), otworzyć nagłówki i wkleić je do formularza. Jeśli nie mają Państwo drugiego adresu, proszę użyć przykładowego pliku kopregels-1.txt, dołączonego do zadania. Następnie proszę samodzielnie uzupełnić: adres IP serwera, który dostarczył wiadomość do odbiorcy, domenę z Return-Path, domenę i selektor podpisu DKIM oraz wynik SPF, DKIM i DMARC. Program analizuje te same nagłówki, na żywo wyszukuje klucz DKIM i zestawia swój wynik z Państwa odpowiedzią. Przesłane nagłówki nie są przechowywane.

Dalsza lektura

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to w podobny sposób.

• Sprawdzanie, czy e-mail dotarł, za pomocą śledzenia e-maili w DirectAdmin
• Instrukcja DirectAdmin 9.3: Śledzenie e-mail: gdzie podziała się moja wiadomość?
• Czy ta wiadomość rzeczywiście pochodzi od WebOké? Jak rozpoznać phishing i skorzystać z kodu promocyjnego
• Bezpłatny kurs DNS 4.4: DKIM: podpis pod Państwa pocztą
• RFC 5322 (budowa wiadomości e-mail), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)