DKIM — jak działa podpis poczty i jak go skonfigurować?

DKIM dodaje do wiadomości podpis kryptograficzny. Serwer wysyłający podpisuje wybrane nagłówki i treść kluczem prywatnym, a odbiorca pobiera z DNS odpowiadający mu klucz publiczny. Dzięki temu może sprawdzić, czy podpis został utworzony przez system kontrolujący daną domenę i czy podpisane elementy nie zostały później zmienione.

Krótka odpowiedź: w panelu dostawcy poczty wygeneruj konfigurację DKIM dla właściwej domeny. Opublikuj dokładnie wskazany rekord DNS pod nazwą zawierającą selektor i _domainkey. Klucz prywatny pozostaje u systemu podpisującego — nigdy nie wklejaj go do publicznego DNS. Po propagacji włącz podpisywanie, wyślij prawdziwą wiadomość i sprawdź w nagłówkach DKIM-Signature, domenę d=, selektor s= oraz wynik dkim=pass.

Co DKIM potwierdza, a czego nie?

Poprawna weryfikacja potwierdza, że:

• podpis pasuje do publicznego klucza wskazanej domeny;
• podpisane nagłówki i treść zachowały postać akceptowaną przez algorytm;
• podmiot mający klucz prywatny podpisał wiadomość.

Nie potwierdza natomiast, że treść jest uczciwa, domena ma dobrą reputację albo odbiorca umieści wiadomość w skrzynce głównej. Atakujący może prawidłowo podpisać pocztę własną domeną. Dlatego DKIM jest sygnałem uwierzytelnienia, nie certyfikatem wiarygodności treści.

Dla DMARC liczy się dodatkowo zgodność domeny podpisu z domeną widoczną w From. Wiadomość może mieć dkim=pass, ale nie przejść DMARC, jeżeli podpis należy wyłącznie do technicznej domeny dostawcy i nie jest wyrównany z autorem.

Cztery elementy konfiguracji DKIM

Domena podpisująca d=

Nagłówek DKIM-Signature zawiera parametr d=, określający domenę biorącą odpowiedzialność za podpis. W typowym wdrożeniu powinna to być domena firmy albo jej właściwa subdomena, obsługiwana przez dostawcę poczty.

Selektor s=

Selektor wskazuje konkretny klucz w obrębie domeny. Pozwala utrzymywać kilka kluczy, rozdzielać systemy i bezpiecznie je rotować. Wartość s=mail2026 prowadzi odbiorcę do rekordu o nazwie podobnej do:

mail2026._domainkey.example.pl

Nazwa jest jedynie przykładem. Użyj dokładnego selektora wygenerowanego przez dostawcę.

Klucz prywatny

Służy do tworzenia podpisów. Powinien znajdować się wyłącznie w kontrolowanym systemie wysyłkowym lub bezpiecznym magazynie sekretów. Nie wolno publikować go w DNS, dokumentacji, zgłoszeniu pomocy ani repozytorium.

Klucz publiczny w DNS

Odbiorca pobiera go, aby zweryfikować podpis. Dostawca zwykle przekazuje gotową nazwę i wartość rekordu TXT albo rekord CNAME prowadzący do własnej infrastruktury. Nie zamieniaj samodzielnie jednego typu na drugi.

Krok 1: ustal, kto naprawdę podpisuje wiadomości

DKIM konfiguruje system, który wysyła i podpisuje pocztę. Może to być dostawca skrzynek, platforma transakcyjna, newsletter lub inna usługa. Sam WordPress zwykle przekazuje wiadomość do dostawcy SMTP lub API, a podpis powstaje dopiero tam.

Zrób listę wszystkich strumieni:

• poczta pracowników;
• formularze i powiadomienia z WordPressa;
• sklep internetowy;
• newsletter;
• faktury, rezerwacje i CRM;
• systemy bezpieczeństwa i monitoringu.

Każdy dostawca może potrzebować własnego selektora. To prawidłowe. Problemem nie jest wiele selektorów, lecz brak kontroli nad tym, który system ma prawo podpisywać wiadomości domeną.

Krok 2: wygeneruj rekord u dostawcy

Skorzystaj z panelu i oficjalnej instrukcji usługi. Dostawca powinien podać:

• domenę, której dotyczy konfiguracja;
• selektor;
• pełną nazwę hosta DNS;
• typ rekordu;
• wartość klucza publicznego lub cel CNAME;
• informację, kiedy można włączyć podpisywanie;
• procedurę testu i rotacji.

Wybierz długość klucza zalecaną i obsługiwaną przez dostawcę oraz operatora DNS. Współczesne usługi często rekomendują klucze 2048-bitowe, ale panel DNS musi przyjąć całą wartość. Nie skracaj jej i nie usuwaj fragmentów tylko dlatego, że interfejs wizualnie dzieli tekst na linie.

Samodzielne generowanie pary kluczy ma sens przy własnej, świadomie utrzymywanej infrastrukturze. W typowej stronie firmowej lepiej użyć mechanizmu dostawcy, który chroni klucz prywatny i automatycznie podpisuje wiadomości.

Krok 3: poprawnie opublikuj DNS

Najczęstsza pułapka to pole „nazwa” w panelu DNS. Jedni operatorzy oczekują pełnej nazwy, inni automatycznie dopisują domenę. Wpisanie pełnej nazwy w tym drugim przypadku może utworzyć rekord pod błędnym adresem, np. z domeną powtórzoną dwukrotnie.

Przed zapisem sprawdź podgląd rekordu końcowego. Nie dodawaj cudzysłowów, spacji ani podziałów inaczej niż wymaga panel. Długi TXT może być prezentowany jako kilka połączonych fragmentów — to nie musi oznaczać kilku rekordów.

Po publikacji odczytaj dokładną nazwę z publicznego DNS:

dig mail2026._domainkey.example.pl TXT

Jeśli dostawca używa CNAME, odpytaj odpowiedni typ. Rekord widoczny w panelu, ale nie w publicznym DNS, nie pomoże odbiorcom.

Krok 4: dopiero teraz włącz podpisywanie

Niektórzy dostawcy automatycznie zaczynają podpisywać po wykryciu rekordu. Inni wymagają kliknięcia „Rozpocznij uwierzytelnianie” albo aktywowania domeny. Zaczekaj na propagację i potwierdzenie w panelu.

Po włączeniu wyślij wiadomości z każdego systemu, który powinien używać domeny. Testowa funkcja w panelu jest pomocna, ale nie zastępuje prawdziwego formularza czy newslettera — różne strumienie mogą przechodzić przez inne serwery.

Jak sprawdzić DKIM w nagłówkach?

Otwórz „pokaż oryginał”, „źródło wiadomości” albo równoważną funkcję programu pocztowego. Szukaj dwóch miejsc.

W DKIM-Signature sprawdź:

• d= — domenę podpisującą;
• s= — selektor;
• h= — listę podpisanych nagłówków;
• a= — algorytm;
• b= — wartość podpisu.

W Authentication-Results sprawdź wynik, np. dkim=pass, i domenę podpisu. Nie oceniaj konfiguracji tylko po obecności nagłówka — podpis może istnieć, ale weryfikacja może kończyć się błędem.

Jeśli celem jest DMARC, porównaj d= z domeną widoczną w From. Przy wyrównaniu relaksowanym domena podpisu może być subdomeną domeny autora; przy ścisłym musi odpowiadać dokładniej. Domyślne ustawienie DMARC jest relaksowane, o ile polityka nie wskazuje inaczej.

Dlaczego DKIM czasem przestaje przechodzić?

Najczęstsze przyczyny to:

• zły selektor albo błędna nazwa rekordu;
• ucięty lub zmieniony klucz publiczny;
• podpisywanie nie zostało aktywowane;
• wiadomość wysłał inny system niż zakładano;
• odbiorca nie może odczytać rekordu DNS;
• klucz został usunięty zbyt wcześnie;
• system pośredni zmienił podpisaną treść lub nagłówek;
• podpis jest poprawny, lecz dotyczy innej domeny niż oczekiwana.

Listy mailingowe, bramki bezpieczeństwa i przekazywanie poczty mogą dopisywać stopki, zmieniać kodowanie albo temat. Takie modyfikacje mogą unieważnić podpis zależnie od tego, co zostało podpisane i jakiej kanonikalizacji użyto. Dlatego warto analizować zarówno wiadomość dostarczoną bezpośrednio, jak i typową drogę firmowego przekazania.

Jak bezpiecznie rotować klucz DKIM?

Selektory istnieją m.in. po to, aby można było wymienić klucz bez nagłego zerwania weryfikacji:

1. wygeneruj nową parę z nowym selektorem;
2. opublikuj nowy klucz publiczny;
3. zaczekaj, aż rekord będzie dostępny w DNS;
4. przełącz podpisywanie na nowy selektor;
5. potwierdź dkim=pass na rzeczywistych wiadomościach;
6. zachowaj stary rekord przez okres potrzebny na dostarczenie wiadomości pozostających w kolejkach;
7. usuń albo unieważnij stary klucz zgodnie z instrukcją dostawcy.

Nie nadpisuj starego klucza nową wartością pod tym samym selektorem bez planu. Wiadomość podpisana wcześniej może dotrzeć z opóźnieniem i wymagać poprzedniego klucza do weryfikacji.

Rotację wykonuj także po podejrzeniu wycieku, zmianie dostawcy lub zakończeniu współpracy z systemem mającym dostęp do klucza. W takim incydencie ważniejsza może być szybka blokada niż zachowanie długiego okresu przejściowego.

DKIM, SPF i DMARC — trzy różne zadania

SPF ocenia, czy serwer wysyłający jest dopuszczony przez politykę domeny transportowej. DKIM sprawdza podpis wiadomości. DMARC łączy wynik przynajmniej jednego z tych mechanizmów z domeną autora widoczną w From i pozwala opublikować politykę dla niespełniających jej wiadomości.

W praktyce warto utrzymywać zarówno SPF, jak i DKIM. Przekazywanie wiadomości może zepsuć SPF, a modyfikacja treści może zepsuć DKIM. Dwa niezależne mechanizmy zwiększają szansę, że legalny strumień zachowa co najmniej jeden wyrównany wynik.

Checklista wdrożenia DKIM

• ☐ Spisano wszystkie systemy wysyłkowe i ich domeny From.
• ☐ Rekord wygenerował właściwy dostawca dla właściwej domeny.
• ☐ Klucz prywatny nie trafił do DNS ani dokumentacji publicznej.
• ☐ Nazwa zawiera poprawny selektor i _domainkey.
• ☐ Panel DNS nie zdublował nazwy domeny.
• ☐ Klucz publiczny jest dostępny w publicznym DNS.
• ☐ Podpisywanie zostało aktywowane po publikacji rekordu.
• ☐ Każdy rzeczywisty strumień wysłał wiadomość testową.
• ☐ W nagłówkach są oczekiwane d=, s= i dkim=pass.
• ☐ Domena d= jest wyrównana z widocznym From, jeśli ma spełniać DMARC.
• ☐ Istnieje procedura rotacji i unieważnienia klucza.