Defaults.Exposed › Remedieri › Guides

„Semnătură DKIM nevalidă" — Cauzele, în ordinea verificării (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.

„DKIM signature not valid” are cinci cauze comune, verificate cel mai bine în ordine: conținut modificat în tranzit, o înregistrare de cheie trunchiată, o cheie publicată care nu se potrivește cu semnatarul, selectorul greșit și canonicalizarea fragilă. Doar 10,092,481 din 261,086,232 domenii clasificate (3.87%) dețin triada completă SPF + DKIM + DMARC aplicat, conform recensământului Defaults.Exposed (2026-06-29).

Ordinea reparării contează deoarece cea mai comună cauză nu se află deloc în DNS-ul dvs. Verificați mai întâi ce a modificat mesajul în tranzit, apoi lucrați spre interior: integritatea înregistrării cheii, dacă se potrivește cu ce semnează cu adevărat serverul dvs. de e-mail, selectorul și în final setările de semnare. Cele mai multe semnături invalide sunt remediate la pasul unu sau doi.

Ce înseamnă de fapt „DKIM signature not valid”?

Fiecare mesaj semnat DKIM poartă un antet DKIM-Signature care numește un domeniu (d=), un selector (s=), un hash al corpului mesajului (bh=) și o semnătură criptografică peste hash-ul corpului plus antetele selectate (b=). Receptorul preia cheia dvs. publică din DNS la <selector>._domainkey.<domain>, recomputează ambele hash-uri și verifică semnătura (RFC 6376). „Signature not valid” este formularea verificatorului și antetului pentru: verificarea a rulat și a eșuat — cheia a fost găsită, dar calculele nu au ieșit corect.

Ultima clauză este aurul diagnostic. Un verificator care nu poate găsi cheia dvs. spune altceva — de obicei un antet precum dkim=fail (no key for signature) — și aceasta este o problemă de selector, acoperită în DKIM „no key for signature” — corecții pentru selector și rotație. Iar un verificator care recomputează un hash de corp diferit spune de obicei explicit: body hash did not verify — Microsoft îl raportează ca dkim=fail (body hash did not verify), în timp ce Gmail redă adesea același diagnostic ca dkim=neutral (body hash did not verify). În orice caz, indică modificarea conținutului, acoperită în „body hash did not verify” — ce a schimbat mesajul dvs.. Citiți formularea exactă din antetul Authentication-Results înainte de a atinge orice: vă spune care dintre cele cinci cauze o aveți.

A face asta corect este rar: doar 51.84% din domeniile clasificate publică o cheie DKIM descoperabilă în DNS, conform recensământului Defaults.Exposed, și doar 3.87% din 261 milioane de domenii clasificate combină SPF, DKIM și o politică DMARC aplicată — configurația pe care regulile expeditorului de masă o presupun acum. Imaginea etapă cu etapă se află în modelul de maturitate al adoptării SPF.

Care sunt cele cinci cauze, în ordine?

Cauza 1 este îngroșată deoarece strică semnăturile pe mesajele care au fost semnate perfect. Un gateway de securitate adaugă un disclaimer, un subsol de conformitate este aplicat după semnare, o listă de corespondență adaugă [listname] la subiect — corpul sau antetele semnate se schimbă, hash-urile nu se mai potrivesc și semnătura este invalidă fără nicio vină a DNS-ului dvs. Dacă eșecurile corelează cu e-mailul care a trecut printr-un gateway, o listă sau un hop de arhivare, începeți de acolo.

Cum remediez „DKIM signature not valid”?

1. Rulați scanarea gratuită la defaults.exposed înainte de a atinge DNS-ul. Arată dacă înregistrarea cheii dvs. publicată este prezentă, bine formată și completă — separând „DNS-ul dvs. este stricat” (cauzele 2–4) de „DNS-ul dvs. este în regulă, mesajul este schimbat” (cauza 1) într-un singur pas.
2. Citiți antetul Authentication-Results al unui mesaj care eșuează. body hash did not verify → cauza 1, mergeți la ghidul body-hash — suspecții obișnuiți sunt subsolurile de gateway și disclaimer-ele, iar remedierea este să semnați după modificare. no key for signature → cauza 4, mergeți la ghidul selectorului. Un eșec simplu de semnătură → continuați.
3. Verificați cheia publicată pentru trunchiere. Căutați <selector>._domainkey.<yourdomain> ca TXT (dig TXT selector._domainkey.example.com). O cheie publică RSA de 2048 de biți este mai lungă decât limita de 255 de caractere a unui singur șir TXT, deci trebuie publicată ca multiple șiruri între ghilimele pe care receptorii le concatenează — iar interfețele web ale furnizorilor DNS sunt notorii pentru trunchearea silențioasă a lipirii, denaturarea împărțirii sau injectarea de spații și ghilimele în valoarea p=. Comparați caracter cu caracter cu cheia generată de semnatarul dvs.; ghidurile noastre de configurare DKIM acoperă particularitățile per furnizor.
4. Confirmați că cheia publicată se potrivește cu semnatarul. După o rotație a cheii, migrare de furnizor sau reconectare ESP, este obișnuit ca semnatarul să dețină o nouă cheie privată în timp ce DNS-ul servește în continuare vechea cheie publică — fiecare semnătură este verificată față de cheia greșită și eșuează. Re-copiați înregistrarea curentă din consola de administrare a furnizorului dvs. Mai bine: acolo unde furnizorul oferă delegarea CNAME, folosiți-o — furnizorul rotește cheile de pe partea sa și toată această clasă de eșecuri dispare. Și nu ștergeți niciodată un selector vechi până când traficul semnat cu el s-a drenat.
5. Corectați setările de semnare, nu doar înregistrarea. Setați canonicalizarea la c=relaxed/relaxed, care tolerează re-împachetarea spațiilor albe și re-plierea antetelor pe care serverele intermediare le fac în mod legitim; canonicalizarea simple eșuează la modificări pe care un om nici nu le poate vedea. Și nu folosiți tagul l= de lungime a corpului: a fost menit să permită subsoluri, dar permite oricui să adauge conținut la mesajul dvs. semnat fără a sparge semnătura — un vector de atac real — și totuși nu supraviețuiește celor mai multe modificări de gateway. Niciun l= este atât alegerea mai sigură cât și cea mai fiabilă.
6. Re-scanați, apoi verificați alinierea. O semnătură validă ajută DMARC doar dacă domeniul d= se aliniază cu domeniul dvs. From — o semnătură care se validează ca d=yourcompany.gappssmtp.com trece DKIM și eșuează totuși DMARC. Dacă aceasta este situația dvs., consultați capcana semnăturii implicite, apoi parcurgeți orice altceva semnalează scanarea pe pagina corectați DKIM.

Întrebări frecvente

„DKIM signature not valid” este același lucru cu „body hash did not verify”? Mesajul body-hash este un sub-caz specific: corpul s-a schimbat după semnare (subsoluri, disclaimer-e, rescrieri de listă). „Signature not valid” este verdictul umbrelă pentru orice verificare eșuată, inclusiv chei greșite și modificări de antete — de aceea pasul 2 de mai sus este citirea antetului și de aceea cazul body-hash are propriul ghid.

O semnătură DKIM invalidă înseamnă că e-mailul meu este respins? Nu în sine — receptorii tratează o semnătură stricată ca pe una lipsă. Daunele apar prin DMARC: dacă SPF nu trece nici cu aliniere, mesajul eșuează DMARC și se aplică politica dvs. publicată. Conform recensământului din 2026-06-29, doar 3.87% din 261,086,232 domenii clasificate dețin SPF, DKIM și o politică DMARC aplicată împreună — dar Gmail și Microsoft așteaptă acum exact asta de la expeditori, deci un picior DKIM stricat costă livrabilitate chiar înainte de respingere.

Ar trebui să folosesc o cheie DKIM de 1024 de biți sau de 2048 de biți? 2048 de biți — cheile de 1024 de biți sunt sub recomandările criptografice curente și unii receptori le penalizează. Dezavantajul este pur operațional: o cheie de 2048 de biți nu încape într-un singur șir TXT de 255 de caractere, deci trebuie împărțită corect (cauza 2 de mai sus). Delegarea CNAME la furnizorul dvs. evită complet problema împărțirii.

DKIM-ul meu trece pe un verificator dar DMARC eșuează totuși — cum? Aproape sigur aliniere: semnătura se validează, dar domeniul d= al acesteia (de ex., yourcompany.gappssmtp.com sau yourtenant.onmicrosoft.com) nu se potrivește cu domeniul dvs. From, deci DMARC nu o poate folosi. Activați semnarea cu domeniu personalizat a furnizorului — ghidul complet este în ghidul capcanei semnăturii implicite.

Pot dezactiva pur și simplu DKIM dacă tot eșuează? Nu — de la mandatele expeditorului de masă din 2024, Gmail și Yahoo cer DKIM pentru expeditorii de volum, iar o politică DMARC aplicată are nevoie realist de DKIM deoarece SPF singur se strică la redirecționare. Reparați semnătura; cauzele de mai sus sunt toate remediabile într-o după-amiază.

Trimiteți proprietarului raportul

Dacă reparați asta pentru un client sau angajatorul dvs., încheiați cu dovezi. Re-rulați scanarea gratuită după modificările dvs. și trimiteți raportul clasificat proprietarului afacerii: datat, limbaj simplu, DKIM arătând verde. Este artefactul de care vor avea nevoie pentru reînnoirea asigurării cibernetice și pentru următorul chestionar de securitate al furnizorilor — diferența dintre „am reparat ceva DNS” și un înainte-și-după documentat care spune că domeniul își autentifică e-mailul.

Verificați domeniul → · Ghid „Body hash did not verify” → · Corectați DKIM → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.