Rotacja kluczy DKIM: kiedy i jak zmieniać selektory
Rotacja kluczy DKIM sprowadza się do trzech ruchów: publikujesz nowy klucz publiczny pod nowym selektorem, przełączasz na niego podpisywanie, a stary rekord usuwasz dopiero wtedy, gdy poczta będąca już w drodze została zweryfikowana. Kiedy warto się tym zająć? Gdy obecny klucz ma 1024 bity, a dostawca DNS przyjmuje dłuższe. Gdy klucz prywatny mógł zostać ujawniony. Albo gdy cała konfiguracja powstała w pośpiechu, na ustawieniach domyślnych. Ten ostatni przypadek zdarza się częściej, niż ludzie przyznają: od lutego 2024 Gmail wymaga uwierzytelniania od wszystkich nadawców, a od nadawców masowych także DKIM i DMARC, więc wiele domen dostało swoje rekordy na szybko.
Czym jest selektor DKIM i dlaczego umożliwia rotację?
Selektor to po prostu etykieta. Znajduje się w podpisie wiadomości i mówi serwerowi odbierającemu, w którym rekordzie DNS leży klucz publiczny. Jak wyjaśnia instrukcja konfiguracji DKIM w Google Workspace, klucz publiczny znajduje się w rekordzie TXT Twojej domeny, a prywatny zostaje na serwerze pocztowym i podpisuje każdą wychodzącą wiadomość. Nazwa rekordu ma postać selektor._domainkey.twojadomena.com, a tę samą etykietę znajdziesz w tagu s= nagłówka DKIM-Signature.
I tu zaczyna się to, co przydatne: na jednej domenie może współistnieć kilka selektorów. Właśnie dzięki temu stary i nowy klucz mogą być ważne jednocześnie. Domyślny prefiks Google to google, a inny wpisujesz wtedy, gdy ta nazwa jest już zajęta.
Kiedy rotować klucze DKIM?
Krótka odpowiedź: gdy klucz jest krótki, gdy klucz prywatny mógł wyciec, gdy zmienia się dostawca albo pracownik z dostępem, a poza tym według harmonogramu, którego faktycznie da się trzymać. Jak często więc rotować klucze DKIM? Szczerze mówiąc, nie ma jednego odstępu, który pasuje każdemu zespołowi. Wybierz rytm dopasowany do swoich możliwości i go zapisz (harmonogram, którego nikt nie przestrzega, jest gorszy niż żaden). Typowe powody:
- klucz 1024-bitowy nadal w użyciu,
- klucz prywatny przechowywany lub udostępniany w niebezpieczny sposób,
- przejście na inną platformę wysyłkową,
- selektory pozostałe po narzędziach, z których już nie korzystasz,
- obecny klucz, którego wieku nikt nie zna.
Regularna rutyna daje jeszcze jedną korzyść. Procedura pozostaje przećwiczona, więc awaryjna zmiana nigdy nie jest Twoim pierwszym podejściem. A jeśli pierwotna konfiguracja powstawała pod presją terminu, wróć do podstaw, czyli do tego, jak wygląda uwierzytelnianie domeny wysyłkowej, zanim ruszysz klucze.
Czy Twój klucz jest wystarczająco długi? Przejście z 1024-bitowego na 2048-bitowy klucz DKIM
Wybieraj 2048-bitowy klucz DKIM zawsze, gdy dostawca Twojej domeny go obsługuje. Przy 1024 bitach zostań tylko wtedy, gdy dostawca DNS nie potrafi zapisać dłuższej wartości. Dłuższe klucze są bezpieczniejsze od krótszych, po prostu, a domena, która już podpisuje słabszą wersją, może się przełączyć.
Nie wiesz, co masz? Sprawdź rekord TXT aktywnego selektora i porównaj długość wartości p= albo odczytaj to ustawienie w swojej platformie wysyłkowej. Jedna praktyczna przeszkoda: w zależności od panelu DNS długą wartość trzeba czasem podzielić na kilka ciągów w cudzysłowach w ramach jednego rekordu TXT. Moja rada: potraktuj tę zmianę jak rotację z nowym selektorem. Nie nadpisuj istniejącego wpisu.
Jak przeprowadzić rotację kluczy DKIM krok po kroku
Całość jednym tchem: generujesz nową parę kluczy pod nowym selektorem, publikujesz część publiczną, czekasz na DNS, przełączasz podpisywanie, weryfikujesz, wycofujesz stary rekord. Teraz szczegółowo:
- Spisz wszystkie systemy, które podpisują pocztę w imieniu domeny, oraz selektor używany przez każdy z nich.
- Wygeneruj nowy klucz DKIM z nową nazwą selektora.
- Dodaj nowy rekord DNS DKIM obok istniejącego.
- Upewnij się, że jest widoczny publicznie.
- Przełącz podpisywanie na nowy selektor.
- Wyślij wiadomości testowe i sprawdź w nagłówkach dkim=pass oraz nową wartość s=.
- Zachowaj stary rekord do czasu, aż poczta w drodze zostanie zweryfikowana.
- Usuń stary rekord i stary klucz prywatny.
Nazywaj selektory datą albo kolejnym numerem, żeby później było widać wiek klucza (przyszły Ty będzie wdzięczny). Kolejność też ma znaczenie. Najpierw publikacja, potem przełączenie. Dlaczego? Bo podpis złożony kluczem, którego odbiorcy jeszcze nie mogą znaleźć, nie przechodzi weryfikacji.
Każda usługa wysyłkowa ma własny selektor i rotuje się ją osobno, niezależnie od tego, czy to dostawca skrzynek, platforma marketingowa czy system transakcyjny. Najmocniej daje to o sobie znać wtedy, gdy pocztę transakcyjną i marketingową wysyłasz razem. W MailCraft domena wysyłkowa jest uwierzytelniana za pomocą SPF, DKIM i DMARC, więc jej selektor też powinien trafić na tę listę.
Jak długo stary rekord DKIM powinien zostać w DNS?
Do momentu, gdy każda podpisana nim wiadomość zostanie dostarczona i sprawdzona. Potem znika. Wiadomości opóźnione, czekające w kolejce, wysyłane ponownie i przekazywane dalej są weryfikowane jakiś czas po wysyłce, a brak klucza zamienia je w błędy DKIM. Dlatego długość okresu przejściowego oprzyj na zachowaniu własnej kolejki i ponownych prób oraz na raportach DMARC pokazujących, że poprzedni selektor już się nie pojawia.
Ale nie zostawiaj go też na zawsze. To usunięcie rekordu faktycznie wycofuje klucz, bo klucz prywatny, który wyciekł, pozostaje użyteczny tak długo, jak długo dostępna jest jego część publiczna. Podejrzewasz naruszenie? Skróć okres przejściowy i pogódź się z częścią błędów w poczcie, która jest jeszcze w drodze.
Co może pójść nie tak podczas rotacji i jak sprawdzić wynik
Większość nieudanych rotacji ma źródło w DNS: rekord jest błędnie sformatowany, opublikowany pod złą nazwą albo jeszcze niewidoczny w chwili przełączenia podpisywania. Klasyka to obcięta wartość klucza, zbędne spacje lub zepsute cudzysłowy, rekord utworzony na niewłaściwej subdomenie i jeden system wysyłkowy pominięty na liście. Przydaje się też cierpliwość, bo instrukcja Google dotycząca dodawania klucza zaznacza, że uwierzytelnianie DKIM może zacząć działać nawet po 48 godzinach.
Sprawdzenie wyniku jest proste. Nagłówek wiadomości powinien pokazywać dkim=pass z nowym selektorem. W nagłówku w ogóle nie ma wiersza DKIM? To znaczy, że wiadomości nie są podpisywane. Po przełączeniu obserwuj też zbiorcze raporty DMARC. I jeszcze jedno: domena podpisująca nadal musi zgadzać się z adresem w polu From, inaczej DKIM przechodzi, a DMARC nie, i to jest najczęstszy powód, dlaczego zgodność DMARC zawodzi.
Niech rotacja kluczy DKIM będzie rutyną, a nie sytuacją awaryjną
Krótka pisemna notatka sprawia, że następna zmiana to praca z listą kontrolną. Nic wyszukanego. Zapisz używane selektory, system, który podpisuje każdym z nich, długość klucza, datę utworzenia i to, kto ma dostęp do klucza prywatnego. Kampanie i automatyzacje wysyłane z MailCraft korzystają z tej samej uwierzytelnionej domeny, więc ten klucz też zasługuje na wiersz w dokumencie.
Wpisz kolejny termin do kalendarza i za każdym razem powtarzaj te same kroki. A dziś? Sprawdź długość obecnego klucza i zaplanuj przejście na 2048 bitów, jeśli dostawca DNS na to pozwala. Gdy pierwsza rotacja kluczy DKIM będzie już za Tobą, każda kolejna to tylko znany obowiązek.
FAQ
Czy rotacja klucza DKIM wpływa na dostarczalność?
Nie, jeśli nowy klucz zostanie opublikowany przed przełączeniem podpisywania, a stary rekord pozostanie na miejscu przez okres przejściowy. Serwery odbierające po prostu weryfikują każdą wiadomość według tego selektora, który wskazuje jej podpis. Błędy biorą się z pominiętych kroków, na przykład ze zbyt wczesnego usunięcia poprzedniego rekordu albo z zapomnienia o jednym systemie wysyłkowym.
Czy dwa selektory DKIM mogą być aktywne na jednej domenie jednocześnie?
Tak. Każdy selektor to osobny rekord DNS z własnym kluczem publicznym, więc nie wchodzą sobie w drogę. W ten sposób wielu nadawców podpisuje pocztę jednej domeny, a stary i nowy klucz nakładają się na siebie podczas zmiany.
Co zrobić, jeśli mój dostawca DNS nie przyjmuje klucza 2048-bitowego?
Najpierw spróbuj podzielić wartość na kilka ciągów w cudzysłowach wewnątrz jednego rekordu TXT, bo wiele paneli odrzuca długi wpis tylko jako pojedynczy ciąg. Jeśli dostawca naprawdę nie potrafi go zapisać, użyj klucza 1024-bitowego, na co wytyczne Google dotyczące długości klucza pozwalają właśnie w takiej sytuacji. Później warto rozważyć przeniesienie DNS do dostawcy, który obsługuje dłuższe klucze.


