Jak bezpiecznie przeprowadzić rotację kluczy DKIM

Klucz DKIM, który nigdy się nie zmienia, z czasem staje się ryzykiem: im dłużej jest używany, tym więcej jest miejsc, do których trafiła kopia klucza prywatnego, i tym dłużej wykradziona kopia pozostaje groźna. Rotacja kluczy to wymiana pary kluczy, którymi podpisujesz pocztę — tak, by po drodze żadna wiadomość nie przestała się weryfikować.

Cały sekret tkwi w selektorze. Publikujesz nowy klucz pod nową nazwą, przełączasz na niego podpisywanie, a stary klucz wycofujesz dopiero wtedy, gdy podpisana nim poczta zdąży zostać zweryfikowana. Jeśli chcesz najpierw odświeżyć wiedzę o podpisach i selektorach, zacznij od poradnika Jak działa DKIM i jak znaleźć selektor.

Po co w ogóle rotować klucze

• Wyciek klucza prywatnego pozwala każdemu podpisywać wiadomości jako Ty. RFC 6376 (sekcja 8.3) mówi to wprost: kto ma klucz prywatny, może wysyłać pocztę podpisaną Twoją domeną, a ta przechodzi DKIM — i DMARC. Rotacja skraca czas, przez który wykradziony klucz jest przydatny.
• Stare klucze bywają za krótkie. RFC 8301 ustanowił 1024 bity jako minimum, a 2048 bitów jako zalecenie. Rotacja to sposób na pozbycie się starych kluczy 1024-bitowych.
• Zmieniają się ludzie i dostawcy. Administratorzy odchodzą, umowy z usługami wysyłkowymi wygasają.
• Wprawa. M3AAWG zaleca rotację co najmniej co sześć miesięcy — także po to, by procedura była rutyną w dniu, w którym trzeba ją wykonać w pośpiechu.

Wybierz nowy klucz

Używaj RSA o długości 2048 bitów i algorytmu rsa-sha256. RFC 8301 wymaga od podpisujących co najmniej 1024 bitów, zaleca co najmniej 2048, wymaga od weryfikujących obsługi kluczy od 1024 do 4096 bitów i zakazuje rsa-sha1 zarówno przy podpisywaniu, jak i weryfikacji.

Klucz publiczny 2048-bitowy ma około 400 znaków base64 — więcej, niż mieści jeden ciąg w rekordzie TXT (255). Rekord dzieli się więc na kilka ciągów, które przed użyciem są łączone bez spacji (RFC 6376, sekcja 3.6.2.2). Wiele paneli DNS dzieli długie wartości samodzielnie, w innych trzeba wpisać ciągi ręcznie.

Parę kluczy wygenerujesz tymi samymi poleceniami OpenSSL, których RFC 6376 używa w załączniku — tylko z 2048 bitami zamiast 1024:

openssl genrsa -out s202610.private 2048
openssl rsa -in s202610.private -pubout -out s202610.public

Wartość p= to zawartość pliku s202610.public bez linii BEGIN i END, połączona w jeden wiersz. Wiele serwerów pocztowych i narzędzi do podpisywania generuje klucz razem z gotowym rekordem DNS. Jeśli podpisujesz też kluczami Ed25519 (RFC 8463), rotuj je tak samo, każdy pod własnym selektorem.

Selektory umożliwiają okres przejściowy

Klucz publikuje się pod nazwą selektor._domainkey.domena, a każdy podpis wskazuje swój selektor w tagu s=. Ponieważ selektorów może być dowolnie wiele, stary i nowy klucz mogą być opublikowane jednocześnie (RFC 6376, sekcja 3.1). Wynikają z tego dwie zasady:

• Nowy klucz — nowy selektor. RFC 6376 odradza używanie starego selektora dla nowego klucza, bo nie dałoby się odróżnić wiadomości podpisanej starym kluczem od sfałszowanej. M3AAWG dodaje, że weryfikujący mogą mieć stary klucz wciąż w pamięci podręcznej.
• Przyjmij schemat nazw. Selektor, który mówi, kiedy klucz wszedł do użytku — s202610 dla października 2026 — ułatwia kontrole. M3AAWG proponuje umieszczać w nazwie datę, a opcjonalnie także strumień poczty i długość klucza.

Rotacja krok po kroku

W tym przykładzie example.com podpisuje selektorem s202604 i przechodzi na s202610.

1. Wygeneruj nową parę kluczy. Klucz prywatny zostaje wyłącznie w systemie, który podpisuje pocztę.

2. Opublikuj klucz publiczny pod nowym selektorem:

   s202610._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" "…IDAQAB"
   

3. Sprawdź rekord, zanim zaczniesz nim podpisywać. Sprawdzanie DKIM z selektorem s202610 pokaże typ i długość klucza oraz wychwyci błędnie połączone ciągi. Zupełnie nowa nazwa jest zwykle widoczna szybko, bo żaden resolwer jej jeszcze nie zapamiętał — chyba że ktoś zapytał o nią przed publikacją; wtedy odpowiedź „nie istnieje” może zostać w pamięci podręcznej tak długo, jak strefa każe przechowywać odpowiedzi negatywne. Propagacja DNS porówna odpowiedzi publicznych resolwerów.

4. Przełącz podpisywanie na s202610 w serwerze pocztowym lub usłudze podpisującej. Stary klucz zostaw opublikowany.

5. Sprawdź na prawdziwej poczcie. Wyślij wiadomość do zewnętrznej skrzynki i wklej jej nagłówki do narzędzia Analizator nagłówków e-mail: nagłówek DKIM-Signature powinien zawierać s=s202610, a Authentication-Results — dkim=pass. W kolejnych dniach raporty zbiorcze DMARC pokażą selektor każdego podpisu, więc zobaczysz, czy któryś system wciąż podpisuje starym kluczem.

6. Odczekaj. Odbiorcy nie zawsze weryfikują podpis w chwili doręczenia. RFC 6376 (sekcja 5.2) mówi, że stary klucz publiczny powinien pozostać opublikowany przez rozsądny czas potrzebny na weryfikację; M3AAWG zaleca co najmniej siedem, a najwyżej 30 dni.

7. Unieważnij stary klucz, opróżniając p=:

   s202604._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; p="
   

   Puste p= oznacza klucz unieważniony; weryfikujący traktują podpisy, które go używają, jako nieudane. Według RFC 6376 unieważniony klucz i usunięty rekord znaczą to samo, ale M3AAWG zaleca zostawić unieważniony rekord, żeby było widać, że klucz wycofano celowo.

8. Zniszcz stary klucz prywatny.

Kiedy	Działanie	Opublikowane klucze
Dzień 0	publikacja s202610	s202604 (podpisuje), s202610
Dzień 1	przełączenie podpisywania	s202604, s202610 (podpisuje)
Dzień 8–31	unieważnienie s202604	s202604 unieważniony, s202610 (podpisuje)

M3AAWG podsuwa też dobry nawyk: publikuj następny klucz z wyprzedzeniem. Gdy zapasowy selektor już jest w DNS, awaryjna rotacja sprowadza się do zmiany konfiguracji po stronie podpisującej.

TTL

Przy zwykłej rotacji TTL ma niewielkie znaczenie, bo dodajesz nową nazwę, a starą zmieniasz dopiero po tygodniach. Liczy się w dwóch sytuacjach:

• Awaryjne unieważnienie. Resolwery, które zapamiętały stary klucz, podają go aż do wygaśnięcia TTL. Utrzymuj umiarkowany TTL rekordów z kluczami — np. 3600 sekund — żeby unieważnienie działało po godzinach, a nie po dniach.
• Zmiana klucza „w miejscu”. Jeśli pod istniejącym selektorem opublikujesz nowy klucz, pamięci podręczne wciąż będą podawać stary i nowe podpisy nie przejdą weryfikacji, dopóki TTL nie minie. To kolejny powód, by za każdym razem używać nowego selektora.

Gdy klucz wycieknie

1. Przełącz podpisywanie na zapasowy, wcześniej opublikowany selektor albo opublikuj nowy klucz i przełącz się, gdy tylko będzie widoczny.
2. Natychmiast unieważnij skompromitowany selektor pustym p=. Wiadomości podpisane nim, które są jeszcze w drodze, nie przejdą DKIM; jeśli Twój SPF jest zgodny z domeną z From, nadal mogą przejść DMARC.
3. Ustal, jak klucz wyciekł, zanim nowy podzieli jego los.

Klucze utrzymywane przez dostawcę (CNAME)

Wiele usług nie daje Ci klucza do opublikowania, tylko prosi o rekordy CNAME wskazujące na klucze, które utrzymuje u siebie:

esp1._domainkey.example.com.  3600  IN  CNAME  esp1.example-com.dkim.esp.example.net.
esp2._domainkey.example.com.  3600  IN  CNAME  esp2.example-com.dkim.esp.example.net.

Dostawca może wtedy rotować klucze, zmieniając to, co publikuje u siebie — bez żadnych zmian w Twoim DNS. Mając co najmniej dwa rekordy CNAME, dostawca może publikować stary i nowy klucz jednocześnie; M3AAWG opisuje taki model delegowania z trzema wpisami.

Microsoft 365 używa dwóch rekordów CNAME: selector1._domainkey i selector2._domainkey. Rotację uruchamiasz w portalu Microsoft Defender albo poleceniem Rotate-DkimSigningConfig w Exchange Online PowerShell; nowy klucz zaczyna podpisywać po czterech dniach (96 godzinach). Konfiguracja tworzona w PowerShell domyślnie używa kluczy 1024-bitowych; Rotate-DkimSigningConfig -KeySize 2048 przechodzi na 2048 bitów, zaczynając od selektora, który staje się aktywny przy tej rotacji.

Google Workspace daje rekord TXT do samodzielnej publikacji, z domyślnym selektorem (prefiksem) google; wybierz 2048 bitów, jeśli Twój dostawca DNS je obsługuje. Strona konfiguracji pozwala podać inny prefiks, więc nowy klucz nie musi zastępować starego rekordu w miejscu — samo przełączenie przeprowadź według aktualnych instrukcji Google.

Przy kluczach utrzymywanych przez dostawcę pilnuj dwóch rzeczy:

• Zachowaj wszystkie rekordy CNAME, dopóki usługa wysyła w Twoim imieniu. Microsoft zaznacza, że bez rekordu selector2 rotacja kluczy się nie uda.
• Usuń rekordy CNAME, gdy rezygnujesz z usługi. W przeciwnym razie dostawca nadal kontroluje ważny klucz podpisujący dla Twojej domeny.

Sprawdzanie DKIM podąża za delegacją CNAME, więc po każdej rotacji sprawdzisz długość klucza utrzymywanego przez dostawcę.

Przed pierwszą rotacją

• Spisz swoje selektory. DNS nie pozwala wylistować nazw pod _domainkey, więc zbierz je z tagu s= w poczcie z każdego systemu wysyłającego albo z wpisów DKIM w raportach zbiorczych — zobacz Jak czytać raporty zbiorcze DMARC.
• Zanotuj dla każdego systemu, kto ma klucz prywatny, jaka jest długość klucza i kiedy była ostatnia rotacja.
• Wpisz następną rotację do kalendarza.