SPF sprawdza serwer, który wysłał Twoją pocztę. DKIM podpisuje samą wiadomość. Odpowiadają na dwa różne pytania i właśnie dlatego odbiorcy tacy jak Gmail, Yahoo i Microsoft oczekują dziś obu mechanizmów na każdej domenie, która wysyła realny wolumen poczty. Jeśli masz tylko jeden z nich, Twoja poczta jest o jedno przekazanie wiadomości lub jedno niedopasowanie zgodności od folderu spam.
Oto wersja skrócona: SPF (Sender Policy Framework, RFC 7208) publikuje listę adresów IP uprawnionych do wysyłania poczty w imieniu Twojej domeny, a odbiorca sprawdza, czy łączący się serwer znajduje się na tej liście. DKIM (DomainKeys Identified Mail, RFC 6376) dołącza do każdej wiadomości podpis kryptograficzny, dzięki czemu odbiorca może potwierdzić, że treść i domena wysyłająca nie zostały zmodyfikowane. Potrzebujesz obu, ponieważ SPF zawodzi, gdy poczta jest przekazywana dalej, a DKIM nie, oraz dlatego, że najwięksi dostawcy skrzynek pocztowych traktują teraz oba jako wymóg podstawowy.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Model myślowy w jednym zdaniu
SPF to lista gości przy wejściu. Gdy serwer łączy się, aby dostarczyć pocztę rzekomo pochodzącą z Twojej domeny, odbiorca odczytuje Twój rekord SPF i zadaje proste pytanie: czy ten adres IP ma prawo wysyłać w imieniu tej domeny? Jeśli tak, SPF przechodzi. Jeśli nie, SPF zawodzi. Nie mówi nic o treści wiadomości.
DKIM to zabezpieczona przed manipulacją pieczęć na kopercie. Twój serwer wysyłający podpisuje wybrane nagłówki oraz treść kluczem prywatnym i publikuje pasujący klucz publiczny w DNS. Odbiorca ponownie oblicza podpis i potwierdza dwie rzeczy: wiadomość nie została zmieniona w tranzycie oraz została faktycznie autoryzowana przez domenę wskazaną w podpisie DKIM. DKIM interesuje się wiadomością, a nie serwerem, który ją przeniósł.
Ta jedna różnica (serwer kontra wiadomość) napędza wszystko inne, w tym powód, dla którego nie możesz bezpiecznie zrezygnować z żadnego z nich.
SPF i DKIM obok siebie
| Właściwość | SPF | DKIM |
|---|---|---|
| Co sprawdza | Adres IP serwera wysyłającego | Podpis kryptograficzny na wiadomości |
| Gdzie się znajduje | Rekord TXT na Twojej domenie | Klucz publiczny w DNS, podpis w nagłówku poczty |
| RFC | 7208 | 6376 |
| Przetrwa przekazanie dalej | Nie, adres IP serwera przekazującego nie jest na Twojej liście | Tak, podpis podróżuje razem z wiadomością |
| Chroni treść wiadomości | Nie | Tak, skrót treści wykrywa manipulację |
| Główny tryb awarii | Zbyt wiele odpytań DNS, błędne adresy IP, +all | Uszkodzony podpis, błędny selektor, zmodyfikowana treść |
| Jaką tożsamość weryfikuje | Domenę MAIL FROM (return-path) | Domenę d= w podpisie DKIM |
Ostatni wiersz jest ważniejszy, niż się wydaje. SPF uwierzytelnia ukryty adres return-path, a nie adres From:, który widzi Twój odbiorca. DKIM uwierzytelnia domenę d= ze swojego podpisu. Żaden z nich samodzielnie nie gwarantuje, że widoczny adres From: jest prawdziwy. Tę lukę zamyka DMARC, wymagając zgodności (alignment), i dlatego te trzy mechanizmy omawia się zwykle razem w SPF, DKIM i DMARC wyjaśnione.
Dlaczego przekazywanie psuje SPF, ale nie DKIM
To najlepszy pojedynczy powód, aby stosować oba. Załóżmy, że ktoś z Twojego zespołu przekazuje wiadomość dalej, lista mailingowa ją retransmituje albo użytkownik ustawił przekierowanie ze starego adresu na nowy. Wiadomość opuszcza teraz serwer, którego nie ma w Twoim rekordzie SPF. SPF sprawdza łączący się adres IP, widzi serwer, którego nigdy nie autoryzowałeś, i zawodzi. Z Twoją pocztą nie było nic nie tak. Przeskok przekazujący po prostu zmienił serwer wysyłający.
DKIM nic to nie obchodzi. Podpis został obliczony, zanim wiadomość opuściła Twoją infrastrukturę, i podróżuje wewnątrz nagłówków wiadomości. Dopóki serwer przekazujący nie przepisze podpisanych nagłówków ani nie zniekształci treści, DKIM nadal przechodzi weryfikację w miejscu docelowym. Dlatego na przekazanej wiadomości zwykle otrzymujesz porażkę SPF i sukces DKIM, a DMARC potrzebuje tylko jednego z dwóch, aby przeszedł ze zgodnością, aby wiadomość przetrwała. Domena z samym DKIM straciłaby zgodność SPF przy bezpośrednim dostarczaniu do skrzynki; domena z samym SPF traci wszystko w chwili, gdy wiadomość zostaje przekazana dalej. Głębsze mechanizmy opisano w dlaczego przekazywanie poczty psuje SPF.
Czy potrzebujesz obu? Tak, i oto dlaczego
Trzy powody sprawiają, że w 2026 roku jest to nienegocjowalne.
Redundancja na różnych ścieżkach dostarczania
Poczta bezpośrednia z Twoich własnych serwerów zwykle przechodzi SPF bez problemu. Poczta przekazywana i retransmitowana zwykle przechodzi tylko DKIM. Stosowanie obu oznacza, że przynajmniej jedna metoda uwierzytelniania przetrwa na niemal każdej ścieżce, jaką może obrać Twoja poczta. Zrezygnuj z jednego, a tworzysz kategorię legalnej poczty, która po cichu zawodzi.
DMARC potrzebuje czegoś, z czym może się zgadzać
DMARC (RFC 7489) nie dodaje nowej weryfikacji, lecz egzekwuje te, które już masz. Przechodzi, gdy SPF lub DKIM przechodzi, a przechodząca tożsamość zgadza się z widoczną domeną From:. Jeśli skonfigurowany jest tylko SPF, a wiadomość zostanie przekazana dalej, DMARC nie ma już czym przejść, a Twoja polityka kieruje wiadomość do kwarantanny lub ją odrzuca. Dwa zgodne mechanizmy dają DMARC dwie szanse na przejście.
Gmail, Yahoo i Microsoft wymagają teraz obu
Od lutego 2024 roku Google i Yahoo wymagają od masowych nadawców uwierzytelniania zarówno za pomocą SPF, jak i DKIM oraz opublikowania rekordu DMARC. Microsoft wprowadził równoważne egzekwowanie dla nadawców o dużym wolumenie do Outlooka i Hotmaila. "Masowość" zaczyna się od około 5000 wiadomości dziennie do jednego dostawcy, ale bezpieczne założenie jest takie, że oba mechanizmy są oczekiwane od każdego realnego nadawcy. Pełną listę kontrolną znajdziesz w przewodniku wymagania nadawcy Google i Yahoo.
Jak wygląda każdy z rekordów
Rekord SPF to pojedynczy rekord TXT na Twojej domenie głównej. Powinien kończyć się na -all (twarda porażka) lub ~all (miękka porażka), nigdy +all:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Rekord DKIM to rekord TXT w subdomenie właściwej dla selektora. Selektor (tutaj s1) pozwala uruchamiać i rotować wiele kluczy:
s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB..."
Skonfiguruj SPF ostrożnie, aby pozostać poniżej limitu 10 odpytań DNS, co krok po kroku omówiono w jak skonfigurować SPF. Następnie opublikuj DKIM i potwierdź, że selektor pasuje do tego, którym podpisuje Twoja platforma wysyłkowa, co opisano w jak skonfigurować DKIM. Zawsze potwierdzaj dokładne wartości rekordów w panelu swojego dostawcy wysyłki, ponieważ selektory i hosty include różnią się w zależności od platformy.
Którego mechanizmu brakuje w mojej domenie?
Najszybszy sposób na odpowiedź to spojrzeć na rzeczywisty wynik zamiast zgadywać. Przepuść swoją domenę przez skaner powyżej, a pokaże on w jednym widoku, czy SPF rozwiązuje się w ramach limitu odpytań, czy opublikowany jest prawidłowy klucz DKIM oraz czy oba zgadzają się w ramach Twojej polityki DMARC. Większość domen, które trafiają do spamu, w ogóle nie ma DKIM lub ma rekord SPF, który po cichu przekracza dziesięć odpytań i zwraca trwały błąd. Zobaczenie, który z dwóch jest uszkodzony, mówi Ci dokładnie, gdzie warto spędzić kolejne dziesięć minut.
Najczęściej zadawane pytania
Czy DKIM jest ważniejszy niż SPF?
Żaden nie zastępuje drugiego. DKIM jest bardziej odporny, ponieważ przetrwa przekazywanie, ale SPF nadal jest weryfikacją potwierdzającą Twoje bezpośrednie serwery wysyłające i jest wprost wymagany przez Gmaila, Yahoo i Microsoft. Stosuj oba, a następnie dodaj DMARC, aby chroniona była widoczna domena From:.
Czy mogę używać samego SPF lub samego DKIM?
Technicznie protokoły działają niezależnie, ale nie powinieneś polegać na jednym z nich. Poczta z samym SPF zawodzi w chwili, gdy zostaje przekazana dalej, a poczta z samym DKIM traci bezpośrednią zgodność SPF. Główni dostawcy skrzynek oczekują teraz obu przy wysyłce masowej, więc pojedyncza metoda naraża dostarczalność.
Czy SPF lub DKIM samodzielnie powstrzymuje podszywanie się?
Nie. SPF weryfikuje return-path, a DKIM weryfikuje domenę d=, ale żaden nie gwarantuje adresu From:, który widzi Twój odbiorca. Dopiero DMARC wiąże przechodzący wynik SPF lub DKIM z widocznym From:, co faktycznie blokuje podszywanie się pod łudząco podobne domeny.
Co, jeśli SPF przechodzi, ale DKIM zawodzi, albo odwrotnie?
To normalne i często w porządku. DMARC potrzebuje tylko jednego z dwóch, aby przeszedł ze zgodnością. Częstym wzorcem jest przechodzący DKIM przy zawodzącym SPF na przekazanej poczcie. Jeśli oba zawiodą lub przechodzący nie jest zgodny, wkracza egzekwowanie DMARC i wiadomość może zostać poddana kwarantannie lub odrzucona.