SPF, DKIM i DMARC: czym się różnią i co robią

O SPF, DKIM i DMARC mówi się zwykle jednym tchem, ale każdy z nich odpowiada na inne pytanie:

• SPF: czy ten serwer może wysyłać pocztę w imieniu domeny nadawcy z koperty?
• DKIM: czy wiadomość została podpisana przez jakąś domenę i czy od tego czasu nikt jej nie zmienił?
• DMARC: czy któryś z tych wyników dotyczy domeny z adresu From, a jeśli nie — co zrobić z wiadomością?

Żaden z nich nie wystarcza sam. Dopiero razem pozwalają odbiorcy ustalić, czy wiadomość naprawdę pochodzi z domeny, którą widzi czytelnik.

Porównanie

	SPF	DKIM	DMARC
Specyfikacja	RFC 7208	RFC 6376 (+ RFC 8301, 8463)	RFC 9989 (2026)
Gdzie się go publikuje	TXT w domenie wysyłającej	TXT pod selektor._domainkey.domena	TXT pod _dmarc.domena
Co uwierzytelnia	domenę nadawcy z koperty (MAIL FROM)	domenę podpisującą d=	nic nowego — ocenia wyniki SPF i DKIM
Na czym się opiera	adres IP serwera wysyłającego	podpis kryptograficzny	zgodność z nagłówkiem From
Czy przetrwa przekazanie dalej	nie	zwykle tak, jeśli wiadomość nie zostanie zmieniona	zależy od SPF/DKIM
Czy mówi odbiorcom, co robić	nie	nie	tak (p=none, quarantine, reject)
Czy wysyła Ci raporty	nie	nie	tak (rua=)

SPF: kto może wysyłać

Domena wymienia w DNS dozwolone serwery, a odbiorca porównuje z tą listą adres IP, który się z nim połączył. To proste, ale obejmuje tylko nadawcę z koperty — adres dla odbić, którego czytelnik nigdy nie widzi — i przestaje działać, gdy wiadomość zostaje przekazana dalej, bo serwera, który ją przekazuje, nie ma na Twojej liście. Szczegóły znajdziesz w poradniku Co to jest SPF i jak działa?.

DKIM: podpis, który podróżuje z wiadomością

Serwer wysyłający podpisuje kluczem prywatnym wybrane nagłówki i treść wiadomości, a następnie dodaje nagłówek DKIM-Signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s2026;
        h=from:to:subject:date:message-id; bh=…; b=…

Odbiorca pobiera klucz publiczny z s2026._domainkey.example.com i weryfikuje podpis. Poprawny podpis dowodzi, że domena example.com wzięła odpowiedzialność za wiadomość i że podpisane części nie zostały zmienione. Ponieważ podpis jest częścią wiadomości, przetrwa przekazanie dalej — dopóki coś nie zmieni tematu albo nie doklei stopki, jak robi to wiele list dyskusyjnych.

Używaj kluczy RSA o długości co najmniej 1024 bitów (zalecane 2048); serwery weryfikujące podpisy muszą odrzucać krótsze klucze i podpisy SHA-1 (RFC 8301). Opublikowany klucz zweryfikujesz narzędziem Sprawdzanie DKIM.

DMARC: powiązanie z tym, co widzi czytelnik

Ani SPF, ani DKIM nie patrzą na adres From. Oszust może wysyłać pocztę z własnego serwera, z własnym rekordem SPF i własnym podpisem DKIM — oba przejdą — a w nagłówku From i tak podać adres w domenie Twojej firmy.

DMARC zamyka tę lukę dzięki zgodności domen (alignment): przechodzi tylko wtedy, gdy SPF lub DKIM przeszły dla domeny pasującej do domeny z From. Pozwala też opublikować politykę dla wiadomości, które tej weryfikacji nie przejdą.

Zgodność domen na przykładzie

Twoje narzędzie do newsletterów wysyła wiadomość z takimi nagłówkami:

From: Example Shop <news@example.com>
Return-Path: <bounce-7f3a@em.mailer.example-esp.net>
DKIM-Signature: … d=mailer.example-esp.net …

SPF przechodzi dla mailer.example-esp.net, DKIM przechodzi dla mailer.example-esp.net — a DMARC nie przechodzi, bo żadna z tych domen nie jest domeną example.com. Są dwa rozwiązania, a każde z nich wystarcza samo:

1. Własny DKIM: niech usługa podpisuje wiadomości z d=example.com (publikujesz jej klucz, często jako CNAME). DKIM jest wtedy zgodny.
2. Własna domena return-path: niech usługa używa domeny odbić w rodzaju bounce.example.com. SPF jest wtedy zgodny w trybie swobodnym (relaxed).

Jeśli wdrażasz tylko jedno, wybierz pierwsze: DKIM przetrwa przekazanie dalej, SPF nie.

Czy potrzebuję wszystkich trzech?

Tak, jeśli wysyłasz pocztę ze swojej domeny do dużych dostawców skrzynek:

• Gmail wymaga od wszystkich SPF lub DKIM, a od nadawców wysyłających ponad 5000 wiadomości dziennie na konta Gmail — SPF i DKIM oraz rekordu DMARC (wystarczy p=none).
• Yahoo stosuje podobne zasady wobec nadawców masowych.
• Microsoft od maja 2025 roku wymaga SPF, DKIM i DMARC od nadawców wysyłających ponad 5000 wiadomości dziennie na adresy w Outlook.com, Hotmail.com i Live.com.

Nawet poniżej tych progów poczta, która ma wszystkie trzy mechanizmy ze zgodnymi domenami, po prostu częściej trafia do skrzynki odbiorczej. A wymuszająca polityka DMARC to jedyny z tych trzech elementów, który faktycznie powstrzymuje podszywanie się pod Twoją domenę.

A co z przekazywaniem dalej i listami dyskusyjnymi?

Przekazywanie dalej psuje SPF, a listy dyskusyjne, które modyfikują wiadomości, psują DKIM. Gdy zawiodą oba, DMARC nie przechodzi, choć to nie Twoja wina. Duzi odbiorcy korzystają z ARC (Authenticated Received Chain, RFC 8617): pośrednicy zapisują wyniki uwierzytelnienia, które widzieli przed zmianą wiadomości, a odbiorcy ufający danemu pośrednikowi mogą je uwzględnić. Nie skonfigurujesz ARC na cudzych listach, ale podpisywanie całej Twojej poczty DKIM ogranicza skutki do minimum.

Krótka lista kontrolna

1. Jeden rekord SPF, który obejmuje każdą usługę wysyłającą pocztę z Twoją domeną i mieści się w limicie 10 zapytań DNS — Sprawdzanie SPF.
2. Podpisywanie DKIM Twoją domeną w każdej usłudze wysyłkowej, w miarę możliwości kluczami 2048-bitowymi — Sprawdzanie DKIM.
3. Rekord DMARC z adresem rua, zaczynając od p=none i dochodząc do p=reject — Sprawdzanie DMARC oraz poradnik konfiguracji DMARC krok po kroku.
4. Weryfikacja na prawdziwej wiadomości: spf=pass, dkim=pass i dmarc=pass w nagłówku Authentication-Results — analizator nagłówków e-mail.