Co to jest DKIM i jak go włączyć: rekord, selektor, błędy
DKIM to podpis cyfrowy dołączany do każdej wysłanej wiadomości. Serwer odbiorcy sprawdza go kluczem publicznym z Twojego DNS i wie, że wiadomość wyszła z Twojej domeny i nie została po drodze zmieniona. Bez DKIM duzi odbiorcy coraz częściej traktują pocztę jako podejrzaną.
Co robi DKIM
Serwer wysyłający liczy skrót treści i wybranych nagłówków, podpisuje go kluczem prywatnym i dodaje wynik do wiadomości jako nagłówek DKIM-Signature. Klucz prywatny zostaje u dostawcy poczty. Klucz publiczny publikujesz w DNS jako rekord TXT. Serwer odbiorcy odczytuje z nagłówka nazwę domeny (tag d=) i selektor (s=), pobiera klucz z DNS i sprawdza podpis. Zmiana treści albo podpisanego nagłówka w drodze powoduje, że podpis przestaje pasować. Pole "Od" musi być częścią podpisu (RFC 6376, sekcja 5.4).
DKIM nie szyfruje wiadomości i sam nie mówi odbiorcy, co zrobić z pocztą bez podpisu. Tę decyzję podejmuje DMARC.
Gdzie leży klucz i jak wygląda rekord
Klucze DKIM leżą w poddomenie _domainkey. Pełna nazwa rekordu to <selektor>._domainkey.<domena>, na przykład poczta2026._domainkey.twojafirma.pl. Typ rekordu to TXT (u części dostawców CNAME wskazujący na rekord dostawcy). Przykład z kluczem skróconym dla czytelności:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
v=DKIM1to wersja. Jeśli występuje, musi być pierwszym tagiem w rekordzie.k=to typ klucza. Domyślnie rsa; dla kluczy Ed25519 wpisuje sięk=ed25519(RFC 8463).p=to klucz publiczny zapisany w base64. Pusta wartość oznacza, że klucz został wycofany.t=y(opcjonalnie) oznacza, że domena dopiero testuje DKIM i odbiorca nie powinien traktować takiej poczty inaczej niż niepodpisanej. Po zakończeniu testów tag usuń.
Selektor i dlaczego skan z zewnątrz go nie znajdzie
Selektor to dowolna nazwa, którą wybiera dostawca albo Ty. Dzięki niej domena może mieć kilka kluczy naraz: osobny dla poczty firmowej, newslettera i sklepu. Nazwę selektora zna odbiorca wiadomości, bo stoi w nagłówku s=. DNS nie udostępnia jednak listy poddomen, więc narzędzie sprawdzające samą domenę nie ma skąd jej wziąć. Może tylko próbować najczęściej spotykanych nazw. Gdy Twój dostawca używa nietypowego selektora, skan nie znajdzie klucza, mimo że poczta jest podpisana. Audytor pisze wtedy, że nie wykrył klucza wśród typowych selektorów, a nie, że DKIM brakuje. Dlatego przy takim wyniku sprawdź nagłówki prawdziwej wiadomości (niżej) albo wpisz selektor z panelu dostawcy.
Długość klucza i algorytmy
- RFC 8301 nakazuje nadawcom używać kluczy RSA o długości co najmniej 1024 bitów i zaleca co najmniej 2048 bitów. Algorytm rsa-sha1 jest zakazany; podpisy rsa-sha1 uznaje się za niepoprawne. Używaj rsa-sha256.
- Google wymaga klucza co najmniej 1024-bitowego przy wysyłce do kont Gmail i zaleca 2048 bitów, o ile dostawca domeny to obsługuje. Yahoo także wymaga minimum 1024 bitów.
- Klucz 2048-bitowy zapisany w base64 ma ponad 255 znaków, a pojedynczy ciąg znaków w rekordzie TXT ma limit 255. Dlatego rekord dzieli się na kilka ciągów, a odbiorca łączy je bez odstępów (RFC 6376, sekcja 3.6.2.2). Panele DNS robią to różnie, stąd częsty błąd opisany niżej.
- Klucze 4096-bitowe mogą nie mieścić się w pakiecie odpowiedzi UDP o rozmiarze 512 bajtów (RFC 6376, sekcja 3.3.3), więc zwykle nie ma powodu ich stosować.
- RFC 8463 dodaje algorytm Ed25519-SHA256 z krótkim kluczem (44 znaki base64). Nie każdy odbiorca go obsługuje, więc dla małej firmy RSA 2048 bitów pozostaje prostszym wyborem.
Rotacja kluczy
Klucz, który nie zmienia się latami, jest większym ryzykiem po ewentualnym wycieku. Bezpieczna kolejność: opublikuj nowy klucz pod nowym selektorem, potem przełącz podpisywanie na nowy klucz, a stary rekord zostaw na rozsądny czas, żeby poczta już w drodze dała się zweryfikować. Dopiero wtedy usuń stary rekord albo wpisz w nim pustą wartość p=. Przy usługach zarządzanych (Google Workspace, Microsoft 365) rotację robi się w panelu dostawcy. RFC 6376 nie podaje terminu rotacji.
DKIM, SPF i DMARC
SPF sprawdza serwer nadawcy, DKIM podpis wiadomości, a DMARC łączy je z adresem w polu "Od". DMARC jest spełniony, gdy podpis DKIM jest poprawny, a domena z tagu d= pasuje do domeny z pola "Od" (w trybie domyślnym wystarczy ta sama domena główna). Ma to praktyczne skutki:
- Podpis poprawny, ale złożony domeną dostawcy (np.
d=dostawca-poczty.com), zalicza DKIM, ale nie daje wyrównania dla DMARC. Poczta przejdzie DMARC tylko dzięki SPF, a ten łatwo traci ważność, gdy wiadomość jest przekazywana dalej. Wiadomości przekazane zwykle zachowują podpis DKIM, o ile nikt nie zmienił treści. - Dlatego w usługach zewnętrznych (newsletter, sklep, CRM) włącz podpis własną domeną, nie domyślną domeną dostawcy.
Opis działania DMARC: poradnik DMARC, a SPF: poradnik SPF.
Co wymagają Gmail, Yahoo i Microsoft
- Google: każdy nadawca do kont Gmail ma ustawić SPF lub DKIM. Nadawcy powyżej 5000 wiadomości dziennie do Gmaila muszą mieć SPF i DKIM oraz DMARC (polityka może być none), a domena z pola "Od" musi pasować do domeny SPF lub DKIM. Zaostrzone zasady dla dużych nadawców obowiązują od 1 lutego 2024 r.
- Yahoo: minimum to SPF lub DKIM; nadawcy masowi muszą mieć oba, a także DMARC z polityką co najmniej p=none, który przechodzi. Strona Yahoo nie podaje progu liczbowego dla nadawcy masowego.
- Microsoft (Outlook.com, hotmail.com, live.com): od maja 2025 r. domeny wysyłające ponad 5000 wiadomości dziennie muszą przechodzić SPF i DKIM oraz mieć DMARC z polityką co najmniej p=none, wyrównany z SPF lub DKIM. Wiadomości niespełniające wymagań trafiają do folderu Wiadomości-śmieci (Junk) po 5 maja 2025 r.; Microsoft zapowiada, że później mogą być odrzucane z błędem 550 5.7.515. Termin odrzucania nie został podany.
Mała firma zwykle wysyła mniej niż 5000 wiadomości dziennie, ale reguły o podpisie i tak dotyczą jej poczty w praktyce, bo brak DKIM obniża zaufanie filtrów. Więcej o poczcie w spamie: poczta w spamie.
Jak sprawdzić podpis w wiadomości
Wyślij wiadomość na konto Gmail i w menu wiadomości wybierz opcję pokazującą jej oryginał. Szukaj dwóch nagłówków.
DKIM-Signature: v=1; a=rsa-sha256; d=twojafirma.pl; s=poczta2026; h=from:to:subject:date; bh=...; b=...
d=to domena podpisująca,s=to selektor. Rekord szukany w DNS to s._domainkey.d, czyli tu poczta2026._domainkey.twojafirma.pl.a=to algorytm; powinno być rsa-sha256.h=to lista podpisanych nagłówków; musi zawierać from.
Drugi nagłówek to Authentication-Results, dopisywany przez serwer odbiorcy. Szukaj w nim fragmentu dkim=pass header.d=twojafirma.pl. Gdy zamiast pass widzisz fail, neutral albo none, powód bywa podany obok (np. body hash did not verify, key not found). Jeśli header.d to domena dostawcy zamiast Twojej, podpis nie jest wyrównany z Twoim adresem "Od".
Najczęstsze błędy
- Proxy Cloudflare na rekordzie CNAME. Rekordy DKIM w Cloudflare muszą mieć status "tylko DNS" (szara chmurka). Z włączonym proxy odbiorca nie dostaje rekordu dostawcy i klucz nie zostaje znaleziony. Opis: SPF, DKIM i DMARC w Cloudflare.
- Klucz ucięty przy wklejaniu. Długi rekord TXT wklejony do panelu bez podziału na ciągi albo z dodatkową spacją, nowym wierszem czy cudzysłowem w środku daje błąd "key not found" lub "bad signature". Porównaj rekord ze skopiowaną wartością i nie edytuj klucza ręcznie.
- Stary selektor po zmianie dostawcy. Po przeniesieniu poczty zostają rekordy poprzedniego dostawcy, a nowy dostawca podpisuje innym selektorem, który nie został dodany do DNS. Usuń stare rekordy dopiero po sprawdzeniu, że nowy podpis przechodzi.
- Podpis domeną dostawcy zamiast własną. DKIM przechodzi, ale DMARC go nie uznaje, bo domena z
d=nie pasuje do pola "Od". Włącz w panelu usługi podpis własną domeną. - Dwie usługi z jednym selektorem. Dwa rekordy pod tą samą nazwą z różnymi kluczami powodują losowe porażki. Każda usługa powinna mieć własny selektor.
- Włączony DKIM tylko w poczcie firmowej. Newsletter, faktury ze sklepu i formularz na stronie wysyłają osobno i każdy trzeba podpisać.
Jak włączyć DKIM
- W panelu dostawcy poczty znajdź ustawienia podpisu DKIM i wygeneruj klucz. Wybierz 2048 bitów, jeśli dostawca daje wybór.
- Dodaj w DNS rekord, który panel pokazuje (TXT albo CNAME), dokładnie w podanej nazwie i wartości.
- Po zmianie DNS poczekaj na propagację (zwykle minuty, czasem kilka godzin), a potem włącz podpisywanie w panelu.
- Wyślij wiadomość na konto Gmail i sprawdź
dkim=passz własną domeną wheader.d. - Powtórz dla każdej usługi, która wysyła pocztę z Twoją domeną, a potem opublikuj DMARC.
Instrukcje krok po kroku: Google Workspace, Microsoft 365, Cloudflare, home.pl, nazwa.pl, OVH, cyber-folks, Zenbox, LH.pl, Hostinger.
Cały stan poczty swojej domeny sprawdzisz w darmowym audycie. Rekord DMARC przygotuje generator DMARC, rekord SPF generator SPF, a opublikowany DMARC sprawdzisz narzędziem DMARC.
Źródła
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: rfc-editor.org/rfc/rfc6376
- RFC 8301, Cryptographic Algorithm and Key Usage Update to DKIM: rfc-editor.org/rfc/rfc8301
- RFC 8463, A New Cryptographic Signature Method for DKIM (Ed25519): rfc-editor.org/rfc/rfc8463
- Google, wymagania dla nadawców: support.google.com/a/answer/81126
- Yahoo Sender Hub, najlepsze praktyki: senders.yahooinc.com/best-practices
- Microsoft, nowe wymagania Outlook.com dla nadawców wysyłających dużo poczty (2025): techcommunity.microsoft.com