Co to jest DKIM? Uwierzytelnianie email wyjaśnione

DKIM (DomainKeys Identified Mail) to kryptograficzny protokół uwierzytelniania poczty email. Co to jest DKIM w praktyce: przypisuje podpis RSA do każdej wychodzącej wiadomości wysyłanej przez Twój serwer pocztowy. Odbierający MTA pobiera Twój klucz publiczny z DNS, weryfikuje ten podpis i raportuje wynik jako dkim=pass lub dkim=fail. Wynik ten zasila model reputacji Twojej domeny i decyduje o tym, czy wyrównanie DMARC zostaje zachowane. Bez ważnego podpisu odbierający MTA nie ma kryptograficznego potwierdzenia, że wiadomość pochodzi z Twojej infrastruktury.

DKIM to protokół podpisywania, nie filtr

Nazwa ta wywołuje powszechne nieporozumienie. DKIM nie blokuje poczty email. Nie poddaje wiadomości kwarantannie ani nie egzekwuje żadnej polityki samodzielnie. To, co robi, to opatrywanie każdej wychodzącej wiadomości weryfikowalnym twierdzeniem: ta wiadomość została podpisana przez domenę wskazaną w polu d=, przy użyciu klucza prywatnego odpowiadającego selektorowi s=.

Odbierający MTA pobiera to twierdzenie, konstruuje zapytanie DNS do <selektor>._domainkey.<domena>, pobiera rekord TXT zawierający klucz publiczny i przeprowadza weryfikację kryptograficzną. Jeśli weryfikacja się powiedzie, nagłówek wyników uwierzytelniania pokazuje dkim=pass. W przypadku niepowodzenia pojawia się dkim=fail lub dkim=temperror.

Żaden z tych wyników sam w sobie nie powoduje odrzucenia wiadomości. Sygnał zasila model reputacji serwera odbierającego i, co kluczowe, ocenę DMARC. Zadaniem DKIM jest generowanie weryfikowalnego wyniku, a nie działanie na jego podstawie.

Warto też wiedzieć, że wyniki uwierzytelniania są zawarte w nagłówku każdej odebranej wiadomości. Administratorzy systemów i inżynierowie ds. dostarczalności mogą przeglądać te nagłówki, aby zrozumieć, dlaczego wiadomość przeszła lub nie przeszła weryfikacji DKIM. To pierwszy krok w diagnozowaniu problemów z uwierzytelnianiem. Narzędzia takie jak MXToolbox czy mail-tester.com pozwalają na szybkie sprawdzenie konfiguracji DKIM bez konieczności analizowania nagłówków ręcznie.

Co DKIM podpisuje i co obejmuje podpis

DKIM podpisuje dwie rzeczy: wybrane nagłówki wiadomości oraz jej treść. Algorytm podpisywania hashuje obie i przechowuje wynik w polu nagłówka DKIM-Signature.

Lista nagłówków jest kontrolowana przez znacznik h= w podpisie. Typowa konfiguracja produkcyjna obejmuje from:subject:date:message-id:content-type. Nagłówek from jest tym istotnym dla wyrównania DMARC. Hash treści obejmuje całą treść wiadomości, znormalizowaną za pomocą kanonizacji simple lub relaxed.

Kanonizacja relaxed jest tą używaną przez większość stosów produkcyjnych. Normalizuje białe znaki przed haszowaniem, co pozwala podpisowi przetrwać drobne przeformatowania przez pośrednie MTA. Kanonizacja simple jest surowsza: pojedyncza zmiana końcowego białego znaku niszczy podpis. W polu DKIM-Signature praktycznie każdego dobrze skonfigurowanego dostawcy usług email znajdziesz c=relaxed/relaxed.

Czego DKIM nie podpisuje: nadawcy koperty SMTP, nagłówków routingu jak Received oraz żadnego nagłówka spoza listy h=. Jest to zamierzone. Podpisanie koperty zepsułoby scenariusze przekazywania dalej, co jest właśnie zaletą DKIM nad SPF.

Selektor DKIM: mechanizm kontroli dostępu traktowany jak etykieta

Selektor to część DKIM, którą większość zespołów lekceważy, dopóki nie musi pod presją rotować kluczy.

Pole s= w Twoim DKIM-Signature wskazuje na konkretny klucz publiczny w DNS. Format wyszukiwania to <selektor>._domainkey.<twojadomena.com>. Jeśli Twój selektor to mail2026, a domena to example.com, resolver szuka rekordu TXT pod mail2026._domainkey.example.com.

Jedna domena może mieć wiele aktywnych selektorów jednocześnie. Każda usługa wysyłania, każdy dostawca usług email, każdy wewnętrzny MTA powinien używać własnego selektora. Daje to trzy konkretne możliwości operacyjne:

• Niezależna rotacja kluczy dla każdej usługi bez wpływu na innych nadawców.

• Możliwe do śledzenia przypisanie w dziennikach uwierzytelniania: selektor informuje, który klucz podpisywania został użyty dla danej wiadomości.

• Czyste zakończenie współpracy: usuń rekord DNS selektora, a ten dostawca usług email nie będzie mógł już podpisywać jako Twoja domena, niezależnie od tego, co robi po swojej stronie.

To, co obserwuje się w logach: zespoły konfigurujące wspólny selektor dla wszystkich usług wysyłania nie mogą odwołać dostępu jednemu nadawcy bez zakłócenia pracy wszystkich pozostałych. Selektor nie jest elementem dekoracyjnym. Jest mechanizmem kontroli dostępu.

DKIM i wyrównanie DMARC: jak działa warstwa egzekwowania

Zaliczenie DKIM jest warunkiem wstępnym dla określonego rodzaju zaliczenia DMARC zwanego wyrównaniem DKIM.

DMARC wymaga co najmniej jednego z dwóch warunków wyrównania: wyrównania SPF lub wyrównania DKIM. Wyrównanie DKIM oznacza, że domena w nagłówku From: odpowiada wartości d= w podpisie DKIM, a podpis zostaje zweryfikowany. Gdy oba warunki są spełnione, DMARC uznaje wiadomość za uwierzytelnioną.

Właśnie dlatego DKIM jest trwalszym sygnałem uwierzytelniania. Wyrównanie SPF zrywa się przy przekazywaniu dalej: gdy wiadomość jest przekazywana, nadawca koperty SMTP zmienia się, a ocena SPF nie powodzi się w odniesieniu do nowego adresu IP wysyłania. Wyrównanie DKIM przeżywa przekazywanie dalej, ponieważ podpis i nagłówek From: podróżują z treścią wiadomości i nie są przepisywane przez pośrednie MTA, pod warunkiem że treść wiadomości nie jest modyfikowana w tranzycie.

W przypadku domen z polityką DMARC p=reject wiadomość, która nie zalicza ani wyrównania SPF, ani DKIM, jest odrzucana przez odbierający MTA. To właśnie mechanizm, który uniemożliwia sfałszowanym wiadomościom z Twojej domeny docieranie do skrzynek odbiorczych na dużą skalę. DKIM nie jest tutaj ostatnią linią obrony. Ale jest linią, która utrzymuje się, gdy przekazywanie dalej jest na ścieżce.

Od 2024 roku Google, Yahoo i Microsoft wymagają DKIM od masowych nadawców wysyłających 5.000 lub więcej wiadomości dziennie do ich serwerów MX. Wiadomości z niepodpisanych domen są domyślnie kierowane do spamu lub odrzucane.

To nie jest funkcja marketingowa. To ograniczenie infrastrukturalne.

Długość klucza i rotacja: praktyczne decyzje na rok 2026

Większość implementacji DKIM używa RSA-SHA256. Kluczową kwestią jest długość klucza.

Klucze RSA o długości 1024 bitów nadal pojawiają się w starszych konfiguracjach. NIST wycofał 1024-bitowe RSA dla większości zastosowań w 2015 roku. Klucz 2048-bitowy zapewnia znacznie większy margines bezpieczeństwa i jest obsługiwany przez wszystkich głównych dostawców usług MTA i odbierających. Jeśli generujesz dziś nowy klucz, użyj 2048 bitów.

Niektóre zespoły przeniosły aktywny klucz podpisywania do 2048 bitów, ale pozostawiły stare selektory 1024-bitowe opublikowane w DNS, ponieważ nikt nie przeprowadził audytu zasobów. Trzy sygnały zmieniające zachowanie systemu: jeśli widzisz k=rsa z kluczem 1024-bitowym w starym selektorze, ten selektor stanowi zagrożenie, nawet jeśli Twoja obecna infrastruktura podpisywania już dokonała przejścia. Ważny, ale wycofany selektor jest podatny na exploitację.

Harmonogram rotacji kluczy: większość zespołów infrastruktury rotuje corocznie, niektóre kwartalnie w przypadku domen o wyższej wrażliwości. Kolejność ma znaczenie:

• Wygeneruj nową parę kluczy.

• Opublikuj nowy klucz publiczny pod nową nazwą selektora w DNS.

• Poczekaj na propagację TTL, zazwyczaj od 24 do 48 godzin dla rekordów z niskim TTL.

• Przełącz klucz podpisywania w konfiguracji MTA na nowy selektor.

• Zweryfikuj DKIM pass na wychodzących wiadomościach za pomocą narzędzia do testowania poczty lub poprzez sprawdzenie nagłówków wyników uwierzytelniania w wiadomości testowej.

• Po potwierdzeniu, że nowy klucz jest aktywny i poprawnie podpisuje, usuń stary rekord DNS.

Rotacja nie powoduje zakłóceń, jeśli postępujesz zgodnie z kolejnością: najpierw DNS, potem przełączenie podpisywania, usunięcie starego rekordu na końcu. Odwrócenie kroków 4 i 6 powoduje okno dkim=fail. Każda rotacja klucza powinna być poprzedzona planem rollback, szczególnie w środowiskach produkcyjnych gdzie niedostępność DKIM przez nawet kilka godzin może wpłynąć na dostarczalność wiadomości. Automatyzacja tego procesu, na przykład za pomocą skryptów Terraform lub Ansible zarządzających rekordami DNS, znacznie zmniejsza ryzyko błędów ludzkich podczas rotacji.

Sygnały operacyjne do monitorowania po konfiguracji DKIM

DKIM nie jest jednorazowym zadaniem konfiguracyjnym. Poniższe sygnały wskazują, że coś się zmieniło lub zepsuło.

dkim=temperror w odebranych nagłówkach. Tymczasowe błędy zazwyczaj wskazują na problemy z wyszukiwaniem DNS po stronie odbierającej lub niezgodność TTL podczas rotacji kluczy. Jeśli widzisz to na wychodzących wiadomościach krótko po rotacji kluczy, poczekaj na pełną propagację, zanim stwierdzisz, że sam klucz jest źle skonfigurowany.

dkim=fail w wysłanych wiadomościach. Modyfikacja treści przez pośredni relay to najczęstsza przyczyna. Sprawdź, czy w ścieżce dostarczania znajduje się hop przekazujący dalej, procesor listy mailingowej lub relay wstrzykujący stopkę. Jeśli błąd jest spójny dla jednego przepływu, mapuj łańcuch relayów hop po hopie.

Brakujący nagłówek DKIM-Signature. Demon podpisywania na Twoim MTA nie działa, ścieżka do klucza podpisywania jest nieprawidłowa lub mapowanie domeny na selektor jest źle skonfigurowane w konfiguracji MTA. Jest to całkowita awaria DKIM dla dotkniętych przepływów wiadomości.

Brak rekordu TXT selektora w DNS. Strefa DNS została edytowana lub zmigrowana bez zachowania rekordu selektora DKIM. Zweryfikuj za pomocą dig TXT <selektor>._domainkey.<domena> z zewnętrznego resolvera.

W konfiguracji wysyłania wieloregionalnego niespójne wyniki DKIM między węzłami są często spowodowane tym, że różne węzły używają różnych konfiguracji selektorów. Potwierdź, że konfiguracja klucza podpisywania jest zsynchronizowana we wszystkich węzłach wysyłania przed wdrożeniem rotacji.

Przed czym DKIM nie chroni

DKIM nie jest filtrem spamu. Nadawca może zarejestrować nową domenę, skonfigurować ważny DKIM i wysyłać w pełni uwierzytelniony spam. Podpis weryfikuje się bez problemów. Uwierzytelnianie potwierdza pochodzenie, nie intencje ani jakość treści.

DKIM nie chroni też przed spoofingiem nazwy wyświetlanej, gdzie nagłówek From: pokazuje zaufaną nazwę, taką jak "Dział Kadr", sparowaną z domeną kontrolowaną przez atakującego. Weryfikacja kryptograficzna działa na domenie, a nie na wizualnej prezentacji w kliencie pocztowym. Większość phishingu na poziomie klienta pocztowego opiera się na oszukiwaniu za pomocą nazwy wyświetlanej, a nie na spoofingu dokładnej domeny.

Przed czym DKIM chroni: spoofing dokładnej domeny, gdzie atakujący próbuje wysyłać jako Twoja domena bez posiadania Twojego klucza prywatnego. W połączeniu z polityką DMARC p=reject egzekwującą wyrównanie DKIM zapobiega to tej kategorii sfałszowanych wiadomości docierających do skrzynek odbiorczych u odbierających dostawców egzekwujących DMARC.

Praktyczna uwaga: sam DKIM nie wystarczy. Model ochrony wymaga egzekwowania polityki DMARC przez odbierający MTA. DKIM jest warstwą uwierzytelniania, która nadaje sens DMARC. SPF to inna warstwa uwierzytelniania, obsługująca weryfikację nadawcy koperty. Wszystkie trzy działają razem. Brak któregokolwiek z nich pozostawia lukę w łańcuchu egzekwowania.

Jeśli skonfigurowałeś już DKIM i SPF, ale nie opublikowałeś jeszcze rekordu DMARC, podpisy istnieją, ale żadna polityka egzekwowania nie jest aktywna. Tryb monitorowania (p=none z raportowaniem rua) to rozsądny pierwszy krok: otrzymujesz zagregowane raporty pokazujące wskaźniki zaliczenia uwierzytelniania w Twojej domenie wysyłania, zanim zdecydujesz się na p=quarantine lub p=reject.