Defaults.Exposed › Remedieri › Guides

DKIM „Body Hash Did Not Verify" — Ce a schimbat mesajul dvs. și cum să-l remediați (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.

„Body hash did not verify” înseamnă că semnătura DKIM era validă când mesajul a plecat de la dvs. — și ceva a rescris corpul mesajului ulterior. Semnătura nu este stricată; mesajul a fost modificat în tranzit. Doar 3.87% din domenii — 10,092,481 — completează triada completă SPF-DKIM-DMARC, conform recensământului Defaults.Exposed pe 261,086,232 domenii (2026-06-29).

Remedierea este o căutare, apoi o decizie. Găsiți hopul care modifică e-mailul dvs. — un gateway care adaugă un disclaimer, un dispozitiv care rescrie linkuri, o listă de corespondență care adaugă un subsol. Apoi semnați după acel hop, opriți modificarea sau faceți semnătura tolerantă la ea — în această ordine.

Ce înseamnă de fapt „body hash did not verify”?

O semnătură DKIM (RFC 6376) poartă două hash-uri: bh=, un hash al corpului mesajului la momentul semnării, și b=, care semnează antetele plus acel hash de corp. Verificatorul recomputează hash-ul corpului din mesajul primit; dacă nu se potrivește cu bh=, verificarea se oprește cu șirul pe care toată lumea îl lipește în motorul de căutare — un antet de receptor precum:

Authentication-Results: …; dkim=fail (body hash did not verify)

Acesta este șirul de motiv documentat de Microsoft; Gmail redă adesea același diagnostic ca dkim=neutral (body hash did not verify). În orice caz, verdictul îngustează enorm problema. Cheia DNS, selectorul și configurația de semnare sunt toate în regulă. Criptografia și-a făcut treaba: corpul s-a schimbat între semnare și verificare — o linie adăugată, un URL rescris, un caracter re-codificat este suficient. (Un mesaj diferit — signature did not verify, no key for signature — înseamnă un eșec diferit; începeți cu „DKIM signature not valid”.) Și este urgent deoarece o semnătură eșuată nu poate oferi DMARC un pass aliniat: dacă SPF nu trece cu aliniere pe același mesaj, e-mailul eșuează DMARC complet.

Ce a schimbat mesajul dvs.? Suspecții obișnuiți

Ceva în calea de livrare a editat corpul după ce semnatarul l-a sigilat. În practică este unul din patru lucruri:

Verificați mai întâi rândul îngroșat — serverul de e-mail semnează, dispozitivul de margine editează și fiecare mesaj pleacă cu o semnătură care a fost adevărată pentru treizeci de milisecunde.

Cum găsesc hopul care modifică e-mailul meu?

Diagnostic diferențial — comparați o cale care funcționează cu calea care eșuează:

1. Trimiteți un mesaj de test direct la o căsuță poștală pe care o controlați la un receptor major (Gmail funcționează bine), ocolind cât mai mult din lanțul dvs. de ieșire.
2. Trimiteți un al doilea mesaj pe calea care eșuează — prin gateway, prin listă, la domeniul destinatarului afectat.
3. Comparați liniile Authentication-Results în ambele antete complete. Trimitere directă dkim=pass, cale care eșuează dkim=fail (sau dkim=neutral) cu body hash did not verify: modificatorul se află între acele două rute.
4. Uitați-vă la corpul primit: un disclaimer, banner sau subsol pe care nu l-ați scris? Linkuri rescrise la un domeniu de scanare? Acela este hopul dvs., identificat — iar lanțul Received: arată ce releu apare doar în calea care eșuează.

Rapoartele dvs. agregate DMARC spun aceeași poveste la scară: o sursă care raportează consistent eșec DKIM cu pass SPF este de obicei modificare-în-tranzit pe propria dvs. rută, nu un atacator.

Cum o remediez?

1. Rulați scanarea gratuită la defaults.exposed înainte de a atinge orice. Confirmă că cheile DKIM publicate și politica DMARC sunt corecte, deci depanați singura problemă reală — modificarea — nu urmăriți fantome în DNS. Pagina corectați DKIM acoperă verificările din partea înregistrărilor.
2. Semnați după hopul care modifică. Remedierea corectă arhitectural: mutați semnarea DKIM la dispozitivul cel mai exterior care atinge mesajul. Magazinele Exchange-plus-gateway ar trebui să semneze la gateway (Mimecast, Proofpoint și similarii îl suportă) și să dezactiveze semnarea în amonte. Dacă Google Workspace sau Microsoft 365 este ultimul dvs. hop, semnați acolo și nu lăsați nimic să editeze e-mailul după aceea — consultați configurați DKIM pe Google Workspace sau Microsoft 365.
3. Sau opriți modificarea. Scoateți editarea din calea de transport: disclaimer în semnătura clientului sau șablonul în locul regulii de transport; bannerul „EXTERNAL:” limitat doar la e-mailul de intrare (etichetarea propriului e-mail de ieșire ca extern este o configurație greșită de două ori); e-mailul autentic de ieșire exclus de la rescrierea linkurilor.
4. Folosiți canonicalizarea relaxed/relaxed (c=relaxed/relaxed). Canonicalizarea simple a corpului eșuează pe o singură linie re-împachetată; relaxed tolerează modificările spațiilor albe și ale terminațiilor de linie. Fiți sincer cu privire la limită: relaxed iartă formatarea, niciodată conținutul — un subsol adăugat eșuează în continuare, cum ar trebui.
5. Re-testați ambele căi, apoi re-scanați. Ambele rute ar trebui să arate acum dkim=pass cu domeniul dvs. în d=, iar raportul de scanare ar trebui să fie curat.

Ar trebui să folosesc tagul l= pentru ca DKIM să ignore conținutul adăugat?

Nu — și fiți suspicioși față de orice ghid care îl sugerează. Tagul l= hash-uiește doar primii N octeți ai corpului, deci un subsol adăugat nu mai strică semnătura. „Funcționează” lăsând sfârșitul mesajului dvs. nesemnat: oricine deține un mesaj semnat legitim poate adăuga conținut arbitrar și semnătura dvs. validă se verifică totuși peste rezultat. Aceasta este o gaură de spoofing deghizată în remediere — abuzul practic a fost demonstrat și unii receptori penalizează sau ignoră l= exact din acest motiv. Rezolvați modificarea; nu desemnați o parte a e-mailului dvs.

Ce se întâmplă cu listele de corespondență — le pot repara?

În mare parte, nu — și știind asta vă economisește săptămâni. O listă care adaugă un tag de subiect sau subsol strică hash-ul corpului dvs. prin design și nu controlați lista. Două lucruri ajută:

• Acest reziduu este exact de ce lansarea DMARC este etapizată. Trecând de la p=none prin p=quarantine cu o rampă pct=, citind rapoartele agregate, înseamnă că mesajele denaturate de liste sunt puse în carantină mai degrabă decât distruse în timp ce evaluați impactul — subiectul ghidului de la p=none la p=reject fără a pierde e-mailul legitim.
• ARC este mecanismul receptorului, nu al dvs. Authenticated Received Chain permite listei să ateste cum arăta autentificarea la sosire și receptorului să decidă dacă să aibă încredere în ea. Nu există nimic pe care dvs., expeditorul, să-l configurați. Listele bine administrate atenuează prin rescrierea antetului From; cele prost administrate pur și simplu strică e-mailul dvs.

Redirecționarea este cazul adiacent — strică în mod fiabil SPF dar doar uneori DKIM, de aceea DKIM aliniat este piciorul dvs. rezistent la redirecționare când corpul supraviețuiește: consultați e-mailul redirecționat eșuează SPF — de ce nu îl puteți repara.

De ce se strică DKIM atât de des când atât de puține domenii au stiva completă?

Deoarece DKIM este copilul fragil din mijloc al triadei: SPF este o înregistrare DNS statică, DMARC o declarație de politică, dar DKIM trebuie să supraviețuiască călătoriei. Doar 51.84% din domeniile clasificate publică o cheie DKIM descoperabilă în DNS, conform recensământului Defaults.Exposed, și doar 10,092,481 domenii — 3.87% din 261,086,232 clasificate — dețin SPF, DKIM și o politică DMARC aplicată împreună (modelul de maturitate al adoptării SPF descompune scara). Obținerea acestei reparații corect este cea mai grea parte a alăturării acelui 3.87%.

Întrebări frecvente

„Body hash did not verify” este un semn că cineva îmi falsifică domeniul? De obicei nu — un falsificator de obicei nu poate produce deloc semnătura dvs. DKIM, deci e-mailul lor arată nicio semnătură sau no key. Un hash de corp eșuat înseamnă că un mesaj semnat în mod genuine de infrastructura dvs. a fost editat ulterior. Verificați propriul gateway înainte de a presupune un atacator.

SPF trece pe aceste mesaje — sunt în regulă? Deocamdată, poate: DMARC are nevoie de un singur pass aliniat. Dar pass-ul SPF evaporă în momentul în care cineva redirecționează mesajul și dacă nu este aliniat cu domeniul dvs. From, nu a contat niciodată pentru DMARC oricum. Cu doar 3.87% din domenii deținând triada completă (recensământul 2026-06-29 al 261,086,232 domenii), „un picior șchiopătând” este starea normală — și cea remediabilă.

Va rezolva trecerea la canonicalizarea relaxed/relaxed problema mea cu disclaimer-ul? Nu. Relaxed tolerează doar modificările spațiilor albe și ale împachetării liniilor. Un disclaimer adăugat este o modificare de conținut și hash-ul trebuie să eșueze pe el — acesta este DKIM funcționând corect. Mutați punctul de semnare sau mutați disclaimer-ul.

Eșecul se întâmplă doar la domeniul unui client. De ce? Partea lor modifică aproape sigur e-mailul de intrare — un dispozitiv de securitate care rescrie linkuri sau aplică bannere înainte ca verificatorul lor să ruleze, sau o redirecționare internă care re-codifică corpul. Trimiteți-le secțiunea de diagnostic a acestei pagini; remedierea este pe gateway-ul lor, nu în DNS-ul dvs.

Trimiteți proprietarului raportul

Dacă reparați asta pentru un client sau angajatorul dvs., încheiați cu dovezi. Odată ce hopul care modifică este reparat, re-rulați scanarea gratuită și trimiteți raportul clasificat proprietarului afacerii: datat, limbaj simplu, DKIM și DMARC pe o singură pagină. Este artefactul de care vor avea nevoie pentru reînnoirea asigurării cibernetice și pentru următorul chestionar al furnizorilor — dovada că e-mailul care iese din companie este acum e-mailul care ajunge.

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