Rotacja kluczy DKIM to planowa wymiana pary kluczy, która służy do podpisywania Twoich e-maili: publikujesz w DNS nowy klucz publiczny pod nowym selektorem, przełączasz podpisywanie na nowy klucz prywatny i wycofujesz z użycia starą parę.
Stowarzyszenie branżowe Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), które publikuje dobre praktyki dla operatorów systemów poczty e-mail, zaleca rotację kluczy DKIM co najmniej raz na sześć miesięcy na wypadek kradzieży klucza.
Ten poradnik jest przeznaczony dla zespołów, które zarządzają własnymi domenami lub domenami klientów i których poczta przechodzi już weryfikację DKIM. Znajdziesz w nim wszystko, co musisz wiedzieć o tym, jak przeprowadzać rotację kluczy DKIM, a także o tym, co może się stać, jeśli tego nie robisz.
Jeśli wciąż ustalasz, którymi kluczami podpisywana jest poczta z Twojej domeny, zacznij od naszego poradnika o wyszukiwaniu selektora DKIM; ten artykuł jest jego kontynuacją.
Jeśli atakujący przejmie Twój klucz, może wysyłać wiadomości, które przechodzą uwierzytelnianie jako wysłane z Twojej domeny. Klucz prywatny nigdy nie jest publikowany w DNS: przechowują go serwery pocztowe i platformy wysyłkowe, które podpisują Twoje wiadomości, a atakujący, który włamie się do jednego z tych systemów, może go skopiować.
Następnie atakujący podpisuje własną wiadomość Twoim kluczem prywatnym. Serwer pocztowy odbiorcy pobiera z DNS Twój klucz publiczny i potwierdza, że podpis jest prawidłowy.
Ponieważ domena podpisująca zgadza się z domeną w adresie nadawcy (w nagłówku From), wiadomość przechodzi też weryfikację DMARC, w której serwer odbiorcy porównuje uwierzytelnioną domenę z domeną w adresie From. Serwery odbiorców stosują Twoją politykę DMARC tylko do poczty, która nie przechodzi weryfikacji DMARC, dlatego nawet przy p=reject dostarczają wiadomość podpisaną Twoim własnym kluczem.
M3AAWG podaje to ryzyko jako powód regularnej rotacji: im krócej dana para kluczy jest w użyciu, tym krócej można wykorzystać przejęty klucz.
To, kto odpowiada za rotację, poznasz po dwóch rzeczach: po typie rekordu DNS opublikowanego dla każdego selektora oraz po tym, czy platforma, która podpisuje pocztę danym selektorem, sama przeprowadza rotację kluczy według własnego harmonogramu. Aby sprawdzić typ rekordu, otwórz ustawienia DNS swojej domeny (w Cloudflare, GoDaddy, u rejestratora domeny lub tam, gdzie zarządzasz DNS) i znajdź rekordy, których nazwy zaczynają się od Twojego selektora, po którym następuje ._domainkey. W kolumnie Type (Typ) przy każdym rekordzie zobaczysz TXT albo CNAME.
Jeśli Twoim DNS zarządza ktoś inny, sprawdź zamiast tego stronę konfiguracji DKIM na każdej platformie wysyłkowej: znajdziesz tam listę rekordów, o których dodanie poprosiła Cię platforma, czyli rekordy CNAME albo jeden rekord TXT z długą wartością klucza.
Rekord TXT zawiera sam klucz publiczny, więc przy każdym nowym kluczu musisz opublikować w swoim DNS nowy rekord TXT. Dlatego rotację przeprowadzasz Ty, nawet jeśli parę kluczy wygenerowała platforma, tak jak robi to Google Workspace.
Rekord CNAME pod nazwą selektora to alias, który wskazuje na rekord kontrolowany przez platformę. Platforma przechowuje klucz prywatny i może publikować w tym rekordzie każdy nowy klucz publiczny bez żadnych zmian w Twoim DNS.
Z typu rekordu dowiesz się, kto może wymienić klucz. Nie dowiesz się z niego natomiast, kiedy nastąpi wymiana: niektóre platformy przeprowadzają rotację według własnego harmonogramu, a inne czekają, aż ją rozpoczniesz. Tabela poniżej pokazuje, jak rotację obsługują cztery platformy wysyłkowe:
| Platforma wysyłkowa | Kto przechowuje klucz prywatny | Jak przebiega rotacja |
|---|---|---|
| Microsoft 365 | Microsoft; Twoje dwa rekordy CNAME (selector1, selector2), publikowane jednorazowo, wskazują na rekordy kluczy kontrolowane przez Microsoft | Rotację rozpoczynasz Ty, korzystając z opcji „Rotate DKIM keys” w portalu Defender albo z polecenia cmdlet Rotate-DkimSigningConfig w Exchange Online PowerShell. Microsoft podaje w swojej dokumentacji, że przełącza podpisywanie na nowy klucz cztery dni (96 godzin) po tym, jak rozpoczniesz rotację. |
| Google Workspace | Google; klucz publiczny publikujesz jako rekord TXT | Rotację przeprowadzasz ręcznie: w konsoli administracyjnej (Admin console) generujesz nowy rekord z nowym prefiksem selektora, dodajesz go jako nowy rekord TXT u dostawcy DNS swojej domeny, a następnie uruchamiasz uwierzytelnianie (Start authentication). |
| Salesforce (Sales Cloud) | Salesforce; Twoje rekordy CNAME wskazują na rekordy kluczy kontrolowane przez Salesforce | Rotacja jest automatyczna: Salesforce przeprowadza ją co 30 dni. |
| Amazon SES (Easy DKIM) | AWS; AWS generuje w ramach Easy DKIM parę kluczy (domyślnie 2048-bitową) i podpisuje nią Twoją pocztę | Nie musisz niczego planować. Klucz przechowuje AWS, a dokumentacja Easy DKIM nie opisuje żadnego kroku rotacji po stronie właściciela domeny. |
Samodzielnie przeprowadzasz rotację każdego klucza opublikowanego jako rekord TXT oraz każdego klucza na platformie, która czeka, aż rozpoczniesz rotację, tak jak Microsoft 365. W przypadku platformy wysyłkowej spoza tej tabeli sprawdź te same dwie rzeczy: typ rekordu pod jej selektorem oraz informację w dokumentacji dostawcy o tym, kto rozpoczyna rotację. Przypadek Salesforce, łącznie z konfiguracją każdego produktu Salesforce, omawiamy w naszym poradniku o DMARC dla e-maili wysyłanych przez Salesforce.
Jeśli zarządzasz DKIM dla domen klientów, według wytycznych M3AAWG prośba o rotację powinna pochodzić od właściciela domeny. Termin każdej rotacji uzgadniaj z klientem, a zmiany w DNS i w ustawieniach podpisywania wprowadzaj w uzgodnionym dniu.
W przypadku kluczy, których rotację przeprowadzasz samodzielnie, M3AAWG zaleca rotację co najmniej raz na sześć miesięcy. W dokumencie DKIM Key Rotation Best Common Practices członkowie M3AAWG porównali różne częstotliwości rotacji i wybrali sześć miesięcy jako kompromis między ryzykiem przejęcia klucza a nakładem pracy potrzebnym do jego wymiany. Dokument sugeruje stałe terminy poza okresami, w których sprzedajesz najwięcej, na przykład kwiecień i październik w przypadku sklepu internetowego.
Przeprowadź rotację przed zaplanowanym terminem w dwóch sytuacjach:
Przy każdej rotacji sprawdzaj długość klucza. Zgodnie z RFC 8301 do podpisywania należy używać kluczy RSA o długości co najmniej 1024 bitów, a zalecana długość to 2048 bitów, więc jeśli rekord DNS danego selektora nadal zawiera klucz 1024-bitowy, wygeneruj w jego miejsce klucz 2048-bitowy.
Stosując metodę dwóch selektorów z okresem przejściowym, wymieniasz klucz bez ani jednego błędu weryfikacji podpisu, ponieważ selektor w każdej wiadomości wskazuje na klucz publiczny, który nadal jest opublikowany w DNS. W okresie przejściowym oba klucze publiczne pozostają opublikowane, każdy pod własnym selektorem, a Ty w tym czasie przełączasz podpisywanie ze starego klucza prywatnego na nowy.
Kroki opisane poniżej dotyczą sytuacji, w której pocztę podpisuje Twój własny serwer pocztowy. Na platformie, która generuje parę kluczy za Ciebie, takiej jak Google Workspace, nowy klucz tworzysz i podpisywanie przełączasz w konsoli administracyjnej platformy, ale rekordy DNS nadal publikujesz, a później unieważniasz samodzielnie.
mail-202604, posortujesz selektory według daty wprowadzenia każdego klucza do użytku.mail-202604._domainkey.yourdomain.com, zwróci nowy klucz publiczny. Twój serwer pocztowy nie podpisuje jeszcze wiadomości nowym kluczem, więc w czasie oczekiwania nie może wystąpić żaden błąd weryfikacji podpisu.s= nowy selektor, a serwery odbiorców sprawdzają ich podpisy za pomocą nowego klucza publicznego.v=DKIM1; p= (z pustą wartością p=). RFC 6376 określa, że pusta wartość oznacza unieważniony klucz. M3AAWG zaleca pozostawienie tego rekordu w DNS zamiast jego usuwania, aby serwer odbiorcy, który wyszukuje stary selektor, znalazł klucz celowo wycofany z użycia, a nie natrafił na brakujący rekord.Microsoft 365 stosuje po swojej stronie tę samą metodę z okresem przejściowym: oba selektory pozostają opublikowane, a Microsoft przełącza podpisywanie na nowy klucz cztery dni (96 godzin) po tym, jak rozpoczniesz rotację.
Jeśli rekord DMARC Twojej domeny zawiera znacznik rua= (z adresem, na który mają trafiać raporty), serwery odbiorców wysyłają na ten adres raporty zbiorcze DMARC. Te raporty pokazują przebieg rotacji: wiadomości podpisane nowym selektorem zaczynają przechodzić weryfikację, a wiadomości podpisane starym selektorem przestają się pojawiać. M3AAWG zaleca audyt mniej więcej tydzień po każdej rotacji: porównaj selektor, który odnotowały serwery odbiorców, z selektorem, który zgodnie z harmonogramem miał być aktywny.
Jeśli wycofany selektor nadal pojawia się w Twoich raportach, oznacza to, że coś działa nieprawidłowo. Najpierw sprawdź dwie przyczyny: usługę, w której nikt nie przeprowadził rotacji i która nadal podpisuje pocztę starym kluczem, oraz klucz wymieniony tylko po jednej stronie. W drugim przypadku serwer pocztowy podpisuje wiadomości jednym kluczem, a rekord DNS zawiera inny, więc te wiadomości nie przechodzą weryfikacji DKIM na serwerach odbiorców.
DMARCeye analizuje te raporty za Ciebie i wyświetla listę selektorów, którymi podpisywana jest poczta w każdej z Twoich domen, dzięki czemu zauważysz selektor, który powinien już zniknąć z raportów. Bezpłatny plan obejmuje jedną domenę.
W przypadku platform, które używają typowych nazw selektorów, takich jak selector1 i selector2 w Microsoft 365, poniższe bezpłatne narzędzie do sprawdzania DKIM pokazuje klucz opublikowany pod każdym selektorem oraz siłę tego klucza. Dzięki niemu wykryjesz klucz 1024-bitowy, który należy zastąpić kluczem 2048-bitowym. Narzędzie nie sprawdza selektorów o niestandardowych nazwach, takich jak mail-202604.
Tak. M3AAWG zdecydowanie odradza ponowne używanie nazw selektorów: gdy rekord pod ponownie użytą nazwą zawiera już nowy klucz, każda wiadomość podpisana starym kluczem, łącznie z pocztą, która jest jeszcze w trakcie dostarczania, nie przechodzi weryfikacji DKIM na serwerach odbiorców. Z nazwy zawierającej datę rotacji, np. billing-202604, odczytasz też, kiedy każdy klucz został wprowadzony do użytku.
Nie, o ile w okresie przejściowym pozostawisz stary klucz opublikowany. Serwery odbiorców weryfikują podpis w chwili, gdy wiadomość do nich dociera, a stary klucz pozostawiasz opublikowany przez 7 do 30 dni po to, aby opóźniona poczta podpisana tym kluczem zdążyła dotrzeć i przejść weryfikację, zanim go unieważnisz. Po unieważnieniu klucza dostarczona już poczta pozostaje dostarczona, a niepowodzeniem kończy się tylko późniejsze, ponowne sprawdzenie podpisu starej wiadomości.
Według obecnych wersji roboczych DKIM2 rotację kluczy przeprowadza się tak samo. IETF pracuje nad DKIM2, planowaną przebudową standardu DKIM, a wersja robocza DKIM2 dotycząca DNS opisuje ten sam model kluczy: nadawcy publikują klucze publiczne w DNS pod selektorami i unieważniają klucz pustą wartością p=.
Rotacja kluczy DKIM to zadanie wykonywane według harmonogramu, a w Twoim harmonogramie muszą się znaleźć tylko klucze, których rotację przeprowadzasz samodzielnie. Przy takim harmonogramie przejęty klucz można wykorzystać tylko do następnej planowej rotacji, a nie do chwili, gdy ktoś zauważy incydent.
Pogrupuj swoje platformy wysyłkowe według typu rekordu pod każdym selektorem oraz według tego, czy dana platforma sama przeprowadza rotację kluczy zgodnie z własnym harmonogramem. Klucze, których rotację przeprowadzasz samodzielnie, wymieniaj dwa razy w roku według harmonogramu, a wcześniej, jeśli podejrzewasz przejęcie klucza albo gdy odchodzi ktoś, kto miał dostęp do Twoich kluczy do podpisywania. Każdą wymianę klucza przeprowadzaj metodą dwóch selektorów z okresem przejściowym, aby selektor w żadnej wiadomości nie wskazywał na klucz, którego nie ma w DNS.
Jeśli otrzymujesz raporty zbiorcze DMARC, na ich podstawie potwierdzisz każdą rotację: rotacja jest zakończona, gdy w zaplanowanym przez Ciebie terminie wiadomości podpisane nowym selektorem przechodzą weryfikację, a stary selektor przestaje się pojawiać. DMARCeye pokazuje, którymi selektorami podpisywana jest poczta w każdej z Twoich domen, dzięki czemu każdą rotację sprawdzisz w miarę napływu codziennych raportów.