Jak czytać nagłówki e-mail: od Received do ARC

Program pocztowy pokazuje cztery pola nagłówka — From, To, Subject, Date — a resztę ukrywa. Te ukryte zapisują, które serwery obsłużyły wiadomość, czy przeszła SPF, DKIM i DMARC, a czasem także, dlaczego filtr uznał ją za spam. Ten poradnik wyjaśnia, jak je czytać, którym ufać i jak je bezpiecznie wyeksportować i udostępnić.

Najszybciej: pobierz pełne nagłówki (instrukcja pod koniec) i wklej je do analizatora nagłówków e-mail, który analizuje je w przeglądarce i niczego nie wysyła.

Nagłówki to stos: czytaj od dołu

Każdy serwer, który przyjmuje wiadomość, dopisuje swoje wiersze śledzące na górze. RFC 5321 wymaga, by każdy serwer SMTP wstawiał swój nagłówek Received na początku, i zabrania zmieniania, usuwania i przestawiania istniejących. Najnowsze wiersze są więc na górze, a pola zapisane przez program pocztowy nadawcy — From, To, Subject, Date, Message-ID — niżej. Żeby prześledzić drogę wiadomości, czytaj nagłówki Received od dołu do góry.

Uproszczona wiadomość w postaci, w jakiej dotarła do anna@example.net:

Return-Path: <bounces+7f3a@mail.example.com>
Delivered-To: anna@example.net
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=mail.example.com;
       dkim=pass header.d=example.com header.s=s2026;
       dmarc=pass header.from=example.com
Received: from out1.mail.example.com (out1.mail.example.com [192.0.2.25])
        by mx.example.net with ESMTPS id 4Q8fKx2
        for <anna@example.net>; Fri, 23 Oct 2026 09:14:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s2026;
        h=from:to:subject:date:message-id; bh=…; b=…
Received: from app1.example.com (app1.example.com [198.51.100.10])
        by out1.mail.example.com with ESMTPSA id 91c2d0;
        Fri, 23 Oct 2026 09:14:03 +0000
From: Example Shop <orders@example.com>
To: anna@example.net
Subject: Your order 1042
Date: Fri, 23 Oct 2026 09:14:02 +0000
Message-ID: <20261023091402.7f3a@example.com>

Od dołu: serwer sklepu app1 przekazał wiadomość serwerowi wychodzącemu out1, ten podpisał ją DKIM i dostarczył do mx.example.net, który sprawdził uwierzytelnienie i umieścił wiadomość w skrzynce.

Received: jeden wiersz na każdy przeskok

Fragment	Znaczenie
from out1.mail.example.com	nazwa, którą serwer wysyłający podał w EHLO
(… [192.0.2.25])	to, co zobaczył odbiorca: zwykle nazwę z odwrotnego DNS i adres IP połączenia
by mx.example.net	serwer, który przyjął wiadomość i zapisał wiersz
with ESMTPS	ESMTPS = użyto STARTTLS, ESMTPA = z uwierzytelnieniem, ESMTPSA = jedno i drugie (RFC 3848); samo ESMTP lub SMTP = bez TLS
id 4Q8fKx2	identyfikator kolejki — podaj go, pytając operatora tego serwera
for <…>	opcjonalnie: odbiorca tej kopii
data po ;	kiedy ten serwer przyjął wiadomość

Na co patrzeć:

• Opóźnienia. Odejmij od siebie kolejne znaczniki czasu. Długa przerwa na jednym odcinku wskazuje na ten serwer: kolejkę, greylisting, ponowienia. Niewielkie ujemne opóźnienie zwykle oznacza źle ustawiony zegar serwera.
• Moment przekazania. Znajdź najniższy wiersz Received zapisany przez Twojego dostawcę poczty. Jego część from to serwer, który przekazał wiadomość — prawdziwe źródło w takim zakresie, w jakim możesz je zweryfikować.
• Reszta to deklaracje. Wiersze poniżej zapisały serwery, nad którymi nie masz kontroli, a nadawca może tam dopisać zmyślone przeskoki, żeby wprowadzić Cię w błąd.

Return-Path: dokąd trafiają odbicia

Serwer, który ostatecznie doręcza wiadomość, dodaje Return-Path z adresem nadawcy z koperty — z polecenia MAIL FROM w sesji SMTP (RFC 5321). Tam trafiają odbicia i tę domenę sprawdza SPF. Często różni się od From; to w porządku, o ile DMARC jest spełniony dzięki DKIM albo zgodnej domenie odbić (zgodność domen DMARC). Return-Path: <> to pusty nadawca z koperty, którego używają same odbicia, żeby nie wywoływać kolejnych odbić; SPF sprawdza wtedy nazwę z HELO.

Authentication-Results: werdykt

W Authentication-Results (RFC 8601) serwer odbiorcy zapisuje, co sprawdził i z jakim wynikiem (zob. przykład wyżej):

• Pierwszy element, mx.example.net, to authserv-id — identyfikator usługi, która wykonała sprawdzenia.
• Każdy wynik to metoda=wynik plus właściwości: smtp.mailfrom (domena z koperty sprawdzana przez SPF), header.d i header.s (domena podpisująca i selektor DKIM), header.i (tożsamość DKIM), header.from (domena From oceniana przez DMARC).
• Wyniki: pass, fail, softfail (SPF), neutral, none, temperror (błąd przejściowy, często DNS), permerror (błąd trwały, np. uszkodzony rekord) i policy (sprawdzenie przeszło, ale lokalna polityka nie zaakceptowała wyniku). W nawiasach są dowolne komentarze.

Możesz też zobaczyć arc= (o tym niżej), iprev= (odwrotny DNS adresu IP połączenia) i auth= (uwierzytelnienie SMTP). Microsoft 365 dodaje compauth= — swój łączny werdykt dla domeny From — z kodem reason= opisanym w dokumentacji Microsoftu.

Któremu ufać

Wiadomość może mieć kilka takich nagłówków: od Twojego dostawcy, od serwerów, przez które przeszła wcześniej, a czasem fałszywe, dopisane przez nadawcę. RFC 8601 rozwiązuje to za pomocą authserv-id: serwery brzegowe muszą usuwać istniejące nagłówki podające się za wynik ich organizacji, a oprogramowanie powinno korzystać tylko z wyników, których authserv-id należy do jego własnej organizacji. W praktyce:

1. Znajdź wiersz Received, w którym Twój dostawca przyjął wiadomość z zewnątrz.
2. Korzystaj z Authentication-Results zapisanego przez Twojego dostawcę — zwykle tuż nad tym wierszem, na samej górze lub blisko niej.
3. Pozostałe traktuj jako historię: to, co widział wcześniejszy serwer, a nie to, co zdecydował Twój dostawca.

Analizator nagłówków grupuje wyniki według authserv-id serwera, który je zapisał. Odczytuje zapisane werdykty; nie weryfikuje ponownie podpisów i nie odpytuje DNS.

DKIM-Signature: kto podpisał i co

Tag	Znaczenie
d=	domena podpisująca — porównaj z domeną From pod kątem zgodności domen
s=	selektor; klucz jest pod s2026._domainkey.example.com (Sprawdzanie DKIM)
a=	rsa-sha256 lub ed25519-sha256; weryfikatory nie mogą akceptować rsa-sha1
c=	kanonikalizacja nagłówka/treści: relaxed toleruje zmiany białych znaków, simple prawie żadnych
h=	podpisane pola nagłówka; from musi być wśród nich
bh=, b=	skrót treści, podpis
i=, t=, x=	opcjonalnie: tożsamość, czas podpisania, wygaśnięcie
l=	opcjonalna długość treści; to, co dopisano dalej, nie jest objęte podpisem — znana słabość

Dwa podpisy — Twojej domeny i usługi wysyłkowej — to nic dziwnego; DMARC potrzebuje jednego, który przechodzi i jest zgodny. Sam podpis tylko deklaruje, kto podpisał; wynik weryfikacji jest w Authentication-Results. Więcej w poradniku jak działa DKIM.

ARC: wyniki, które przetrwają przekazanie

Gdy lista dyskusyjna dopisuje stopkę albo usługa przekazuje wiadomość dalej, podpis DKIM może stracić ważność, a SPF nie przechodzi, więc DMARC zawodzi, choć oryginał był w porządku. ARC, czyli Authenticated Received Chain (RFC 8617, RFC eksperymentalny), pozwala każdemu pośrednikowi zapisać, co zobaczył, zanim cokolwiek zmienił. Pośrednik dodaje zestaw ARC — trzy nagłówki o wspólnym numerze instancji i=:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; t=…; b=…
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.example.org;
        s=arc1; h=from:to:subject:date; bh=…; b=…
ARC-Authentication-Results: i=1; mx.lists.example.org;
        spf=pass smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com; dmarc=pass header.from=example.com

• ARC-Authentication-Results: wyniki, które pośrednik uzyskał po odebraniu wiadomości — składnia Authentication-Results plus i=.
• ARC-Message-Signature: podpis podobny do DKIM, obejmujący wiadomość w postaci przekazanej dalej.
• ARC-Seal: podpis nagłówków ARC; cv= zapisuje stan łańcucha, który otrzymał pieczętujący: none (brak wcześniejszych zestawów), pass lub fail.

Kolejny pośrednik dodaje i=2 i tak dalej, najwyżej do 50 zestawów. Ostateczny odbiorca zapisuje wynik, np. arc=pass, we własnym Authentication-Results.

ARC dowodzi, którzy pośrednicy obsłużyli wiadomość, a nie tego, że są uczciwi. Każdy odbiorca sam decyduje, którym pieczętującym ufa, i dopiero wtedy może przyjąć ich wyniki mimo niepowodzenia DMARC. Nadawca nie doda ARC do cudzego przekazywania poczty; podpisywanie wszystkiego DKIM ogranicza szkody.

Nagłówki z werdyktem filtra antyspamowego

Niektóre filtry zapisują werdykt w wiadomości, w niestandardowych nagłówkach X-:

• SpamAssassin, popularny u dostawców hostingu: X-Spam-Status: Yes, score=7.4 required=5.0 tests=… i X-Spam-Flag: YES. Nazwy testów wyjaśniają wynik.
• Microsoft 365: X-Forefront-Antispam-Report z SFV:SPM (spam) lub SFV:NSPM (nie spam), CAT: (zastosowana polityka, np. SPM, PHSH, BULK) i SCL: (poziom pewności spamu); X-Microsoft-Antispam zawiera BCL: (poziom skarg na pocztę masową). Microsoft zaznacza, że w organizacjach w chmurze wartość SCL nie decyduje o tym, czy wiadomość zostanie uznana za spam, ani o tym, co się z nią stanie; żeby sprawdzić, jak ją przefiltrowano, odsyła do CAT i DIR (kierunek wiadomości).

Nie każdy dostawca ujawnia werdykt, a kopia w folderze „Wysłane” nadawcy nigdy nie pokazuje, co postanowił serwer odbiorcy — poproś odbiorcę o jego nagłówki. Typowe przyczyny opisujemy w poradniku dlaczego maile trafiają do spamu.

Jak pobrać pełne nagłówki

W nawiasach nazwy z angielskiej wersji interfejsu.

• Gmail (w przeglądarce): otwórz wiadomość, ⋮ (Więcej) obok Odpowiedz → Pokaż oryginał (Show original), potem Kopiuj do schowka (Copy to clipboard) lub Pobierz oryginał (Download original).
• Outlook w przeglądarce, Outlook.com, nowy Outlook dla Windows: Więcej akcji (⋯, More actions) → Widok (View) → Wyświetl szczegóły wiadomości (View message details).
• Klasyczny Outlook dla Windows: otwórz wiadomość w osobnym oknie, Plik → Właściwości (File → Properties); nagłówki są w polu Nagłówki internetowe (Internet headers).
• Apple Mail na Macu: Widok → Wiadomość → Wszystkie nagłówki (View → Message → All Headers) albo Surowe źródło (Raw Source) w tym samym menu, żeby zobaczyć całą wiadomość.
• Thunderbird: Widok → Źródło wiadomości (View → Message Source), Ctrl+U, na Macu ⌘U.

Większość aplikacji na telefon nie pokazuje nagłówków; użyj poczty w przeglądarce albo programu na komputerze. Nagłówki kończą się na pierwszym pustym wierszu; analizator przyjmie same nagłówki albo całe źródło.

Bezpieczne udostępnianie nagłówków

Nagłówki zdradzają więcej, niż się wydaje: imiona, nazwiska i adresy nadawcy i wszystkich odbiorców; adresy IP i wewnętrzne nazwy serwerów, a u niektórych dostawców także urządzenia nadawcy; temat i Message-ID; wreszcie osobiste tokeny, np. link z List-Unsubscribe — który zadziała dla każdego, kto go otworzy.

Zanim wkleisz nagłówki na forum albo do zgłoszenia:

1. Udostępnij same nagłówki, nie całe źródło — treść może zawierać dane osobowe, tokeny i załączniki.
2. Zamieniaj adresy konsekwentnie (anna@example.net → user@example.net), żeby trasa pozostała czytelna.
3. Usuń adresy URL z List-Unsubscribe i inne linki z tokenami.
4. Zostaw w całości Received, Authentication-Results, DKIM-Signature i ARC-*; długie wartości b= możesz skrócić.