Trzy mechanizmy uwierzytelniania poczty są opisane w setkach poradników, a mimo to typowe wdrożenie wygląda tak: administrator publikuje rekord SPF z twardym odrzuceniem, włącza DMARC z polityką odrzucania i następnego dnia dowiaduje się, że system fakturowania, narzędzie do newsletterów i drukarka wysyłająca skany przestały docierać do odbiorców. Problem nie leży w mechanizmach, lecz w kolejności.
Co robi każdy z mechanizmów
SPF publikuje w DNS listę adresów, które mogą wysyłać pocztę w imieniu domeny. Odbiorca sprawdza adres serwera, który się z nim łączy.
DKIM podpisuje wiadomość kluczem prywatnym serwera wysyłającego; klucz publiczny jest w DNS. Odbiorca weryfikuje, że treść nie została zmieniona i pochodzi od uprawnionego systemu. Podpis przeżywa przekazywanie wiadomości, którego SPF nie przeżywa.
DMARC łączy oba: wymaga, by domena z adresu nadawcy widocznego dla użytkownika była zgodna z domeną, która przeszła SPF lub DKIM, i mówi odbiorcy, co zrobić, gdy nie jest: nic, kwarantanna lub odrzucenie. Dodatkowo prosi o raporty, kto wysyła pocztę w imieniu domeny.
Krok 1: raporty zanim cokolwiek zaostrzysz
Pierwszy rekord DMARC ma politykę none i adres do raportów zbiorczych. Nie zmienia nic w dostarczaniu, ale przez kilka tygodni zbiera informację, z jakich adresów wychodzi poczta z domeną w polu nadawcy. Lista zawsze zaskakuje: system kadrowy, aplikacja alarmowa, dostawca ankiet, skaner w recepcji, partner wysyłający w imieniu firmy. Bez tej listy każda polityka jest zgadywaniem.
Cztery do sześciu tygodni raportów to minimum, żeby złapać wysyłki miesięczne.
Krok 2: SPF z pełną listą
Rekord SPF zawiera wszystkie źródła z raportów: własne serwery, usługę pocztową w chmurze, dostawców wysyłających w imieniu domeny. Dwa ograniczenia techniczne:
- limit dziesięciu odwołań DNS w całym rekordzie, łącznie z zagnieżdżonymi; przekroczenie oznacza błąd trwały i odrzucenie przez część odbiorców,
- jeden rekord SPF na domenę; dwa rekordy to błąd.
Rekord kończy się początkowo ~all (miękkie niepowodzenie). Twarde -all przychodzi na końcu, gdy raporty DMARC nie pokazują już legalnych źródeł poza listą.
Krok 3: DKIM dla każdego źródła
Każdy system wysyłający pocztę podpisuje ją własnym kluczem z własnym selektorem. Usługa pocztowa w chmurze ma swój, narzędzie do newsletterów swój, własny przekaźnik swój. Klucze o długości co najmniej 2048 bitów, rotowane według harmonogramu dostawcy. Poddomeny używane przez dostawców zewnętrznych są skonfigurowane tak, by podpis był zgodny z domeną główną, inaczej DMARC ich nie uzna.
Po włączeniu DKIM raporty pokazują, które źródła podpisują, a które nie. Źródła, które nie potrafią podpisywać, są kandydatami do przeniesienia przez własny przekaźnik.
Krok 4: DMARC stopniowo
Gdy raporty pokazują, że cała legalna poczta przechodzi SPF lub DKIM ze zgodnością domen, polityka zmienia się na quarantine z parametrem pct=10: dziesięć procent niezgodnej poczty trafia do spamu odbiorcy. Po tygodniu bez zgłoszeń pct rośnie do 50, potem do 100. Następnie reject, znów przez pct. Na każdym etapie raporty są przeglądane, a zgłoszenia od użytkowników o niedostarczonej poczcie sprawdzane pod kątem niezgodności.
Osobna decyzja dotyczy poddomen: polityka dla poddomen może być ostrzejsza od głównej, bo poddomeny, które nie wysyłają poczty, mogą od razu mieć reject.
Krok 5: SPF na twardo i monitoring stały
Po osiągnięciu reject rekord SPF zmienia zakończenie na -all. Raporty DMARC nadal są zbierane i przeglądane co miesiąc: nowy dostawca dodany przez dział marketingu bez wiedzy IT pojawi się w raportach zanim zadzwonią klienci.
Podsumowanie
Kolejność: raporty DMARC z polityką none, potem SPF z pełną listą i miękkim zakończeniem, potem DKIM dla każdego źródła, potem zaostrzanie DMARC procentami, na końcu twardy SPF. Każdy krok jest weryfikowany raportami, a nie założeniem. Wdrożenie trwa dwa do trzech miesięcy i przez ten czas żadna legalna wiadomość nie ginie. Wdrożenie jednodniowe trwa jeden dzień i kilka tygodni naprawiania.