SPF a DKIM: jaka jest różnica i czy potrzebujesz obu?

Wprowadzenie

Wiele błędów serwera SPF nie wynika z nieprawidłowej konfiguracji rekordu, lecz z faktu, że wiadomość została przekazana dalej.

Administrator IT poprawnie konfiguruje rekord SPF, sprawdza, czy weryfikacja przebiega pomyślnie, i uznaje zadanie za wykonane, po czym użytkownik przekazuje wiadomość za pośrednictwem serwera przekaźnikowego innej firmy. Serwer odbiorczy wykrywa adres IP, którego nie ma na liście autoryzowanych adresów, weryfikacja kończy się niepowodzeniem, administrator sprawdza rekord i stwierdza, że wszystko wygląda w porządku. Problemem nie jest sam rekord, ale sposób działania mechanizmu SPF.

Sam protokół SPF nie wystarcza do uwierzytelniania wiadomości e-mail, a protokoły SPF i DKIM nie służą temu samemu celowi. Każdy z tych protokołów chroni inną warstwę procesu dostarczania wiadomości e-mail. Usunięcie któregokolwiek z nich powoduje powstanie luk, które zarówno infrastruktura przekazująca wiadomości, jak i osoby atakujące mogą wykorzystać na różne sposoby i z różnych powodów.

W tym wpisie dowiesz się, czym różni się SPF od DKIM, dlaczego przekierowanie powoduje awarię jednego z nich, a drugiego nie, oraz dlaczego oba są niezbędne do prawidłowego działania DMARC.

Czym jest SPF i jak działa?

SPF (Sender Policy Framework) to protokół uwierzytelniania poczty elektronicznej, który pozwala właścicielowi domeny określić, które serwery pocztowe są uprawnione do wysyłania wiadomości e-mail w imieniu tej domeny.

Domena publikuje rekord SPF w swoim systemie DNS jako wpis TXT zawierający listę zatwierdzonych adresów IP i serwerów. Gdy serwer pocztowy odbierający wiadomość otrzymuje ją, porównuje domenę nadawcy z tym opublikowanym rekordem, aby potwierdzić, że serwer wysyłający jest autoryzowany. 

Na podstawie tego wyniku odbiorca decyduje, czy zaakceptować, oznaczyć czy odrzucić wiadomość. System SPF ma na celu uniemożliwienie spamerom i atakującym fałszowanie adresu nadawcy, co ogranicza spoofingu e-mailowego i phishingu. Działa w połączeniu z DKIM i DMARC w celu weryfikacji autentyczności wiadomości. 

Co sprawdza SPF

SPF sprawdza, czy serwer wysyłający wiadomość ma uprawnienia do wysyłania poczty w imieniu domeny, z której rzekomo pochodzi. Odbywa się to w momencie, gdy serwer odbiorczy akceptuje przychodzące połączenie, jeszcze zanim przetworzy treść wiadomości.

Jednak protokół SPF nie sprawdza adresu nadawcy, który faktycznie widzą odbiorcy. Sprawdza jedynie nadawcę koperty, zwanego również Return-Path lub MAIL FROM, czyli adres używany w tle podczas transakcji SMTP. 

W ten sposób osoba atakująca może przejść weryfikację SPF dla domeny koperty, a mimo to w skrzynce odbiorczej pojawi się sfałszowany adres nadawcy. DMARC pomaga wyeliminować tę lukę, łącząc wynik weryfikacji SPF z widoczną domeną nadawcy.

Serwer odbierający przyjmuje dwa dane wejściowe: 

1. Adres IP nadawcy
2. Domena nadawcy koperty

Następnie wyszukuje rekord SPF tej domeny w systemie DNS. Przechodzi kolejno przez poszczególne elementy rekordu, takie jak ip4, ip6, a, mxoraz include. Jeśli adres IP nadawcy pasuje do autoryzowanego źródła, test SPF kończy się powodzeniem. Jeśli test przebiega do zamykającego znacznika mechanizmu bez znalezienia dopasowania, wynik zależy od tego, jak skonfigurowano ten mechanizm.

SPF nie zwraca prostej odpowiedzi „tak” lub „nie”. Zwraca jeden z następujących wyników:

• Przejdź: Serwer został uwierzytelniony.
• Nieudane (-all): Brak uprawnień. Chcesz, aby ta wiadomość została odrzucona.
• SoftFail (~wszystkie): Prawdopodobnie brak uprawnień. Zaakceptuj, ale oznacz jako podejrzane.
• Neutralny (?wszystkie): Nie wyrażasz żadnego stanowiska w tej sprawie.
• Brak: Nie ma rekordu SPF dla tej domeny.
• Błąd stały / Błąd tymczasowy: Rekord jest uszkodzony lub problem z DNS zablokował wyszukiwanie.

Serwer odbiorczy traktuje ten wynik jako jeden z sygnałów, obok DKIM i DMARC, służących do ustalenia autentyczności wiadomości e-mail, zanim zostanie ona dostarczona, oznaczona jako podejrzana lub odrzucona. 

Czym jest DKIM i jak działa?

DKIM (DomainKeys Identified Mail) to protokół uwierzytelniania poczty elektronicznej, który dołącza podpis kryptograficzny do każdej wiadomości wysyłanej przez daną domenę. Serwer wysyłający podpisuje wiadomość kluczem prywatnym i umieszcza ten podpis w nagłówku wiadomości. Domena publikuje pasujący klucz publiczny w swoim systemie DNS jako rekord TXT. 

Gdy serwer odbiorczy otrzymuje wiadomość, pobiera ten klucz publiczny i weryfikuje podpis. Prawidłowy podpis potwierdza dwie rzeczy: 

1. Wiadomość rzeczywiście pochodziła z podanej domeny
2. Jego treść nie uległa zmianie podczas transportu. 

Protokół DKIM ma na celu zapobieganie manipulacjom i fałszowaniu tożsamości nadawcy; działa on w połączeniu z protokołami SPF i DMARC w celu weryfikacji autentyczności wiadomości. 

Co podpisuje DKIM

DKIM podpisuje dwie części każdej wiadomości: wybrany zestaw pól nagłówka oraz treść wiadomości. Nie podpisuje koperty, adresu IP serwera wysyłającego ani żadnych elementów spoza tych dwóch obszarów. Na tym polega różnica między tymi dwoma protokołami: SPF sprawdza kopertę i serwer wysyłający, podczas gdy DKIM podpisuje samą wiadomość.

Podpis nie jest nakładany na sam tekst wiadomości. Serwer wysyłający generuje skrót treści oraz wybranych nagłówków, a następnie szyfruje ten skrót swoim kluczem prywatnym. Wynik trafia do nagłówka DKIM-Signature, który serwer dodaje do wiadomości. Wewnątrz tego nagłówka kilka znaczników informuje odbiorcę dokładnie o tym, co zostało podpisane:

• h= wyświetla pola nagłówka zawarte w podpisie, takie jak Od, Do, Temat i Data.
• bh= zawiera skrót treści wiadomości.
• b= zawiera sam podpis, czyli zaszyfrowany skrót podpisanych nagłówków.
• c= ustawia kanonizację, która określa, jak ściśle muszą pasować spacje i formatowanie.

Nagłówek „From” jest zawsze podpisany. Wymaga tego protokół DKIM, ponieważ chodzi o powiązanie podpisu z domeną, którą faktycznie widzi odbiorca.

Wszystko, co nie zostało wymienione w atrybucie h=, nie jest chronione. Jeśli nagłówek nie znajduje się na tej liście, może zostać zmieniony podczas przesyłania bez naruszenia podpisu. Treść jest w całości objęta podpisem, chyba że opcjonalny atrybut l= ogranicza podpis do jej pierwszej części, dlatego też zazwyczaj odradza się stosowania atrybutu l=. Wszelkie treści dodane po podpisanej długości przejdą bez podpisu.

Gdy serwer odbierający sprawdza DKIM, ponownie oblicza skrót treści i skrót nagłówka, odszyfrowuje b= za pomocą opublikowanego klucza publicznego i porównuje te dwa wyniki. Jeśli oba wyniki są zgodne, podpis jest ważny, a podpisane fragmenty wiadomości dotarły w niezmienionej postaci.

SPF a DKIM

Protokół SPF i DKIM rozwiązują dwa różne problemy. SPF określa, które serwery mogą wysyłać wiadomości e-mail w imieniu Twojej domeny, natomiast DKIM, wykorzystując podpis kryptograficzny, potwierdza, że wiadomość nie została zmieniona i rzeczywiście pochodzi z Twojej domeny. Oto krótkie zestawienie różnic między protokołami SPF i DKIM.

Żadna ze stron nie wie, co wie druga.

Protokół SPF pozwala potwierdzić, że wiadomość pochodzi z autoryzowanego serwera, ale gdy wiadomość opuści serwer, SPF nie ma wglądu w to, co się z nią stało. 

Podobnie DKIM pozwala potwierdzić, że treść dotarła w nienaruszonym stanie oraz że domena podpisująca posiadała klucz prywatny, ale nie mówi nic o tym, czy serwer ten miał w ogóle uprawnienia do wysłania wiadomości.

Oto, co oznacza sytuacja, w której serwer odbierający analizuje oba wyniki:

DMARC analizuje oba wyniki i stosuje opublikowaną politykę w oparciu o zgodność z z . Dlatego te dwa protokoły zostały stworzone tak, by się wzajemnie uzupełniać, a nie konkurować.

Dlaczego SPF zawodzi przy przekazywaniu wiadomości, a DKIM nie?

Problem przekierowania SPF

SPF przestaje działać, gdy przekazywana jest wiadomość e-mail. Jest to jedna z najczęstszych przyczyn, dla których legalna wiadomość nie przechodzi weryfikacji SPF, a wynika to bezpośrednio ze sposobu działania protokołu.

SPF porównuje adres IP serwera łączącego się z rekordem SPF domeny nadawcy koperty. Przekierowanie powoduje naruszenie tej zgodności. Gdy serwer przekierowuje wiadomość, mają miejsce trzy rzeczy:

1. Serwer przekaźnikowy staje się nowym adresem IP, z którym nawiązywane jest połączenie.
2. Adres nadawcy na kopercie nadal wskazuje na domenę pierwotnego nadawcy.
3. W rekordzie SPF oryginalnej domeny nie podano serwera przekierowującego, więc wynik sprawdzenia to „Niepowodzenie”.

Na przykład wiadomość wysłana z Twojej domeny przechodzi pomyślnie weryfikację SPF na pierwszym etapie. Następnie serwer odbiorcy przekazuje ją dalej na drugi adres, np. konto absolwentów lub listę mailingową. W tym drugim miejscu adres IP, z którego nawiązano połączenie, to adres serwera przekazującego, ale w polu „Return-Path” nadal widnieje Twoja domena. Twój rekord SPF nigdy nie autoryzował tego serwera, więc weryfikacja SPF kończy się niepowodzeniem, mimo że wiadomość jest autentyczna.

Najczęściej pojawia się to w następujących przypadkach:

• Listy mailingowe
• Reguły automatycznego przekierowywania na poziomie konta w Gmailu lub Outlooku
• Adresy przekazujące dla absolwentów lub oparte na rolach
• Filtry antyspamowe i bramy przekazujące wiadomości dalej

Dwie rzeczy sprawiają, że przekazywana poczta nie jest odrzucana:

1. SRS (Sender Rewriting Scheme): Serwer przekazujący przepisuje pole Return-Path na swoją własną domenę przed przekazaniem wiadomości. Następnie SPF sprawdza domenę serwera przekazującego, która autoryzuje ten serwer, więc kontrola kończy się powodzeniem. Większość renomowanych usług przekazywania stosuje SRS automatycznie.
2. DKIM i DMARC: Podpis DKIM zachowuje ważność po przekazaniu wiadomości, o ile osoba przekazująca nie zmieni podpisanej treści. Tak więc nawet jeśli SPF nie przejdzie testu w przypadku przekazanej wiadomości, DKIM nadal może przejść, a DMARC wymaga zgodności tylko jednego z tych dwóch. To główny powód, dla którego nie należy polegać wyłącznie na SPF.

Dlaczego DKIM działa nawet przy przekazywaniu wiadomości

Algorytm DKIM zachowuje swoją skuteczność podczas przekazywania wiadomości, ponieważ podpisuje samą wiadomość, a nie ścieżkę, którą ona pokonuje. Podpis znajduje się w nagłówku DKIM-Signature, więc przemieszcza się wraz z wiadomością e-mail na każdym etapie przesyłania. Niezależnie od tego, przez ile serwerów przechodzi wiadomość, podpis pozostaje nienaruszony, gdy dotrze ona do miejsca docelowego.

Weryfikacja nie zależy również od serwera, z którego nawiązano połączenie. Odbiorca pobiera klucz publiczny domeny podpisującej z serwera DNS tej domeny i wykorzystuje go do sprawdzenia podpisu. Adres IP, z którego dostarczono wiadomość, nie ma znaczenia. Jest to przeciwieństwo mechanizmu SPF, który nie działa w przypadku przekazywania wiadomości właśnie dlatego, że sprawdza adres IP, z którego nawiązano połączenie, a przekazywanie powoduje zmianę tego adresu.

O ile serwer przekaźnikowy przekazuje wiadomość bez zmiany podpisanej treści, skróty treści i nagłówka nadal się zgadzają, a weryfikacja DKIM przebiega pomyślnie.

DKIM zachowuje ważność przy zwykłym przekazywaniu wiadomości, ale nie jest odporny na wszystko. Podpis traci ważność, gdy pośrednik modyfikuje podpisane treści. Najczęstszymi sprawcami są listy mailingowe, które często:

• Dodaj stopkę lub link do rezygnacji z subskrypcji w treści wiadomości
• Dodaj w temacie wiadomości tag w formacie [nazwa-listy]
• Przepisz lub wstaw nagłówki znajdujące się w treści podpisu

Każda z tych zmian powoduje zmianę skrótu, a podpis przestaje być poprawny. ARC (Authenticated Received Chain) został stworzony właśnie na taką ewentualność, zachowując oryginalne wyniki uwierzytelnienia, gdy wiadomość przechodzi przez pośredników, którzy ją modyfikują.

Właśnie dlatego DKIM ma znaczenie w przypadku wiadomości przekazywanych w ramach DMARC. Test DMARC kończy się powodzeniem, gdy test SPF lub DKIM zakończy się powodzeniem i wyniki są zgodne z domeną „From”. W przypadku przekazywanych wiadomości test SPF zazwyczaj kończy się niepowodzeniem, więc to DKIM decyduje o wyniku spójność DMARC . Domena podpisująca pozostaje ta sama podczas przekazywania, więc zgodność pozostaje zachowana. Poleganie wyłącznie na SPF i wiadomościach przekazywanych z Twojej domeny może spowodować niepowodzenie weryfikacji DMARC i trafienie do spamu.

Jak współdziałają protokoły SPF, DKIM i DMARC?

SPF i DKIM rozwiązują różne problemy, ale żadna z tych metod nie zapewnia sama w sobie skutecznej ochrony. DMARC łączy wyniki tych sprawdzianów z konkretnym działaniem i wiąże oba sprawdziany z domeną, którą faktycznie widzą odbiorcy.

Oto, co się dzieje, gdy serwer odbiorczy analizuje przychodzącą wiadomość:

1. Najpierw uruchamia się SPF: Serwer odczytuje nadawcę koperty, czyli adres MAIL FROM , a nie nagłówek „From”, który widzi odbiorca, i porównuje adres IP nadawcy z Twoim rekordem SPF. Jeśli adres IP jest autoryzowany, SPF przechodzi pomyślnie. Jeśli nie, następuje błąd.
2. Następnie uruchamia się DKIM: Serwer odczytuje nagłówek DKIM-Signature , wyszukuje klucz publiczny w DNS przy użyciu selektora i tagów domeny, a następnie weryfikuje podpis kryptograficzny względem treści wiadomości. Prawidłowy podpis potwierdza, że wiadomość pochodzi z domeny kontrolującej klucz prywatny i nie została zmieniona podczas przesyłania.
3. DMARC jest sprawdzany jako ostatni: Pobiera dane Twojej polisy i sprawdza zgodność:
   1. Czy domena, która przeszła weryfikację SPF, zgadza się z domeną nadawcy? 
   2. Czy tag d= w podpisie DKIM pasuje do Twojej domeny „From”? 

Jeśli którekolwiek z nich jest zgodne, test DMARC kończy się powodzeniem. To, co stanie się z wiadomością, zależy wówczas od opublikowanej polityki.

Co w praktyce oznacza wyrównanie

SPF dopuszcza każdą domenę podaną w polu nadawcy koperty. DKIM dopuszcza każdą domenę posiadającą prawidłowy klucz podpisujący. Żadna z tych weryfikacji nie potwierdza samodzielnie poprawności nagłówka „From”, czyli pola zawierającego [email protected] w skrzynce odbiorczej adresata, jest prawidłowy. DMARC uzupełnia tę weryfikację, porównując uwierzytelnioną domenę z domeną „From”.

Funkcja wyrównywania działa w dwóch trybach:

1. W trybie swobodnym, który jest trybem domyślnym, wystarczy dopasowanie domeny organizacyjnej, gdzie mail.twojafirma.com pokrywa się z twojafirma.com. 
2. W trybie ścisłym nazwy domen muszą być identyczne. Większość organizacji stosuje tryb elastyczny, ponieważ tryb ścisły powoduje problemy z dostarczaniem wiadomości w przypadku subdomen, o ile każde źródło wysyłające nie jest precyzyjnie skonfigurowane.

Wyniki porównania wiadomości autentycznych i sfałszowanych

W przypadku prawidłowo skonfigurowanej, autentycznej wiadomości:

• Adres IP nadawcy jest zgodny z rekordem SPF → Test SPF zakończył się powodzeniem
• Podpis DKIM jest poprawny, d= pasuje do Twojej domeny „Od” → DKIM przeszedł pomyślnie
• Oba wyniki są zgodne z Twoją domeną nadawczą → DMARC: pozytywny wynik
• Twoje p=odrzuc → wiadomość została dostarczona

W przypadku sfałszowanej wiadomości wysłanej z nieautoryzowanego serwera bez ważnego klucza podpisu:

• Nieautoryzowany adres IP → Błąd SPF
• Brak prawidłowego podpisu → Błąd DKIM
• Żaden z tych wyników nie zgadza się z Twoją domeną nadawcy → błąd DMARC
• Twoje p=odrzuc → wiadomość jest odrzucana, zanim dotrze do jakiejkolwiek skrzynki odbiorczej

Właśnie dlatego połączenie SPF i DKIM w ramach protokołu DMARC jest skuteczniejsze niż stosowanie każdego z nich osobno. DMARC może zaakceptować wynik zgodności obu metod, więc gdy weryfikacja SPF nie powiedzie się w przypadku wiadomości przekazanych dalej, zgodność DKIM pozwala na pozytywny wynik DMARC dla wiadomości autentycznych. Gdy obie metody zawiodą w przypadku wiadomości sfałszowanych, DMARC działa zgodnie z ustaloną polityką.

Gdy Twoja domena osiągnie p=kwarantanna lub p=reject , a zarówno SPF, jak i DKIM są zgodne i zsynchronizowane, spełniłeś również warunek wstępny dla BIMI, standardu wyświetlającego zweryfikowane logo marki w obsługujących go skrzynkach odbiorczych, takich jak Gmail i Apple Mail.

Czy potrzebujesz zarówno SPF, jak i DKIM?

Tak, potrzebujesz zarówno SPF, jak i DKIM. 

Domena korzystająca z SPF bez DKIM nie posiada weryfikacji integralności na poziomie wiadomości. Nie ma możliwości potwierdzenia, że treść nie została zmieniona podczas przesyłania. Brak zgodności z DKIM uniemożliwia stosowanie DMARC, co oznacza, że jeśli SPF zawiedzie (a tak się stanie w przypadku każdej przekazanej wiadomości e-mail), DMARC nie ma rozwiązania awaryjnego. Wystarczy jedna reguła przekazywania między służbową skrzynką odbiorczą użytkownika a jego kontem prywatnym, a uwierzytelnianie zawodzi w przypadku wiadomości, która była całkowicie prawidłowa.

W lutym 2024 r. firmy Google i Yahoo wprowadziły obowiązek stosowania obu tych rozwiązań.

Google wymaga rekordów SPF, DKIM i DMARC od wszystkich nadawców masowych wysyłających co najmniej 5 000 wiadomości dziennie. Yahoo wymaga co najmniej jednego z rekordów SPF lub DKIM oraz DMARC, choć wdrożenie tylko jednego z nich oznacza jednoczesne niespełnienie wymagań Google. Jeśli wysyłasz wiadomości do odbiorców na obu platformach, skonfigurowanie obu rozwiązań jest jedynym sposobem na spełnienie wszystkich wymagań jednocześnie.

Nawet poniżej progu 5000 wiadomości wymagania te stały się de facto standardem dostarczalności wśród głównych dostawców usług poczty elektronicznej. 

Czego dotyczy jedna z nich, a drugiej nie:

Zgodnie z zaleceniami RFC 7208 system SPF z założenia nie rozpoznaje wiadomości przekazanych dalej. Adres IP serwera przekazującego zastępuje adres pierwotny, a ponieważ ten adres nie znajduje się na liście autoryzowanych adresów, weryfikacja kończy się niepowodzeniem, mimo że wszystko przebiegło prawidłowo. System DKIM nie uwzględnia zmian adresu IP. Podpis towarzyszy wiadomości i jest weryfikowany niezależnie od tego, przez jakie serwery przeszła wiadomość, o ile jej treść nie została zmodyfikowana.

DKIM potwierdza, że wiadomość jest nienaruszona i że domena podpisująca posiadała kontrolę nad kluczem prywatnym, ale nie mówi nic o tym, czy serwer, który ją wysłał, posiadał uprawnienia na poziomie sieci, by to zrobić. Tę kontrolę zapewnia SPF.

Żadna ze stron nie wie, co wie druga. Korzystanie z obu protokołów oznacza, że serwer odbierający, który analizuje wiadomość, ma pełny obraz sytuacji, w tym autoryzowaną ścieżkę i nienaruszoną treść, a nie tylko jej część.

Jak skonfigurować SPF i DKIM: przewodnik krok po kroku

Jeśli w Twojej domenie nie skonfigurowano jeszcze protokołów SPF i DKIM, proces konfiguracji jest bardzo prosty. Poniższe kroki opisują, co należy zrobić, aby skonfigurować i zweryfikować oba protokoły. 

Krok 1: Utwórz rekord SPF

Zacznij od sporządzenia listy wszystkich usług uprawnionych do wysyłania wiadomości e-mail z Twojej domeny, takich jak:

1. Twój główny serwer pocztowy
2. Platforma marketingowa
3. CRM
4. Narzędzie pomocy technicznej
5. Dostawca usług poczty elektronicznej służącej do obsługi transakcji oraz wszelkie inne podmioty wysyłające wiadomości w Twoim imieniu.

Każda autoryzowana usługa otrzymuje include: mechanizm w rekordzie SPF lub bezpośredni zakres adresów IP przy użyciu ip4: lub ip6:. Zamknij rekord za pomocą -all , aby poinformować serwery odbierające, że każdy adres IP nieznajdujący się na liście jest nieautoryzowany.

Przed dodaniem zakresów adresów IP bezpośrednio za pomocą ip4: lub ip6:, upewnij się, że zakresy należą do właściwej usługi wysyłającej. Funkcja wyszukiwania adresów IP WHOIS w PowerDMARC pozwala zweryfikować właściciela adresu IP, zanim trafi on do Twojego rejestru. 

Podstawowy rekord SPF wygląda następująco:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Zwracaj uwagę na liczbę zapytań DNS podczas dodawania usług. Standard RFC 7208 ogranicza liczbę zapytań podczas oceny SPF do 10. Każda mechanizm include: mechanizm „include” zużywa co najmniej jedno wyszukiwanie, a zagnieżdżone wywołania „include” wliczają się do tego samego limitu. Większość domen osiąga ten limit szybciej niż się spodziewano, gdy obsługują jednocześnie cztery lub pięć zewnętrznych nadawców.

Skorzystaj z bezpłatnego generatora SPF , aby utworzyć swój rekord bez ręcznego wpisywania składni, oraz PowerSPF , aby automatycznie utrzymywać liczbę wyszukiwań poniżej limitu 10, w miarę zmian w Twojej infrastrukturze wysyłkowej.

Krok 2: Wygeneruj i opublikuj swoje klucze DKIM

Dla każdej usługi wysyłającej wiadomości w Twoim imieniu potrzebujesz pary kluczy DKIM: 

1. Klucz prywatny, którego serwer wysyłający używa do podpisywania wychodzących wiadomości
2. Odpowiedni klucz publiczny opublikowany w Twoim systemie DNS, służący do weryfikacji przez serwery odbiorcze.

Jeśli usługa taka jak Google Workspace lub Microsoft 365 obsługuje podpisywanie DKIM, udostępnia ona rekord klucza publicznego oraz nazwę selektora. Opublikuj ten rekord w systemie DNS pod adresem selector._domainkey.twojadomena.com i włącz podpisywanie w konsoli administracyjnej usługi.

W środowiskach, w których klucze generuje się samodzielnie, należy stosować co najmniej 2048-bitowy algorytm RSA; 1024-bitowy nie jest już uznawany za wystarczający. Bezpłatny generator DKIM generuje gotowy do publikacji rekord DNS bez konieczności korzystania z narzędzi wiersza poleceń.

Jeśli zarządzasz DKIM w wielu usługach wysyłkowych, Hosted DKIM zajmuje się generowaniem kluczy, publikowaniem w DNS i rotacją z jednego miejsca, bez konieczności ręcznej edycji DNS za każdym razem, gdy klucz wymaga zmiany.

Krok 3: Dodaj rekord DMARC

Po skonfigurowaniu SPF i DKIM dodaj rekord DMARC do swojej strefy DNS. Zacznij od p=none , aby gromadzić zbiorcze dane raportowe bez wpływu na dostarczanie poczty.

Podstawowy zapis początkowy:

v=DMARC1; p=none; rua=mailto:[email protected];

p=none nie blokuje sfałszowanych wiadomości. Przełącza DMARC w tryb monitorowania, dzięki czemu otrzymujesz zbiorcze raporty pokazujące, które źródła przechodzą, a które nie przechodzą uwierzytelnienia, ale żadna poczta nie jest poddawana kwarantannie ani odrzucana. 

Wykorzystaj te dane do wykrycia błędów konfiguracji i problemów z dostosowaniem, a następnie przejdź do p=kwarantanny i w końcu p=odrzuc.

Domena znajdująca się pod adresem p=none nie jest chroniona przed spoofingiem. Faza monitorowania wymaga zdefiniowanego punktu końcowego, a nie otwartej osi czasu.

Krok 4: Sprawdź swoją konfigurację

Po opublikowaniu wpisów upewnij się, że każdy z nich działa poprawnie, zanim uznasz konfigurację za zakończoną.

Chociaż poprawne rozpoznawanie rekordów jest konieczne, samo w sobie nie wystarcza. Wyślij test na żywo, aby sprawdzić, czy nagłówki uwierzytelniające przechodzą przez cały łańcuch komunikacyjny. Narzędzie do testowania SMTP firmy PowerDMARC pozwala przetestować połączenie z serwerem pocztowym i zweryfikować SPF, DKIM i DMARC przechodzą w rzeczywistej poczcie wychodzącej, a nie tylko w DNS. 

Typowe błędy

Dwa najczęstsze błędy powodujące niepowodzenia uwierzytelniania w środowisku produkcyjnym to: 

Limit wyszukiwania SPF 10

Protokół SPF dopuszcza maksymalnie 10 zapytań DNS gdy serwer odbierający ocenia twój rekord — jest to limit określony w RFC 7208. Mechanizmy takie jak include, a i mx wywołują po jednym wyszukiwaniu i mogą być zagnieżdżane. 

Większość domen przekracza limit 10, dodając nadawców zewnętrznych, ponieważ każda usługa, którą autoryzujesz za pomocą polecenia „include”, zużywa operacje sprawdzania. Po przekroczeniu limitu SPF zwraca błąd PermError, a serwery odbiorcze traktują to jako błąd, który uniemożliwia autoryzację Twojej poczty. 

Spłaszczanie rozwiązuje ten problem poprzez zastąpienie mechanizmów dołączania rzeczywistymi zakresami adresów IPv4 i IPv6, do których są one rozdzielane, co powoduje spadek liczby wyszukiwań do zera.

Rotacja kluczy DKIM

Rotacja kluczy DKIM polega na cyklicznej wymianie pary kluczy DKIM, polegającej na wycofaniu starego klucza prywatnego służącego do podpisywania oraz opublikowaniu w jego miejsce nowego klucza publicznego. Rotacja ogranicza czas, przez jaki dany klucz pozostaje dostępny, dzięki czemu w razie jego naruszenia szkody są minimalne. Większość zespołów przeprowadza rotację co kwartał lub dwa razy w roku, a niektórzy dostawcy dokonują rotacji swoich kluczy automatycznie.

Większość awarii rotacji wynika z błędów popełnianych podczas wymiany. Oto, co administratorzy najczęściej przeoczają.

Zbyt wczesne usunięcie starego klucza publicznego

Wiadomości znajdujące się już w drodze zostały podpisane starym kluczem, a odbiorca potrzebuje pasującego klucza publicznego w DNS, aby je zweryfikować. Usuń stary wpis natychmiast po zmianie, a wiadomości znajdujące się w drodze nie przejdą weryfikacji DKIM. Pozostaw stary klucz opublikowany przez okres przejściowy, aż wszystkie wiadomości podpisane tym kluczem zostaną dostarczone.

Ponowne użycie tego samego selektora

Zmieniaj selektory, nie nadpisuj ich. Opublikuj nowy klucz pod nowym selektorze, przenieś do niego podpisywanie, a następnie wycofaj stary selektor po okresie nakładania się. Nadpisanie rekordu pojedynczego selektora tworzy lukę, w której poczta podpisana starym kluczem nie będzie już mogła przejść walidacji.

Przełączenie przed zakończeniem propagacji DNS

Jeśli podpiszesz się nowym kluczem, zanim nowy klucz publiczny nie zostanie rozpowszechniony, odbiorcy nie będą mogli go znaleźć i DKIM zakończy się niepowodzeniem. Najpierw opublikuj nowy rekord, poczekaj na upływ czasu TTL rekordu, a następnie przenieś podpisywanie.

Pomijanie nadawców zewnętrznych

Każda usługa wysyłkowa, np. dostawca usług e-mailowych (ESP) lub system CRM, zarządza własnymi kluczami i selektorami DKIM. Zmiana klucza dla domeny głównej nie ma na nie wpływu. Należy zmienić klucz dla każdej usługi osobno lub upewnić się, że dostawca zajmuje się tym za Ciebie.

Nieprawidłowe dzielenie rekordu 2048-bitowego

Klucz publiczny o długości 2048 bitów – będący obecnie standardem i wartym wdrożenia, jeśli nadal korzystasz z klucza 1024-bitowego – często przekracza limit 255 znaków dla pojedynczego ciągu znaków w rekordzie DNS TXT i musi zostać podzielony na kilka ciągów ujętych w cudzysłowy. Nieprawidłowy podział powoduje uszkodzenie rekordu, przez co klucz nie zostanie zweryfikowany, mimo że wydaje się, że jest obecny.

Praca w trybie obrotowym bez monitorowania

Raporty zbiorcze DMARC pozwalają sprawdzić, czy nowy klucz jest poprawny. Bez nich nieprawidłowa rotacja klucza objawia się spadkiem skuteczności dostarczania wiadomości, a nie wyświetleniem ostrzeżenia. Sprawdzaj raporty po każdej rotacji.

Obie awarie wynikają z tego, że rekordy zmieniają się szybciej, niż można je aktualizować ręcznie. PowerDMARC utrzymuje Twój rekord SPF w stanie spłaszczonym poniżej limitu 10 wyszukiwań, a klucze DKIM są regularnie rotowane, a następnie powiadamia Cię w momencie wystąpienia jakiejkolwiek awarii, zanim wpłynie to negatywnie na dostarczalność.

Rozpocznij bezpłatny okres próbny , aby sprawdzić, jak wygląda obecnie sytuacja Twojej domeny.

Najczęściej zadawane pytania

Czy DKIM zastępuje SPF?

Nie. DKIM weryfikuje integralność wiadomości za pomocą podpisu kryptograficznego, ale nie potwierdza, czy serwer wysyłający był autoryzowany. Tą kontrolę zapewnia SPF, więc do zapewnienia pełnej ochrony potrzebne są oba mechanizmy. 

Dlaczego po przekazaniu wiadomość e-mail nie przechodzi testu SPF?

Protokół SPF porównuje adres IP serwera wysyłającego z listą autoryzowanych adresów, a podczas przekazywania wiadomości oryginalny adres IP zostaje zastąpiony adresem serwera przekazującego, który nie figuruje w tej liście. Jest to zachowanie zgodne z normą RFC 7208, a protokół DKIM został zaprojektowany tak, by sobie z tym poradzić, ponieważ weryfikuje on treść wiadomości, a nie jej ścieżkę. 

Co jest ważniejsze: SPF czy DKIM?

Żadne z powyższych. SPF przeprowadza uwierzytelnianie na poziomie serwera, DKIM weryfikuje na poziomie wiadomości, a oba są niezbędne do niezawodnego dostosowania do standardu DMARC. Posiadanie obu tych mechanizmów pozwala na dostarczenie wiadomości nawet w przypadku niepowodzenia jednego z nich podczas przekazywania. 

Ile selektorów DKIM mogę mieć?

Nie ma żadnych ograniczeń. Możesz opublikować tyle wpisów, ile potrzebujesz – zazwyczaj jeden na każdą usługę wysyłkową lub cykl rotacji klucza. Każdy z nich istnieje jako oddzielny wpis TXT w systemie DNS pod adresem selector._domainkey.twojadomena.com. 

Co się stanie, jeśli mam tylko SPF, ale nie mam DKIM?

Tracisz integralność na poziomie wiadomości i nie masz rezerwowego rozwiązania w przypadku braku zgodności DKIM, więc DMARC może nie przejść pomyślnie w przypadku legalnych wiadomości przekazanych dalej, gdy zawiedzie SPF. Zasady Google dotyczące nadawców masowych również wymagają stosowania DKIM, co sprawia, że nadawcy wysyłający duże ilości wiadomości nie spełniają wymogów zgodności.