rekord DKIM

Rekord DKIM to wpis DNS zawierający klucz publiczny umożliwiający weryfikację podpisu wiadomości.

Rekord DKIM – czym jest i do czego służy

Rekord DKIM jest elementem konfiguracji DNS domeny używanej do wysyłania poczty elektronicznej. Zawiera klucz publiczny powiązany z podpisem dołączanym do wiadomości przez serwer wysyłający. Klucz prywatny pozostaje po stronie systemu, który nadaje wiadomość, natomiast klucz publiczny zostaje opublikowany w DNS. Dzięki temu system odbierający może sprawdzić, czy podpis znajdujący się w nagłówkach wiadomości odpowiada opublikowanej wartości.

Weryfikacja DKIM nie polega na odczytywaniu treści wiadomości przez odbiorcę. Podczas wysyłki obliczany jest skrót wybranych nagłówków oraz fragmentu treści, a następnie skrót zostaje zabezpieczony kluczem prywatnym. Po odebraniu wiadomości system pocztowy odczytuje między innymi nazwę domeny podpisującej oraz selektor, czyli identyfikator wskazujący właściwy rekord DNS. Następnie pobiera klucz publiczny i sprawdza zgodność podpisu. Pomyślna kontrola oznacza, że wiadomość została podpisana przez uprawniony system i że podpisane elementy nie uległy zmianie po wysłaniu.

Sam rekord DKIM nie jest więc hasłem, nazwą użytkownika ani adresem skrzynki pocztowej. Jest publiczną częścią mechanizmu kryptograficznego. Jego obecność nie gwarantuje automatycznie dostarczenia każdej wiadomości do skrzynki odbiorczej, ponieważ na ocenę wpływają również reputacja domeny, zgodność adresu nadawcy, treść wiadomości, historia wysyłki oraz pozostałe mechanizmy ochrony poczty.

Rekord DKIM w DNS – budowa i znaczenie selektora

Typowy rekord DKIM jest rekordem TXT umieszczonym pod nazwą złożoną z selektora, stałego fragmentu _domainkey oraz nazwy domeny. W praktyce nazwa może mieć postać zbliżoną do wybrany-selektor._domainkey.przyklad.pl. Selektor nie jest kluczem publicznym. Pełni funkcję wskazującą, gdzie należy szukać właściwej wartości. Dzięki temu w jednej domenie może być używanych kilka podpisów, na przykład dla różnych systemów wysyłkowych, aplikacji, biuletynów albo odrębnych etapów migracji poczty.

Wartość TXT zawiera zwykle oznaczenie wersji oraz parametr klucza publicznego. Najczęściej spotyka się zapis rozpoczynający się od oznaczenia wersji DKIM, po którym występuje parametr określający rodzaj klucza i sama wartość klucza. Dłuższy klucz może zostać przedstawiony w panelu DNS jako kilka połączonych fragmentów tekstu. Taki podział nie powinien być samodzielnie usuwany ani zmieniany, ponieważ po złożeniu fragmentów musi powstać dokładnie ta sama wartość, która została przekazana przez system pocztowy.

Przy sprawdzaniu konfiguracji istotne jest rozróżnienie między nazwą domeny nadawcy widoczną dla odbiorcy a domeną zapisaną w podpisie DKIM. Podpis może pochodzić z domeny pomocniczej, dlatego sam fakt uzyskania wyniku pozytywnego nie zawsze oznacza pełną zgodność z adresem znajdującym się w polu nadawcy. Tę zgodność analizuje się szerzej, razem z mechanizmem DMARC oraz informacjami SPF.

Rekord DKIM a SPF i DMARC – porównanie mechanizmów

DKIM, SPF i DMARC rozwiązują powiązane, lecz różne problemy. DKIM sprawdza podpis kryptograficzny dołączony do wiadomości. SPF określa, które adresy serwerów mogą wysyłać pocztę w imieniu danej domeny i wykorzystuje do tego rekord TXT z listą uprawnionych źródeł. DMARC ustala sposób interpretowania wyników SPF i DKIM, a także zasady postępowania z wiadomościami, które nie przejdą kontroli lub nie będą zgodne z domeną widoczną dla odbiorcy.

Podpis DKIM może przetrwać przekazywanie wiadomości przez inne systemy, o ile nie zostaną zmienione elementy objęte podpisem. Z tego powodu stanowi uzupełnienie SPF, który ocenia źródło połączenia wysyłającego. Z kolei SPF może przestać odzwierciedlać rzeczywistą ścieżkę dostarczenia, gdy wiadomość zostaje przekazana dalej przez kolejny system. Stosowanie obu mechanizmów ogranicza zależność od jednego sposobu weryfikacji.

Wynik pozytywny DKIM nie oznacza, że treść jest bezpieczna ani że nadawca jest znany odbiorcy. Oznacza jedynie, że podpis można zweryfikować względem klucza opublikowanego dla wskazanego selektora. Wiadomość może nadal zawierać próbę oszustwa, złośliwy załącznik albo link prowadzący do niebezpiecznej strony. Ocena techniczna oraz ocena reputacyjna są odrębnymi etapami filtrowania poczty.

Rekord DKIM – typowe problemy z konfiguracją

Jednym z częstych problemów jest opublikowanie rekordu pod nieprawidłową nazwą. Pomyłka w selektorze, dodatkowe powtórzenie nazwy domeny albo umieszczenie wpisu w niewłaściwej strefie powodują, że system odbierający nie znajduje klucza. Niekiedy panel zarządzania DNS automatycznie dopisuje nazwę domeny do pola nazwy. Jeżeli zostanie ona wpisana również ręcznie, powstaje adres inny od oczekiwanego.

Inną przyczyną niepowodzenia jest niepełna lub uszkodzona wartość TXT. Dotyczy to zwłaszcza długich kluczy dzielonych na kilka fragmentów, znaków spacji, cudzysłowów oraz przypadkowo dodanych znaków. Rekord może być widoczny w jednym panelu, lecz jeszcze niedostępny w innych miejscach z powodu czasu odświeżania pamięci DNS. Podczas diagnozy uwzględnia się więc zarówno poprawność wpisu, jak i możliwość odczytania go z zewnętrznych serwerów DNS.

Błąd może pojawić się również po zmianie dostawcy poczty albo po zakończeniu migracji. Nowy system może używać innego selektora i innego klucza, a poprzedni wpis pozostaje w strefie bez zastosowania. Usunięcie starego rekordu bez potwierdzenia, że nie jest już wykorzystywany, może jednak doprowadzić do problemów z wiadomościami wysyłanymi przez nadal działające narzędzie. Przydatne jest przygotowanie listy wszystkich źródeł wysyłki i przypisanie im selektorów.

Problemy bywają mylone z awarią skrzynki, ponieważ ich skutkiem może być odrzucanie wiadomości, trafianie do spamu albo wyświetlanie ostrzeżenia o niezweryfikowanym nadawcy. W takich sytuacjach sprawdza się nagłówki odebranej wiadomości, wynik kontroli DKIM, nazwę selektora, domenę podpisującą oraz zgodność z zasadami DMARC. Sama edycja rekordu bez analizy tych danych może usunąć objaw tylko na krótko.

Rekord DKIM – praktyczne wskazówki dotyczące sprawdzania

Przed zmianą wpisu warto ustalić, który system faktycznie wysyła wiadomości. Należy uwzględnić pocztę używaną przez pracowników, formularze kontaktowe, systemy powiadomień, platformy do wysyłki biuletynów oraz aplikacje korzystające z adresu domenowego. Dla każdego źródła powinno być jasne, jaki selektor jest używany i gdzie znajduje się klucz prywatny. Nie należy publikować klucza prywatnego w DNS, w wiadomościach ani w publicznej dokumentacji.

Po dodaniu lub zmianie rekordu wykonuje się kontrolę z kilku niezależnych miejsc. Sprawdza się dokładną nazwę TXT, kompletność wartości, brak drugiego sprzecznego wpisu oraz rezultat testowej wysyłki. W nagłówkach odebranej wiadomości szuka się informacji o wyniku weryfikacji, domenie podpisującej i selektorze. Jeżeli wiadomość przechodzi przez kilka etapów, analizuje się także to, w którym miejscu podpis został zmieniony albo usunięty.

Podczas planowania rotacji kluczy przygotowuje się nowy selektor, publikuje nowy klucz publiczny, uruchamia podpisywanie po stronie wysyłającej, a dopiero później rozważa usunięcie starego wpisu. Takie działanie ogranicza ryzyko przerwy w weryfikacji. Kolejność ma znaczenie również wtedy, gdy zmieniany jest dostawca poczty lub konfiguracja domeny. Warto zachować opis używanych selektorów, datę zmian i system, który korzysta z danego podpisu.

Zgłoszenie problemu do Warszawskiego Pogotowia Komputerowego 24/7 może być zasadne, gdy nie udaje się ustalić źródła wysyłki, rekord pozostaje niewidoczny mimo poprawnej edycji albo wyniki DKIM są niespójne między różnymi wiadomościami. Do analizy przydatne są pełne nagłówki przykładowej wiadomości, nazwa domeny, używany selektor oraz informacja, po jakiej zmianie pojawiły się trudności. Nie powinno się przekazywać haseł ani kluczy prywatnych.