DKIM "No Key for Signature": naprawa selektora i rotacji (2026)

Opublikowano 2026-07-08

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

“No key for signature” oznacza, że odbiorca odpytał rekord DNS, na który wskazuje Twój podpis DKIM — selector._domainkey.yourdomain — i nie znalazł klucza: nigdy nie został opublikowany lub został usunięty w trakcie rotacji. Opublikuj selektor, którego faktycznie używa Twój podpisujący. Tylko 10 092 481 domen — 3,87% — wypełnia triadę SPF+DKIM+DMARC, zgodnie ze spisem Defaults.Exposed obejmującym 261 086 232 ocenionych domen.

Naprawa to jeden rekord DNS, znaleziony w jednym nagłówku. Odczytaj tagi s= i d= z prawdziwego nagłówka DKIM-Signature, żeby dowiedzieć się, jakim selektorem jest podpisywana Twoja poczta, opublikuj (lub napraw) ten dokładny rekord i preferuj delegację CNAME, żeby dostawca rotował klucze za Ciebie. Następnie rotuj według planu działania poniżej — ten błąd zazwyczaj oznacza, że ktoś usunął stary selektor za wcześnie.

Co oznacza „dkim no key for signature”?

Każdy podpis DKIM niesie dwa tagi mówiące odbiorcy, gdzie pobrać klucz publiczny: d= (domena podpisująca) i s= (selektor). Odbiorca odpytuje jedną nazwę DNS zbudowaną z nich — s._domainkey.d — o klucz. „No key for signature” oznacza, że to zapytanie zwróciło pustą odpowiedź: podpis istnieje, ale klucz, który nazywa, nie.

Sformułowanie pojawia się w nagłówkach Authentication-Results i raportach zbiorczych DMARC — dokładne sformułowanie różni się w zależności od odbiorcy, ale ważne są dwa warianty:

Ciąg wynikowy (fragment, powszechnie obserwowany)	Co się faktycznie stało	Przejściowy?
`dkim=temperror (no key for signature)`	Zapytanie DNS nie powiodło się lub przekroczyło limit czasu — odbiorca w ogóle nie uzyskał odpowiedzi	Tak — ponowne próby często przechodzą; badaj tylko jeśli powtarza się
`dkim=permerror (no key for signature)`	Zapytanie DNS powiodło się i odpowiedź brzmiała „brak takiego rekordu” — selektor naprawdę nie ma klucza	Nie — rekord brakuje dopóki go nie opublikujesz

Jednorazowy temperror to kaprys DNS. Permerror — lub temperror powtarzający się przez dni i u wielu odbiorców — oznacza, że rekord, na który wskazuje podpis, nie ma klucza w Twojej strefie. To jest ten przewodnik.

Konsekwencja: niemożliwy do zweryfikowania podpis liczy się jako brak DKIM w ogóle, więc DMARC wraca do samego SPF — a SPF psuje się przy przekazywaniu. Jeśli podpis jest obecny, ale nieprawidłowy, a nie brakujący (hash ciała, zniekształcony klucz), to inny błąd — patrz „DKIM signature not valid”.

Jak znaleźć, jakim selektorem jest podpisywana moja poczta?

Nie zgaduj z dokumentacji dostawcy — odczytaj to z prawdziwej wiadomości:

Wyślij wiadomość z dotkniętego systemu do skrzynki, którą kontrolujesz (adres Gmail działa dobrze).
Otwórz źródło surowe („Pokaż oryginał” w Gmail, „Wyświetl źródło wiadomości” w Outlook).
Znajdź nagłówek DKIM-Signature: i odczytaj dwa tagi: s= to selektor, d= to domena podpisująca. Przykład ilustracyjny: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Rekord, którego szuka odbiorca, to s._domainkey.d — tutaj mail2026._domainkey.yourdomain.com. Sprawdź to sam: dig TXT mail2026._domainkey.yourdomain.com +short. Pusta odpowiedź = błąd jest realny dla każdego odbiorcy.
Powtórz dla każdego systemu wysyłkowego. Wiadomość może nieść wiele podpisów DKIM — dostawca skrzynki, narzędzie do newsletterów, helpdesk — każdy z własną parą s=/d= i rekordem. Napraw nieprzechodzący i zwróć uwagę na jego d=: tylko podpis, którego d= pasuje do Twojej domeny From, pomaga DMARC.

Dlaczego rekord selektora nie ma klucza?

Cztery przyczyny odpowiadają za niemal wszystkie te błędy — sprawdzaj je w tej kolejności:

Nigdy nie został opublikowany. Podpisujący został włączony (lub domyślnie włączony) z selektorem, którego nikt nie dodał do DNS. Powszechne przy nowych narzędziach i bramkach, które podpisują nieoczekiwanie.
Został usunięty w trakcie rotacji. Ktoś „posprzątał” stary selektor, gdy wiadomości podpisane nim były nadal w tranzycie, kolejkowane do ponowienia lub oczekujące na przekazanie. Ta poczta jest już podpisana z s=old; usunięcie old._domainkey retroaktywnie psuje każdą z nich.
Twój panel DNS zniekształcił cel CNAME. Wielu dostawców deleguje przez CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), a wiele paneli DNS cicho dołącza Twoją strefę do celu — przechowując s1.domainkey.u123.esp.com.yourdomain.com, co nie rozwiązuje się do niczego. Sprawdź cel: dig CNAME s1._domainkey.yourdomain.com +short. Ta sama pułapka kąsa podczas migracji narzędzi — patrz DKIM przestało działać po zmianie narzędzi poczty.
Dostawca zrotował, Twoja strefa nie. Klucz dostawcy wklejony jako statyczny rekord TXT (zamiast jego CNAME) jest osierocony przez zaplanowaną rotację — podpisujący przechodzi do selektora, którego nigdy nie opublikowałeś. Tylko 51,84% z 261 milionów domen w spisie ma możliwy do odkrycia klucz DKIM w czasie skanowania (dane z 2026-06-29).

Jak naprawić „no key for signature”?

Uruchom bezpłatne skanowanie na defaults.exposed przed dotykaniem DNS. Odczytuje Twoje aktywne rekordy DKIM, SPF i DMARC i pokazuje, co faktycznie widzą odbiorcy — w tym czy selektor się rozwiązuje i czy cel CNAME nie został zniekształcony.
Opublikuj selektor, którego faktycznie używa podpisujący — wartość s= z nagłówka, a nie tę ze starego planu. Pobierz rekord z konsoli administracyjnej dostawcy (konfiguracja DKIM Google Workspace · konfiguracja DKIM Microsoft 365) i dodaj go dokładnie pod s._domainkey.yourdomain.com.
Preferuj delegację CNAME zamiast wklejania klucza TXT. Jeśli dostawca oferuje CNAME DKIM, użyj ich: klucz żyje w ich strefie, więc rotują go bez Twojego dotykania DNS — przyczyna 4 staje się niemożliwa. Platformy newsletterowe prawie wszystkie działają w ten sposób; patrz wiadomości Mailchimp/Brevo/Klaviyo nie przechodzą DMARC.
Sprawdź poza swoim panelem. dig TXT s._domainkey.yourdomain.com +short (lub dig CNAME … dla delegowanych selektorów) z maszyny poza Twoją siecią. Panel pokazujący rekord nic nie udowadnia, jeśli strefa serwuje coś innego.
Ponów skanowanie i wyślij wiadomość testową ponownie. Authentication-Results powinien teraz zawierać dkim=pass. Następnie zajmij się wszystkim innym, co zaznacza skanowanie na stronie naprawy DKIM — podpis przechodzący, który nie wyrównuje się z domeną From, nadal nie przechodzi DMARC.

Jak rotować klucze DKIM bez powodowania tego błędu?

Rotacja to miejsce, gdzie działające konfiguracje się psują. Zasada, która to zapobiega: selektor jest usuwany dopiero gdy ostatnia wiadomość nim podpisana odpłynęła — nigdy przy przełączaniu. Podpisana poczta żyje dłużej niż myślisz: kolejki ponowień działają przez dni, a przekazywane wiadomości są weryfikowane ponownie za każdym razem, gdy się przemieszczają.

Krok	Działanie	Brama przed następnym krokiem
1. Dodaj	Opublikuj nowy selektor (`s2._domainkey…`) obok starego	`dig` potwierdza rozwiązywanie z zewnątrz
2. Przełącz	Skieruj podpisującego na nowy selektor	Wiadomość testowa pokazuje `s=s2` i `dkim=pass`
3. Poczekaj	Zostaw stary selektor opublikowany dopóki ruch w locie, kolejkowany i przekazywany odpłynie	≥ 7 dni; obserwuj raporty zbiorcze DMARC, aż stary selektor przestanie się pojawiać
4. Wycofaj	Usuń stary klucz — lub lepiej, ponownie go opublikuj z pustym tagiem `p=`: „wycofany”, a nie „nigdy nie istniał”	Nigdy nie zaczynaj tego przy przełączaniu — przedwczesne usunięcie to przyczyna nr 1 „no key for signature”

Przy delegacji CNAME Twój dostawca uruchamia ten plan w swojej własnej strefie i nigdy tego nie widzisz — to najsilniejszy argument za delegacją.

Często zadawane pytania

Czy „no key for signature” to temperror czy permerror? Oba ciągi istnieją: temperror to wyszukiwanie DNS, które nie powiodło się lub przekroczyło limit czasu — przejściowe, często znika przy ponowieniu — podczas gdy permerror oznacza, że DNS odpowiedział „brak takiego rekordu”. Temperror powtarzający się u wielu odbiorców zazwyczaj okazuje się też naprawdę brakującym rekordem. Sprawdź za pomocą dig i ufaj odpowiedzi, nie etykiecie.

Czy ten błąd oznacza, że ktoś podszywa się pod moją domenę? Nie — spoofer nie podpisywałby Twoim selektorem. Oznacza, że Twoja własna poczta niesie podpis, którego odbiorcy nie mogą zweryfikować, więc liczy się jako niepodpisana i DMARC opiera się wyłącznie na SPF. Pełne, wyrównane uwierzytelnienie jest rzadkie: tylko 10 092 481 z 261 086 232 domen (3,87%) wypełniło triadę SPF+DKIM+DMARC w spisie Defaults.Exposed (dane z 2026-06-29).

Czy mogę po prostu usunąć stary selektor gdy nowy działa? Nie od razu. Wiadomości nim podpisane nadal są w kolejkach ponowień i ścieżkach przekazywania; usunięcie klucza retroaktywnie je psuje. Trzymaj stary rekord co najmniej tydzień, obserwuj raporty DMARC, aż stary selektor przestanie się pojawiać, a następnie go wycofaj — najlepiej z pustym p= zamiast usunięciem.

Checker dostawcy mówi, że DKIM jest skonfigurowany, ale odbiorcy nadal raportują brak klucza. Jak to? Prawie zawsze pułapka celu CNAME: Twój panel DNS dołączył Twoją strefę do celu (…esp.com.yourdomain.com), więc rekord istnieje, ale wskazuje w pustkę. dig CNAME selector._domainkey.yourdomain.com +short pokazuje przechowywany cel dosłownie — porównaj go znak po znaku z tym, o co prosił dostawca.

Wyślij właścicielowi raport

Jeśli naprawiasz to dla klienta lub pracodawcy, zamknij pętlę z dowodem. Ponów bezpłatne skanowanie gdy selektor się rozwiązuje i prześlij oceniony raport właścicielowi firmy: z datą, w prostym języku, DKIM teraz weryfikuje. To artefakt, który będzie mu potrzebny przy przedłużeniu ubezpieczenia cybernetycznego i kolejnym kwestionariuszu bezpieczeństwa dostawcy — dowód działającej kontroli, nie tylko zamkniętego zgłoszenia.

Sprawdź swój DKIM bezpłatnie

Sprawdź, czy Twoje selektory się rozwiązują — i co dokładnie naprawić — prywatnie i tylko dla właściciela.

Sprawdź swoją domenę → · „DKIM signature not valid” → · Napraw DKIM → · Skonfiguruj DKIM w Google Workspace → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.