DKIM „No Key for Signature": Corecții pentru selector și rotație (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

„No key for signature” înseamnă că receptorul a interogat înregistrarea DNS la care pointează semnătura DKIM — selector._domainkey.yourdomain — și nu a găsit nicio cheie: nu a fost niciodată publicată sau a fost ștearsă în mijlocul rotației. Publicați selectorul pe care îl folosește semnatarul. Doar 10,092,481 domenii — 3.87% — completează triada SPF+DKIM+DMARC, conform recensământului Defaults.Exposed pe 261,086,232 domenii clasificate.

Remedierea este o singură înregistrare DNS, găsită într-un singur antet. Citiți tagurile s= și d= dintr-un antet DKIM-Signature real pentru a afla cu ce selector este semnat e-mailul dvs., publicați (sau reparați) acea înregistrare exactă și preferați delegarea CNAME astfel încât furnizorul să rotească cheile pentru dvs. Apoi rotiți după planul de mai jos — această eroare înseamnă de obicei că cineva a șters un selector vechi prea devreme.

Ce înseamnă „dkim no key for signature”?

Fiecare semnătură DKIM poartă două taguri care îi spun receptorului de unde să preia cheia publică: d= (domeniu de semnare) și s= (selector). Receptorul interoghează un nume DNS construit din acestea — s._domainkey.d — pentru cheie. „No key for signature” înseamnă că interogarea a revenit goală: semnătura există, dar cheia pe care o numește nu.

Formularea apare în antetele Authentication-Results și în rapoartele agregate DMARC — formularea exactă variază în funcție de receptor, dar două variante contează:

Șir de rezultat (fragment, observat pe scară largă)	Ce s-a întâmplat de fapt	Tranzitoriu?
`dkim=temperror (no key for signature)`	Interogarea DNS a eșuat sau a expirat — receptorul nu a putut obține un răspuns	Da — reîncercările trec deseori; investigați doar dacă persistă
`dkim=permerror (no key for signature)`	Interogarea DNS a reușit și răspunsul a fost „fără înregistrare” — selectorul este cu adevărat absent	Nu — înregistrarea lipsește până o publicați

Un temperror unic este DNS aleatoriu. Un permerror — sau un temperror care se repetă pe zile și receptori — înseamnă că înregistrarea la care pointează semnătura nu se află în zona dvs. Acesta este ghidul.

Consecința: o semnătură neverificabilă contează ca fără DKIM, deci DMARC cade înapoi numai pe SPF — iar SPF se strică la redirecționare. Dacă semnătura este prezentă dar invalidă mai degrabă decât lipsă (hash al corpului, cheie denaturată), acesta este un eșec diferit — consultați „DKIM signature not valid”.

Cum găsesc cu ce selector este semnat e-mailul meu?

Nu ghiciți din documentația furnizorului — citiți-o dintr-un mesaj real:

Trimiteți un mesaj de la sistemul afectat la o căsuță poștală pe care o controlați (o adresă Gmail funcționează bine).
Deschideți sursa brută („Show original” în Gmail, „View message source” în Outlook).
Găsiți antetul DKIM-Signature: și citiți două taguri: s= este selectorul, d= este domeniul de semnare. Un exemplu ilustrativ: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Înregistrarea pe care receptorul o interoghează este s._domainkey.d — aici, mail2026._domainkey.yourdomain.com. Verificați singuri: dig TXT mail2026._domainkey.yourdomain.com +short. Răspuns gol = eroarea este reală pentru fiecare receptor.
Repetați per sistem de trimitere. Un mesaj poate purta multiple semnături DKIM — furnizor de căsuță poștală, instrument de newsletter, helpdesk — fiecare cu propria pereche s=/d= și înregistrare. Reparați-o pe cea care eșuează și notați d=-ul: numai o semnătură al cărei d= se potrivește cu domeniul dvs. From ajută DMARC.

De ce lipsește înregistrarea selectorului?

Patru cauze explică aproape toate aceste erori — verificați-le în această ordine:

Nu a fost niciodată publicată. Semnatarul a fost activat (sau activat implicit) cu un selector pe care nimeni nu l-a adăugat la DNS. Frecvent cu instrumente noi și gateway-uri care semnează neașteptat.
A fost ștereasă în mijlocul rotației. Cineva a „curățat” selectorul vechi în timp ce mesajele semnate cu el erau încă în tranzit, în coada de reîncercare sau așteptând redirecționarea. Acel e-mail este deja semnat cu s=old; ștergerea old._domainkey strică retroactiv fiecare dintre acele mesaje.
Interfața UI DNS a denaturat o țintă CNAME. Mulți furnizori deleghează prin CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), iar multe panouri DNS adaugă tăcut zona dvs. la țintă — stocând s1.domainkey.u123.esp.com.yourdomain.com, care se rezolvă la nimic. Verificați ținta: dig CNAME s1._domainkey.yourdomain.com +short. Aceeași capcană muște în timpul migrărilor de instrumente — consultați DKIM eșuează după schimbarea instrumentelor de e-mail.
Furnizorul a rotit, zona dvs. nu. O cheie de furnizor lipită ca înregistrare TXT statică (în loc de CNAMEs-urile lor) este orfanizată de rotația lor programată — semnatarul se mută la un selector pe care nu l-ați publicat niciodată. Doar 51.84% din cele 261 milioane de domenii din recensământ prezintă o cheie DKIM descoperabilă la momentul scanării (date din 2026-06-29).

Cum remediez „no key for signature”?

Rulați scanarea gratuită la defaults.exposed înainte de a atinge DNS-ul. Citește înregistrările dvs. DKIM, SPF și DMARC active și arată ce văd receptorii — inclusiv dacă selectorul se rezolvă și dacă o țintă CNAME a fost denaturată.
Publicați selectorul pe care îl folosește semnatarul — valoarea s= din antet, nu cea dintr-un manual vechi. Obțineți înregistrarea din consola de administrare a furnizorului dvs. (configurare DKIM Google Workspace · configurare DKIM Microsoft 365) și adăugați-o exact la s._domainkey.yourdomain.com.
Preferați delegarea CNAME față de lipirea unei chei TXT. Dacă furnizorul dvs. oferă CNAMEs DKIM, folosiți-le: cheia se află în zona lor, deci ei o rotesc fără ca dvs. să mai atingeți DNS-ul — cauza 4 devine imposibilă. Platformele de newsletter funcționează aproape toate astfel; consultați e-mailuri Mailchimp/Brevo/Klaviyo care eșuează DMARC.
Verificați din afara panoului dvs. dig TXT s._domainkey.yourdomain.com +short (sau dig CNAME … pentru selectorii delegați) de pe o mașină din afara rețelei dvs. Panoul care arată înregistrarea nu dovedește nimic dacă zona servește altceva.
Re-scanați și re-trimiteți mesajul de test. Authentication-Results ar trebui să citească acum dkim=pass. Apoi rezolvați orice altceva semnalează scanarea pe pagina corectați DKIM — o semnătură care trece dar nu se aliniază cu domeniul dvs. From eșuează totuși DMARC.

Cum rotesc cheile DKIM fără a provoca această eroare?

Rotația este locul unde configurările care funcționează se strică. Regula care o previne: un selector este șters numai după ce ultimul mesaj semnat cu el s-a drenat — niciodată la comutare. E-mailul semnat trăiește mai mult decât credeți: cozile de reîncercare rulează zile, iar mesajele redirecționate sunt re-verificate ori de câte ori se deplasează.

Pas	Acțiune	Poartă înainte de pasul următor
1. Adăugați	Publicați noul selector (`s2._domainkey…`) alături de cel vechi	`dig` confirmă că se rezolvă din exterior
2. Comutați	Pointați semnatarul la noul selector	Mesajul de test arată `s=s2` și `dkim=pass`
3. Așteptați	Lăsați vechiul selector publicat cât timp traficul în zbor, în coadă și redirecționat se drenează	≥ 7 zile; urmăriți rapoartele agregate DMARC până când selectorul vechi nu mai apare
4. Retragere	Eliminați cheia veche — sau mai bine, re-publicați-o cu un tag `p=` gol: „retras”, nu „niciodată existat”	Nu porniți niciodată aceasta la comutare — ștergerea prematură este cauza #1 a „no key for signature”

Cu delegarea CNAME, furnizorul dvs. rulează exact acest plan în propria zonă și nu îl vedeți niciodată — cel mai puternic argument pentru delegare.

Întrebări frecvente

„No key for signature” este un temperror sau un permerror? Ambele șiruri există: temperror este o interogare DNS care a eșuat sau a expirat — tranzitorie, deseori dispărută la reîncercare — în timp ce permerror înseamnă că DNS a răspuns „fără înregistrare”. Un temperror care se repetă la receptori se dovedește de obicei a fi și o înregistrare cu adevărat lipsă. Verificați cu dig și aveți încredere în răspuns, nu în etichetă.

Înseamnă această eroare că cineva vă falsifică domeniul? Nu — un falsificator nu ar semna cu selectorul dvs. Înseamnă că propriul e-mail poartă o semnătură pe care receptorii nu o pot verifica, deci contează ca nesemnat și DMARC se bazează numai pe SPF. Autentificarea completă și aliniată este rară: doar 10,092,481 din 261,086,232 domenii (3.87%) au completat triada SPF+DKIM+DMARC în recensământul Defaults.Exposed (date din 2026-06-29).

Pot șterge selectorul vechi odată ce cel nou funcționează? Nu imediat. Mesajele semnate cu el sunt încă în cozile de reîncercare și căile de redirecționare; ștergerea cheii le strică retroactiv. Păstrați înregistrarea veche cel puțin o săptămână, urmăriți rapoartele DMARC până când selectorul vechi nu mai apare, apoi retrageți-l — ideal cu un p= gol mai degrabă decât ștergere.

Verificatorul furnizorului spune că DKIM este configurat, dar receptorii raportează în continuare nicio cheie. Cum? Aproape întotdeauna capcana țintei CNAME: panoul DNS a adăugat zona dvs. la țintă (…esp.com.yourdomain.com), deci înregistrarea există dar pointează nicăieri. dig CNAME selector._domainkey.yourdomain.com +short arată ținta stocată verbatim — comparați-o caracter cu caracter cu ceea ce a cerut furnizorul.

Trimiteți proprietarului raportul

Dacă reparați asta pentru un client sau angajatorul dvs., încheiați cu dovezi. Re-rulați scanarea gratuită odată ce selectorul se rezolvă și trimiteți raportul clasificat proprietarului afacerii: datat, limbaj simplu, DKIM verificând acum. Acesta este artefactul de care vor avea nevoie pentru reînnoirea asigurării cibernetice și pentru următorul chestionar de securitate al furnizorilor — dovada unui control funcțional, nu doar un tichet închis.

Verificați gratuit DKIM-ul

Vedeți dacă selectorii dvs. se rezolvă — și exact ce trebuie corectat — privat și numai pentru proprietar.

Verificați domeniul → · „DKIM signature not valid” → · Corectați DKIM → · Configurați DKIM pe Google Workspace → · Doar date agregate. Date stocate și procesate în UE.