Jak czytać nagłówki wiadomości e-mail, aby sprawdzić SPF, DKIM i DMARC

Każda wiadomość e-mail niesie ze sobą blok metadanych zwany nagłówkami, który rejestruje, skąd pochodzi wiadomość, przez jakie serwery przeszła oraz czy przeszła weryfikację SPF, DKIM i DMARC. Aby sprawdzić uwierzytelnienie, otwierasz surowe źródło, odnajdujesz nagłówek Authentication-Results, a następnie odczytujesz werdykty spf=, dkim= i dmarc= wraz z domenami, względem których były sprawdzane. Ten przewodnik prowadzi przez cały nagłówek od góry do dołu, dzięki czemu potwierdzisz, że wiadomość jest wiarygodna, albo dokładnie wskażesz, dlaczego weryfikacja się nie powiodła.

Jak wyświetlić surowe źródło

Potrzebne informacje znajdują się w surowym źródle, a nie w wyświetlanej treści wiadomości. Każdy z głównych programów pocztowych udostępnia je w inny sposób.

• Gmail (przeglądarka): Otwórz wiadomość, kliknij trzy pionowe kropki w prawym górnym rogu panelu wiadomości i wybierz Pokaż oryginał. Gmail wyświetli pełne nagłówki oraz tabelę podsumowującą, w której SPF, DKIM i DMARC oznaczone są jako PASS lub FAIL.
• Outlook (nowy komputerowy i webowy): Otwórz wiadomość, kliknij trzy kropki (...) obok przycisków odpowiedzi, następnie Widok i Wyświetl źródło wiadomości. W klasycznym Outlooku na komputerze otwórz wiadomość, przejdź do Plik, potem Właściwości i odczytaj pole Nagłówki internetowe.
• Apple Mail (macOS): Zaznacz wiadomość, następnie wybierz Widok, Wiadomość i Źródło surowe (albo naciśnij Command+Option+U). Pamiętaj, że aplikacja Mail na iOS i iPadOS nie potrafi wyświetlić surowego źródła, więc do diagnozy użyj programu na komputerze.

Gdy masz już przed sobą surowy tekst, zacznij czytać od dołu do góry.

Łańcuch Received

Nagłówki Received tworzą ostemplowany dziennik podróży wiadomości. Każdy serwer, który obsługuje wiadomość, dodaje na górze własny wiersz Received, więc łańcuch czyta się w odwrotnej kolejności chronologicznej: najstarszy przeskok (serwer źródłowy) znajduje się na dole, a serwer, który dostarczył wiadomość do Twojej skrzynki, na górze.

Pojedynczy przeskok wygląda tak:

Received: from mail.example.com (mail.example.com [192.0.2.10])
        by mx.google.com with ESMTPS id abc123
        for <you@yourdomain.com>; Tue, 04 Jul 2026 09:14:22 -0700 (PDT)

Odczytaj to następująco: serwer odbierający (by mx.google.com) przyjął wiadomość from hosta, który przedstawił się jako mail.example.com i połączył się z adresu IP 192.0.2.10. To właśnie ten adres IP w nawiasach kwadratowych oceniają weryfikacje SPF i PTR i to jest element, którego atakujący nie może sfałszować. Aby prześledzić prawdziwe pochodzenie wiadomości, zacznij od dolnego wiersza Received i potwierdź, że wysyłający adres IP należy do sieci, której się spodziewasz. Wiarygodna wiadomość transakcyjna powinna pokazywać krótki, sensowny łańcuch; długi objazd przez niepowiązane hosty zasługuje na bliższe przyjrzenie się. Nazwa z odwrotnego DNS przypisana do tego pierwszego adresu IP ma znaczenie dla dostarczalności, co omawiamy w artykule czym jest rekord PTR.

Return-Path i nadawca koperty

Nagłówek Return-Path rejestruje nadawcę koperty, nazywanego też adresem zwrotnym lub MAIL FROM. Różni się on od adresu From:, który widzi odbiorca. SPF uwierzytelnia domenę koperty z Return-Path (MAIL FROM według RFC 5321), a nie widoczną domenę From: (RFC 5322) - dlatego te dwie mogą się różnić i dlatego istnieje odrębne pojęcie zgodności (alignment).

Return-Path: <bounces@mail.example.com>
From: "Example Billing" <billing@example.com>

Tutaj SPF sprawdzany jest względem mail.example.com (domena z Return-Path), podczas gdy odbiorca widzi example.com. Jeśli te dwie domeny współdzielą tę samą domenę organizacyjną, SPF jest zgodny na potrzeby DMARC. Jeśli platforma wysyłkowa używa własnej domeny zwrotnej niepowiązanej z Twoją domeną From:, SPF może przejść, a mimo to nie spełnić zgodności DMARC. Pełny obraz znajdziesz w artykule czym jest Return-Path.

Nagłówek Authentication-Results

To nagłówek, który odpowiada na pytanie wprost. Serwer odbierający zapisuje go po przeprowadzeniu weryfikacji i powinieneś ufać wyłącznie kopii dodanej przez serwer, który faktycznie dostarczył wiadomość do Ciebie (tej znajdującej się najwyżej, pochodzącej od Twojego własnego dostawcy). Typowy wiersz wygląda tak:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@mail.example.com designates 192.0.2.10 as permitted sender) smtp.mailfrom=bounces@mail.example.com;
       dkim=pass header.i=@example.com header.s=selector1 header.b=Gw+yUxcC;
       dmarc=pass (p=REJECT sp=REJECT dis=none) header.from=example.com

Podziel go na trzy werdykty.

SPF

spf=pass oznacza, że wysyłający adres IP (192.0.2.10) jest autoryzowany przez rekord SPF domeny z smtp.mailfrom. Wartość smtp.mailfrom mówi Ci, która domena była sprawdzana. pass w tym miejscu dowodzi jedynie, że domena koperty autoryzowała ten adres IP; nie mówi nic o widocznym From:, dopóki nie wejdzie w grę zgodność DMARC. Jeśli widzisz spf=permerror, rekord SPF nie mógł zostać oceniony, najczęściej dlatego, że przekroczył limit 10 zapytań DNS. Zobacz SPF PermError kontra TempError oraz jak naprawić zbyt wiele zapytań DNS w SPF.

DKIM

dkim=pass oznacza, że podpis kryptograficzny został zweryfikowany względem klucza publicznego opublikowanego w DNS. Dla zgodności liczą się dwa pola:

• header.d (lub header.i) to domena podpisująca. Tutaj jest to example.com.
• header.s to selektor, selector1, który mówi odbiorcy, który klucz pobrać spod selector1._domainkey.example.com. Nowoczesne konfiguracje używają kluczy 2048-bitowych.

DKIM przetrwa przekierowanie wiadomości, w przeciwieństwie do SPF, więc często to właśnie ta weryfikacja utrzymuje DMARC w stanie pass, gdy wiadomość jest przekazywana dalej.

DMARC

dmarc=pass to werdykt, który decyduje o skrzynce odbiorczej. DMARC przechodzi tylko wtedy, gdy SPF lub DKIM przejdzie oraz domena, która przeszła, jest zgodna z widoczną domeną From: (header.from=example.com). Polityka w nawiasie pokazuje, o co poprosił właściciel domeny: p=none (tylko monitorowanie), p=quarantine (skierowanie do spamu) lub p=reject (odrzucenie). dis=none raportuje działanie, które odbiorca faktycznie zastosował, czyli w tym przypadku brak działania, ponieważ wiadomość przeszła weryfikację.

Po pełniejszy opis samego tego nagłówka sięgnij do artykułu jak czytać nagłówek Authentication-Results. O samych protokołach przeczytasz w SPF, DKIM i DMARC wyjaśnione.

Diagnozowanie błędu

Gdy pojawi się dmarc=fail, przeanalizuj wyniki metodycznie.

1. Sprawdź, czy SPF lub DKIM w ogóle przeszły. Jeśli obie pokazują fail, wiadomość nie została uwierzytelniona żadną metodą. Potwierdź, że wysyłający adres IP z dolnego wiersza Received znajduje się w Twoim rekordzie SPF i że platforma podpisuje wiadomości kluczem DKIM.
2. Jeśli SPF przechodzi, ale DMARC zawodzi, podejrzewaj zgodność. Porównaj smtp.mailfrom z header.from. Różne domeny organizacyjne oznaczają, że SPF nie jest zgodny. Dedykowana domena zwrotna lub własna domena Return-Path pod Twoją nazwą zwykle to naprawia.
3. Jeśli DKIM przechodzi, ale DMARC zawodzi, sprawdź domenę podpisującą. Porównaj header.d z header.from. Jeśli platforma podpisuje własną domeną, podpis jest ważny, ale niezgodny. Dodanie firmowego klucza DKIM na Twojej domenie rozwiązuje problem. Zobacz jak naprawić zgodność DKIM.
4. Jeśli wiadomość została przekazana dalej, spodziewaj się, że SPF się załamie. Przekazywanie zmienia ścieżkę, ale nie From:, więc SPF zawodzi względem adresu IP przekazującego. DKIM powinien wciąż przenieść wiadomość przez weryfikację. Omawiamy to w artykule dlaczego przekazywanie e-maili psuje SPF.

Zgodność może być relaxed (subdomena domeny organizacyjnej liczy się jako zgodna) lub strict (wymagane jest dokładne dopasowanie), co zmienia to, co uznaje się za pass. Zobacz zgodność DMARC relaxed kontra strict.

Dlaczego nagłówki mają znaczenie dla dostarczalności

Czytanie nagłówków przydaje się nie tylko w celach śledczych. Zasady dla masowych nadawców od Gmaila, Yahoo i Microsoftu wymagają, aby poczta była uwierzytelniona, a nagłówki to miejsce, w którym tego dowodzisz. Nadawcy wysyłający ponad 5000 wiadomości dziennie do Gmaila muszą przechodzić SPF i DKIM, opublikować DMARC na domenie From:, utrzymywać wskaźnik skarg na spam raportowany w Postmaster Tools poniżej 0,3% (najlepiej poniżej 0,1%), przesyłać wiadomości przez TLS, opublikować prawidłowy, potwierdzony w obie strony rekord PTR oraz oferować rezygnację z subskrypcji jednym kliknięciem zgodnie z RFC 8058 w poczcie marketingowej. Gdy przeprowadzasz audyt próbki własnej poczty wychodzącej, nagłówek Authentication-Results jest najszybszym potwierdzeniem, że spełniony jest każdy z wymogów. Zobacz wymagania dla nadawców Google i Yahoo.

Najczęściej zadawane pytania

Któremu nagłówkowi Authentication-Results powinienem ufać?

Ufaj wyłącznie temu znajdującemu się najwyżej, zapisanemu przez Twojego własnego dostawcę odbierającego pocztę. Każdy nagłówek Authentication-Results położony niżej w łańcuchu został dodany przez serwer nadrzędny i może zostać sfałszowany przez nadawcę, dlatego odbiorca usuwa je lub ignoruje. Miarodajny jest nagłówek ostemplowany przez serwer, który dostarczył wiadomość do Twojej skrzynki.

Dlaczego SPF przechodzi, a DMARC mimo to zawodzi?

SPF uwierzytelnia domenę z Return-Path (koperty), podczas gdy DMARC wymaga, aby ta domena była zgodna z widoczną domeną From:. Jeśli Twoja platforma wysyłkowa używa własnej domeny zwrotnej, SPF przechodzi, ale nie jest zgodny, więc DMARC zawodzi, chyba że zgodny jest za to DKIM. Skonfigurowanie własnej domeny Return-Path pod Twoją domeną przywraca zgodność.

Czy mogę czytać nagłówki na telefonie?

Możesz je wyświetlić w mobilnej wersji webowej Gmaila oraz w niektórych aplikacjach innych firm, ale aplikacja Mail na iOS i iPadOS nie potrafi wyświetlić surowego źródła. Dla wiarygodnej diagnozy otwórz wiadomość w programie na komputerze, takim jak Gmail w przeglądarce, Outlook lub Apple Mail na macOS, gdzie dostępne jest pełne surowe źródło.

Czy nagłówki Received dowodzą, skąd przyszła wiadomość?

Adres IP w nawiasach kwadratowych w dolnym wierszu Received to najbardziej wiarygodny sygnał pochodzenia, ponieważ jest zapisywany przez serwer odbierający i nie może zostać sfałszowany przez nadawcę. Deklarowane nazwy hostów można podrobić, więc zawsze weryfikuj łączący się adres IP względem sieci, której się spodziewasz, oraz względem wyniku SPF.

Czytanie nagłówków ręcznie to właściwa umiejętność, ale nie musisz robić tego dla każdej wiadomości. Przeskanuj swoją domenę darmowym skanerem SPFWise, aby zobaczyć status SPF, DKIM i DMARC w mgnieniu oka, potwierdzić zgodność i wychwycić błędne konfiguracje, które objawiają się jako błędy w tych nagłówkach, zanim kosztują Cię miejsce w skrzynce odbiorczej.