'DKIM Signature Not Valid' — przyczyny w kolejności sprawdzania (2026)

Opublikowano 2026-07-08

Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenionych domen. Zobacz jak oceniamy.

„DKIM signature not valid” ma pięć częstych przyczyn, które najlepiej sprawdzać w kolejności: treść zmodyfikowana w tranzycie, obcięty rekord klucza, opublikowany klucz niezgodny z podpisującym, zły selektor i krucha kanonizacja. Tylko 10 092 481 z 261 086 232 ocenionych domen (3,87%) posiada pełną triadę SPF + DKIM + wymuszający DMARC, zgodnie ze spisem Defaults.Exposed (2026-06-29).

Kolejność naprawy ma znaczenie, bo najczęstsza przyczyna w ogóle nie tkwi w Twoim DNS. Najpierw sprawdź, co zmodyfikowało wiadomość w tranzycie, a następnie idź do środka: integralność rekordu klucza, czy pasuje do tego, czym faktycznie podpisuje Twój serwer pocztowy, selektor i wreszcie ustawienia podpisywania. Większość nieprawidłowych podpisów naprawia się w kroku pierwszym lub drugim.

Co tak naprawdę oznacza „DKIM signature not valid”?

Każda wiadomość podpisana DKIM niesie nagłówek DKIM-Signature wskazujący domenę (d=), selektor (s=), hash ciała wiadomości (bh=) i podpis kryptograficzny ponad hashem ciała i wybranymi nagłówkami (b=). Odbiorca pobiera Twój klucz publiczny z DNS pod <selector>._domainkey.<domain>, przelicza oba hashe i sprawdza podpis (RFC 6376). „Signature not valid” to język narzędzi sprawdzających i nagłówków dla: ta weryfikacja się odbyła i nie powiodła — klucz został znaleziony, ale matematyka nie wyszła.

Ta ostatnia klauzula to złoto diagnostyczne. Weryfikator, który nie może znaleźć klucza, mówi coś innego — zazwyczaj nagłówek jak dkim=fail (no key for signature) — i to jest problem z selektorem, opisany w DKIM „no key for signature” — naprawa selektora i rotacji. A weryfikator, który przelicza inny hash ciała, zazwyczaj mówi to wprost: body hash did not verify — Microsoft raportuje to jako dkim=fail (body hash did not verify), podczas gdy Gmail często renderuje tę samą diagnozę jako dkim=neutral (body hash did not verify). W każdym razie wskazuje to na modyfikację treści, opisaną w „body hash did not verify” — co zmieniło Twoją wiadomość. Odczytaj dokładne sformułowanie w nagłówku Authentication-Results przed dotykaniem czegokolwiek: mówi Ci, którą z pięciu przyczyn trzymasz.

Osiągnięcie poprawnego stanu jest rzadkie: tylko 51,84% ocenionych domen publikuje w ogóle możliwy do odkrycia klucz DKIM w DNS, zgodnie ze spisem Defaults.Exposed, i tylko 3,87% z 261 milionów ocenionych domen łączy SPF, DKIM i wymuszającą politykę DMARC — konfigurację, którą reguły masowych nadawców teraz zakładają. Obraz etap po etapie jest w modelu dojrzałości wdrożenia SPF.

Jakie są pięć przyczyn w kolejności?

#	Przyczyna	Sygnał ostrzegawczy	Rozwiązanie
1	Treść zmodyfikowana w tranzycie — stopki bramki, zastrzeżenia prawne, tagi tematu listy mailingowej	`body hash did not verify` w Authentication-Results; poczta zewnętrzna nie przechodzi, bezpośrednia tak	Podpisuj po modyfikacji lub zatrzymaj modyfikowanie — patrz przewodnik body-hash
2	Obcięty lub zniekształcony długi klucz	Opublikowany `p=` jest wyraźnie krótszy niż wygenerowany klucz; każdy odbiorca nie przechodzi	Ponownie opublikuj klucz 2048-bitowy jako prawidłowo podzielone ciągi TXT
3	Opublikowany klucz niezgodny z podpisującym	Błędy zaczynają się zaraz po rotacji, migracji lub zmianie dostawcy	Skopiuj ponownie aktualny klucz publiczny od podpisującego; preferuj delegację CNAME
4	Zły lub brakujący selektor	`no key for signature` — samo wyszukiwanie nie powodzi się	Opublikuj selektor, którego faktycznie używa podpisujący — patrz przewodnik selektorów
5	Krucha kanonizacja lub tag `l=`	Sporadyczne błędy przy trywialnie sformatowanych wiadomościach	`c=relaxed/relaxed`; usuń `l=` całkowicie

Przyczyna 1 jest wyróżniona, bo psuje podpisy na wiadomościach, które były podpisane doskonale. Bramka bezpieczeństwa dołącza zastrzeżenie, stopka zgodności jest stemplowana po podpisaniu, lista mailingowa dodaje [listname] do tematu — ciało lub podpisane nagłówki się zmieniają, hashe już nie pasują, i podpis jest nieprawidłowy bez żadnej winy Twojego DNS. Jeśli błędy korelują z pocztą, która przeszła przez bramkę, listę lub skok archiwizacji, zacznij tam.

Jak naprawić „DKIM signature not valid”?

Uruchom bezpłatne skanowanie na defaults.exposed przed dotykaniem DNS. Pokazuje, czy Twój opublikowany rekord klucza jest obecny, poprawnie sformułowany i kompletny — oddzielając „Twój DNS jest zepsuty” (przyczyny 2–4) od „Twój DNS jest w porządku, wiadomość jest zmieniana” (przyczyna 1) w jednym kroku.
Odczytaj nagłówek Authentication-Results nieprzechodzącego komunikatu. body hash did not verify → przyczyna 1, idź do przewodnika body-hash — zwykłymi podejrzanymi są stopki bramki i zastrzeżenia, a naprawą jest podpisywanie po modyfikacji. no key for signature → przyczyna 4, idź do przewodnika selektora. Zwykły błąd podpisu → kontynuuj.
Sprawdź opublikowany klucz pod kątem obcięcia. Odszukaj <selector>._domainkey.<yourdomain> jako TXT (dig TXT selector._domainkey.example.com). 2048-bitowy klucz publiczny RSA jest dłuższy niż limit 255 znaków pojedynczego ciągu TXT, więc musi być opublikowany jako wiele cytowanych ciągów, które odbiorcy konkatenują — a webowe interfejsy dostawców DNS są znane z cichego obcinania wklejania, zniekształcania podziału lub wstrzykiwania białych znaków i cudzysłowów do wartości p=. Porównaj znak po znaku z kluczem wygenerowanym przez podpisującego; nasze przewodniki konfiguracji DKIM opisują specyfikę dla każdego dostawcy.
Potwierdź, że opublikowany klucz pasuje do podpisującego. Po rotacji klucza, migracji dostawcy lub ponownym podłączeniu ESP często zdarza się, że podpisujący trzyma nowy klucz prywatny, podczas gdy DNS nadal serwuje stary klucz publiczny — każdy podpis weryfikuje się względem złego klucza i nie przechodzi. Skopiuj ponownie aktualny rekord z konsoli administracyjnej dostawcy. Lepiej: gdzie dostawca oferuje delegację CNAME, używaj jej — dostawca rotuje klucze po swojej stronie i cała ta klasa błędów znika. I nigdy nie usuwaj starego selektora, dopóki ruch nim podpisany nie odpłynie.
Napraw ustawienia podpisywania, nie tylko rekord. Ustaw kanonizację na c=relaxed/relaxed, która toleruje przepakowywanie białych znaków i przepinanie nagłówków, które pośrednie serwery legalnie robią; kanonizacja simple nie przechodzi zmian, których człowiek nawet nie widzi. I nie używaj tagu l= długości ciała: miał on pozwalać na przechodzenie stopek, ale pozwala komukolwiek dołączać treść do Twojej podpisanej wiadomości bez niszczenia podpisu — to realny wektor ataku — i nadal nie przeżywa większości modyfikacji bramki. Brak l= to zarówno bezpieczniejszy, jak i bardziej niezawodny wybór.
Ponów skanowanie, a następnie sprawdź wyrównanie. Ważny podpis pomaga DMARC tylko jeśli domena d= wyrównuje się z Twoją domeną From — podpis weryfikujący się jako d=yourcompany.gappssmtp.com przechodzi DKIM i nadal nie przechodzi DMARC. Jeśli to Ty, patrz pułapka domyślnego podpisu, a następnie zajmij się wszystkim innym, co zaznacza skanowanie na stronie naprawy DKIM.

Często zadawane pytania

Czy „DKIM signature not valid” to to samo co „body hash did not verify”? Wiadomość o hashu ciała to jeden konkretny podprzypadek: ciało zmieniło się po podpisaniu (stopki, zastrzeżenia, przepisania list). „Signature not valid” to ogólny werdykt dla każdej nieudanej weryfikacji, w tym złych kluczy i zmian nagłówków — dlatego krok 2 powyżej to czytanie nagłówka, i dlaczego przypadek body-hash ma własny przewodnik.

Czy nieprawidłowy podpis DKIM oznacza, że moja poczta jest odrzucana? Nie sam w sobie — odbiorcy traktują zepsuty podpis jak brakujący. Szkoda dochodzi przez DMARC: jeśli SPF też nie przechodzi z wyrównaniem, wiadomość nie przechodzi DMARC i stosuje się Twoja opublikowana polityka. Według spisu z 2026-06-29, tylko 3,87% z 261 086 232 ocenionych domen posiada razem SPF, DKIM i wymuszającą politykę DMARC — ale Gmail i Microsoft teraz właśnie tego oczekują od nadawców, więc zepsuta noga DKIM kosztuje dostarczalność nawet przed odrzuceniem.

Czy powinienem używać klucza DKIM 1024-bitowego czy 2048-bitowego? 2048-bitowego — klucze 1024-bitowe są poniżej aktualnych zaleceń kryptograficznych i niektórzy odbiorcy je obniżają w ocenie. Haczyk jest czysto operacyjny: klucz 2048-bitowy nie mieści się w jednym 255-znakowym ciągu TXT, więc musi być prawidłowo podzielony (przyczyna 2 powyżej). Delegacja CNAME do dostawcy całkowicie omija problem podziału.

Mój DKIM przechodzi w checkerze, ale DMARC nadal nie przechodzi — jak to? Niemal na pewno wyrównanie: podpis weryfikuje się, ale jego domena d= (np. yourcompany.gappssmtp.com lub yourtenant.onmicrosoft.com) nie pasuje do Twojej domeny From, więc DMARC nie może go użyć. Włącz podpisywanie z własną domeną u dostawcy — pełny opis jest w przewodniku pułapki domyślnego podpisu.

Czy mogę po prostu wyłączyć DKIM, jeśli ciągle nie przechodzi? Nie — od mandatów dla masowych nadawców z 2024 r. Gmail i Yahoo wymagają DKIM dla nadawców wolumenu, a wymuszająca polityka DMARC realistycznie potrzebuje DKIM, bo samo SPF psuje się przy przekazywaniu. Napraw podpis; przyczyny powyżej są wszystkie naprawialne w jedno popołudnie.

Wyślij właścicielowi raport

Jeśli naprawiasz to dla klienta lub pracodawcy, zamknij pętlę z dowodem. Ponów bezpłatne skanowanie po zmianach i prześlij oceniony raport właścicielowi firmy: z datą, w prostym języku, DKIM pokazuje zielone. To artefakt, który będzie mu potrzebny przy przedłużeniu ubezpieczenia cybernetycznego i kolejnym kwestionariuszu bezpieczeństwa dostawcy — różnica między „naprawiłem coś w DNS” a udokumentowanym porównaniem przed i po, mówiącym, że domena uwierzytelnia swoją pocztę.

Sprawdź swoją domenę → · Przewodnik „Body hash did not verify” → · Napraw DKIM → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.