SPF a DKIM a DMARC: jaka jest różnica?

Co robi SPF?

SPF odpowiada na jedno pytanie: czy serwer, który dostarczył tę wiadomość, może wysyłać dla tej domeny? Właściciel domeny publikuje rekord TXT zaczynający się od v=spf1, który wymienia dozwolone źródła, na przykład include:_spf.protonmail.ch dla Proton Mail. Odbiorca porównuje łączący się adres IP z listą i otrzymuje wynik: pass, fail, softfail lub neutral, zależnie od kwalifikatora na końcu (-all, ~all lub ?all).

SPF sprawdza nadawcę koperty (MAIL FROM) i nazwę HELO, a nie adres From, który widzi czytelnik. Ta luka jest powodem istnienia DMARC. SPF ma też twarde limity: domena musi mieć tylko jeden rekord SPF, a ocena kończy się błędem trwałym po 10 terminach wykonujących zapytania DNS (include, a, mx, ptr, exists, redirect). Pełną metodę opisuje przewodnik tworzenie rekordu SPF.

Co robi DKIM?

DKIM odpowiada na inne pytanie: czy ta wiadomość została podpisana przez domenę, którą podaje, i czy dotarła niezmieniona? Serwer wysyłający podpisuje wybrane nagłówki i treść kluczem prywatnym. Odbiorca odczytuje domenę podpisującą (d=) i selektor (s=) z nagłówka DKIM-Signature, pobiera klucz publiczny w selector._domainkey.domain w DNS i sprawdza podpis.

Ponieważ podpis podróżuje razem z wiadomością, DKIM przetrwa przekazanie dalej, które zostawia wiadomość nienaruszoną, czego SPF nie robi, bo przekazujący wysyła z własnego adresu IP. RFC 6376 mówi, że podpisujący muszą używać kluczy RSA o długości co najmniej 1024 bitów dla kluczy długotrwałych, i zaleca nowe selektory przy zmianie kluczy. Dostawcy publikują klucze za Ciebie: trzy rekordy CNAME dla Proton Mail i Fastmail, cztery dla Mailbox.org. Szczegóły są w przewodniku konfiguracja DKIM.

Co robi DMARC?

DMARC wiąże SPF i DKIM z widoczną domeną From i mówi odbiorcom, co zrobić, gdy żadna z kontroli się nie zgadza. Wiadomość przechodzi DMARC, gdy SPF lub DKIM przechodzi, a uwierzytelniona domena pasuje do domeny From. Dopasowanie jest domyślnie swobodne (ta sama domena organizacyjna), a ścisłe, gdy ustawisz aspf=s lub adkim=s.

Rekord znajduje się w _dmarc.yourdomain i zawiera politykę: p=none (tylko monitorowanie), p=quarantine (traktuj jako podejrzane) lub p=reject (odrzuć). Adres rua otrzymuje raporty zbiorcze, które pokazują, kto wysyła pocztę w Twoim imieniu. RFC 9989, opublikowane w maju 2026, jest obecną specyfikacją; unieważnia RFC 7489, usuwa tag pct i dodaje flagę testową t. Przejście od monitorowania do odrzucania opisuje przewodnik konfiguracja DMARC.

Czy potrzebuję wszystkich trzech?

Tak: własna domena, która wysyła pocztę, powinna publikować SPF, DKIM i DMARC, ponieważ najwięksi odbiorcy ich wymagają. Wytyczne Google dla nadawców wymagają SPF, DKIM i rekordu DMARC (wystarczy polityka none) od nadawców powyżej 5,000 wiadomości dziennie na konta Gmail. Microsoft prosi nadawców Outlook.com powyżej 5,000 dziennie o te same trzy, od 5 maja 2025, a Yahoo wymaga SPF, DKIM i DMARC także od nadawców masowych.

Osobista skrzynka wysyła znacznie mniej wiadomości, więc progi Cię nie wiążą. Rekordy nadal decydują, czy Twoja poczta trafi do skrzynki odbiorczej, i powstrzymują innych przed podrabianiem Twojego adresu. Według zestawienia Postelva z 12 listopada 2026 ze stron pomocy dostawców pełna konfiguracja Proton Mail to 8 rekordów DNS, a pełna konfiguracja Mailbox.org to 11, z czego 3 i 4 to klucze DKIM. Rekordy MX opisuje czym jest rekord MX.

Które błędy psują te trzy rekordy?

Trzy błędy powodują większość awarii: drugi rekord SPF, więcej niż 10 zapytań oraz zbyt ścisła polityka DMARC ustawiona zbyt wcześnie. Domena z dwoma rekordami SPF zwraca błąd trwały, więc dodaj include nowego dostawcy do istniejącego rekordu. Nałożenie hosta pocztowego, narzędzia newslettera i systemu zgłoszeń może przekroczyć 10 zapytań i rekord zawodzi wtedy dla każdego nadawcy. Mailbox.org i Proton radzą zaczynać DMARC od p=none, a Mailbox.org ostrzega, że zbyt ścisła polityka zastosowana zbyt wcześnie może odbijać prawidłową pocztę.

Czwartym błędem jest trzymanie wpisów DKIM i SPF poprzedniego dostawcy przez miesiące. Nie szkodzą dostarczaniu, ale poszerzają listę serwerów uprawnionych do występowania w Twoim imieniu. Usuń je, gdy przeprowadzka zostanie potwierdzona.

Jak te trzy współpracują przy jednej wiadomości?

Odbiorca uruchamia SPF i DKIM, a DMARC łączy wyniki. Weźmy wiadomość od [email protected] wysłaną przez Proton Mail. SPF przechodzi, jeśli łączący się serwer jest na liście _spf.protonmail.ch. DKIM przechodzi, jeśli podpis wykonany kluczem pod yourname.com jest poprawny. DMARC pyta wtedy, czy co najmniej jedna z tych kontroli przeszła z yourname.com w zgodnym identyfikatorze. Jeśli tak, wiadomość przechodzi; jeśli nie, odbiorca stosuje Twoją politykę i odnotowuje wynik w następnym raporcie zbiorczym.

RFC 9989 zauważa, że domena z p=reject nie może polegać wyłącznie na SPF i powinna podpisywać DKIM, ponieważ SPF psuje się przy przekazywaniu dalej. ARC (RFC 8617), standard eksperymentalny, pozwala przekazującym zapisać oryginalne wyniki, choć nie jest częścią Twojej własnej konfiguracji. Po opublikowaniu rekordów sprawdź je za pomocą dig, zanim zaostrzysz jakąkolwiek politykę.

Definicja do zacytowania: SPF autoryzuje serwery, DKIM uwierzytelnia wiadomości, a DMARC egzekwuje zgodność z domeną From i raportuje wynik.