Co naprawdę robią SPF, DKIM i DMARC
Traktuj je jak jeden łańcuch z trzema ogniwami. SPF autoryzuje serwery, które mogą wysyłać pocztę w imieniu Twojej domeny. DKIM dołącza podpis kryptograficzny, dzięki któremu odbiorca może sprawdzić, że wiadomość nie została zmieniona po drodze. DMARC wiąże oba z domeną, którą czytelnik faktycznie widzi w polu From:, i publikuje politykę na wypadek, gdy kontrola zawiedzie. Mówiąc prosto: SPF sprawdza kopertę, DKIM sprawdza treść, a DMARC sprawdza, czy którykolwiek z nich zgadza się z nazwą, którą czyta Twój odbiorca.
SPF: które serwery mogą wysyłać w imieniu Twojej domeny
Rekord SPF to pojedynczy wpis TXT w DNS, który zaczyna się od v=spf1, wymienia hosty i mechanizmy include uprawnione do wysyłania poczty dla domeny i kończy się mechanizmem all. Dwie zasady często zaskakują. Po pierwsze, domena może opublikować tylko jeden rekord v=spf1; drugi sprawia, że ewaluacja zwraca permerror, a uwierzytelnianie w praktyce zawodzi (RFC 7208, sekcja 4.5). Po drugie, podczas ewaluacji SPF może wykonać najwyżej dziesięć mechanizmów wymagających zapytań DNS – include, a, mx, ptr, exists oraz modyfikator redirect; po przekroczeniu dziesięciu wynikiem znów jest permerror (sekcja 4.6.4). Końcowy kwalifikator to polityka: ~all oznacza softfail (przyjmij, ale oznacz), -all oznacza hardfail (odrzuć nadawców spoza listy), a +all przepuściłby wszystko – dlatego nigdy go nie publikujesz. Jedno ograniczenie konstrukcyjne warto znać: SPF uwierzytelnia ukrytą domenę Return-Path, a nie widoczną From:, i przestaje działać przy przekierowaniu, bo adresu IP serwera przekierowującego nie ma w Twoim rekordzie – i właśnie dlatego DMARC nie polega na samym SPF.
DKIM: podpis, którego nic nie zmieni po cichu
DKIM podpisuje każdą wychodzącą wiadomość kluczem prywatnym przechowywanym przez Twój system wysyłkowy i publikuje odpowiadający mu klucz publiczny w DNS. Podpis obejmuje wybrane nagłówki i treść, więc jeśli cokolwiek zostanie zmienione w drodze, weryfikacja podpisu kończy się niepowodzeniem. Odbiorcy znajdują klucz przez selektor: nagłówek DKIM-Signature zawiera s= (selektor) i d= (Twoją domenę), a weryfikator pobiera klucz publiczny z selector._domainkey.yourdomain (RFC 6376, sekcja 3.6.2.1). Selektory pozwalają też używać kilku kluczy jednocześnie, dzięki czemu rotacja przebiega czysto – opublikuj nowy selektor, przenieś na niego podpisywanie, a potem wycofaj stary (pusta wartość klucza oznacza, że został unieważniony). Co do długości klucza: RFC 6376 wymaga co najmniej 1024-bitowych kluczy RSA do długotrwałego użytku, a weryfikatory muszą obsługiwać klucze do 2048 bitów; 2048 bitów to rozsądny współczesny standard, a okresowa rotacja kluczy ogranicza szkody, jeśli któryś kiedyś wycieknie.
DMARC: polityka, która spina całość
DMARC to rekord, dzięki któremu SPF i DKIM coś znaczą dla domeny, którą czyta Twój odbiorca. Jego główną ideą jest wyrównanie (alignment). Wiadomość przechodzi DMARC tylko wtedy, gdy SPF lub DKIM daje wynik pozytywny, a ten wynik opiera się na identyfikatorze wyrównanym z widoczną domeną From: (RFC 7489, sekcja 4.2). Dlatego wiadomość może przejść sam SPF, a mimo to nie przejść DMARC: jeśli Twój dostawca usług e-mail (ESP) wysyła z własną domeną Return-Path, SPF przechodzi dla ESP, ale ta domena nie jest wyrównana z Twoją domeną From:, więc część SPF w DMARC zawodzi. Wyrównanie ma dwa tryby – łagodny (relaxed), który akceptuje zgodną domenę organizacyjną (mail.yourco.com jest wyrównana z yourco.com), i ścisły (strict), który wymaga dokładnej zgodności. Ponieważ wystarczy jeden wyrównany mechanizm, zwykle wyrównanie DKIM ratuje pocztę, z którą SPF sobie nie radzi, np. przekierowane wiadomości. Sam rekord wygląda tak: v=DMARC1; p=none; rua=mailto:reports@yourco.com; znacznik p ustawia politykę (none, quarantine lub reject), rua wskazuje, dokąd trafiają raporty zbiorcze, a sp ustawia osobną politykę dla subdomen – jeśli go pominiesz, przyjmuje wartość p.
Dlaczego w 2024 roku stało się to obowiązkowe
Uwierzytelnianie było kiedyś opcjonalną higieną. W lutym 2024 stało się warunkiem wejścia. Gmail i Yahoo wymagają dziś od masowych nadawców – Google zalicza do nich każdego, kto wysyła ponad 5000 wiadomości dziennie na konta Gmail – uwierzytelniania przez SPF i DKIM oraz publikacji rekordu DMARC, który na początek może mieć p=none. Poczta marketingowa i subskrybowana musi też umożliwiać wypisanie się jednym kliknięciem: nagłówek List-Unsubscribe (RFC 2369) plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, czyli mechanizm jednego kliknięcia z RFC 8058, dzięki któremu klient pocztowy odbiorcy może wypisać go jednym żądaniem HTTPS POST. Pełne zasady Gmail i Yahoo znajdziesz w przeglądzie dostarczalności. Warto pamiętać o dwóch rzeczach: egzekwowanie zaostrzyło się od 2024 roku, więc stosuj się do zasad nawet poniżej 5000 wiadomości dziennie, a niski poziom skarg na spam jest wymogiem na równi z uwierzytelnianiem, a nie miłym dodatkiem.
Częste błędy, które po cichu psują uwierzytelnianie
- Publikowanie +all w rekordzie SPF, co upoważnia cały internet do wysyłania poczty jako Ty – dokładne przeciwieństwo celu.
- Więcej niż jeden rekord v=spf1 w tej samej domenie, co zwraca permerror i unieważnia SPF.
- Przekroczenie limitu dziesięciu zapytań DNS, gdy dodajesz kolejne include od dostawców, co również zwraca permerror.
- Za krótki albo nigdy nierotowany klucz DKIM, przez co klucz, który wyciekł lub został złamany siłowo, podpisuje wiadomości bez końca.
- Przejście od razu na p=reject bez przeczytania choćby jednego raportu zbiorczego, co blokuje legalną pocztę, o której wysyłaniu nie pamiętasz.
- Pominięcie sp= dla subdomen, przez co luźna polityka subdomen zostawia domenę marketing.yourco.com otwartą na podszywanie się.
- Zewnętrzny nadawca – ESP, narzędzie do faktur, helpdesk – którego nigdy nie doprowadzono do wyrównania SPF i DKIM, więc jego poczta nie przechodzi DMARC.
Miejsce uwierzytelniania w Twoim stosie narzędzi
Uwierzytelnianie to fundament, na którym stoi cała reszta. Jeśli hostujesz samodzielnie, w pełni kontrolujesz DNS i klucze podpisujące – to najmocniejsza wersja kontroli nad własną tożsamością nadawcy. Platforma customer engagement powinna pokazywać stan uwierzytelniania i wyrównania dla każdej domeny wysyłkowej zamiast go ukrywać, żeby od razu było widać, które źródła przechodzą. Kieruj pocztę transakcyjną i marketingową osobnymi strumieniami, najlepiej z osobnych subdomen, żeby wzrost skarg na marketing nigdy nie zagroził doręczaniu e-maili z resetem hasła. I zachowaj właściwą kolejność: uwierzytelnianie i wyrównanie są pierwsze, przed rozgrzewaniem domeny – rozgrzewanie nieuwierzytelnionej domeny tylko szybciej uczy dostawców, żeby Ci nie ufali.