DKIM "Body Hash Did Not Verify" — Mikä muutti viestiäsi ja miten korjata se (2026)

Julkaistu 2026-07-08

Luvut päivätty 2026-06-29 · metodologia v7. Aggregoitu väestölaskentadata 261 miljoonan arvioidun verkkotunnuksen yli. Katso miten arvioimme.

“Body hash did not verify” tarkoittaa, että DKIM-allekirjoituksesi oli kelvollinen kun viesti lähti sinulta — ja jokin kirjoitti viestin rungon uudelleen sen jälkeen. Allekirjoitus ei ole rikki; viestiä muokattiin siirrossa. Vain 3.87% verkkotunnuksista — 10,092,481 — suorittaa täydellisen SPF-DKIM-DMARC -triadon Defaults.Exposed-palvelun 261,086,232 verkkotunnuksen väestölaskennan mukaan (2026-06-29).

Korjaus on metsästys, sitten päätös. Löydä hyppy, joka muokkaa postiasi — yhdyskäytävä, joka lisää vastuuvapauslausekkeen, laite, joka kirjoittaa linkkejä uudelleen, postituslista, joka lisää alatunnisteen. Sitten allekirjoita kyseisen hypyn jälkeen, lopeta muokkaus tai tee allekirjoituksesta sen tolerantti — siinä järjestyksessä.

Mitä “body hash did not verify” oikeasti tarkoittaa?

DKIM-allekirjoitus (RFC 6376) sisältää kaksi tiivistettä: bh=, tiiviste viestin rungosta allekirjoitettuna, ja b=, joka allekirjoittaa otsakkeet sekä kyseisen runkotiivisteen. Tarkistaja laskee uudelleen runkotiivisteen vastaanotetusta viestistä; jos se ei vastaa bh=:ta, vahvistus pysähtyy merkkijonoon, jonka kaikki liittävät hakukenttään — vastaanottajan otsake kuten:

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

Se on Microsoftin dokumentoitu syy-merkkijono; Gmail renderöi usein saman diagnoosin muodossa dkim=neutral (body hash did not verify). Kummassakin tapauksessa tuomio rajaa ongelman huomattavasti. DNS-avaimesi, selektorisi ja allekirjoituskonfiguraatiosi ovat kaikki hyvin. Kryptografia teki työnsä: runko muuttui allekirjoituksen ja vahvistuksen välillä — yksi lisätty rivi, yksi kirjoitettu URL uudelleen, yksi uudelleenkoodattu merkki riittää. (Eri viesti — signature did not verify, no key for signature — tarkoittaa eri epäonnistumista; aloita kohdasta “DKIM-allekirjoitus ei kelpaa”.) Ja se on kiireellistä, koska epäonnistunut allekirjoitus ei voi antaa DMARC:lle linjautunutta läpäisyä: ellei SPF läpäise linjautuneesti samassa viestissä, posti epäonnistuu DMARC:ssa suoraan.

Mikä muutti viestiäsi? Tavalliset epäillyt

Jokin toimituspolulla muokkasi runkoa allekirjoittajasi sinetöityä sen jälkeen. Käytännössä se on yksi neljästä:

Kuka muokkasi	Mitä he muuttavat	Tyypillinen merkki
Lähtevä yhdyskäytävä / älykäs isäntä (Exchange-kuljetussäännöt, Mimecast, Proofpoint, Barracuda…)	Lisää juridisen vastuuvapauslausekkeen, markkinointialatunnisteen tai “EXTERNAL:“-bannerin postipalvelimen jo allekirjoitettua	Kaikki viestit kyseisellä reitillä epäonnistuvat; suorat lähetykset yhdyskäytävän ohi läpäisevät
Tietoturvalaitteisto / linkinssuojaus	Kirjoittaa URLit uudelleen skannaaviin uudelleenohjauksiin, lisää seurantakääristeitä	Vain linkkejä sisältävät viestit epäonnistuvat
Postituslista (Google Groups, Mailman…)	Lisää aihetunnisteen ja listaalatunnisteen, joskus muotoilee rungon uudelleen	Vain listan kautta lähetetty posti epäonnistuu
Välittäjä / rele uudelleenkoodaa MIMEn	Transkoodaa merkistön, rivityy uudelleen — ihmiselle näkymätön, tiivisteelle tappava	Epäonnistumiset klusteroituvat yhteen vastaanottajaan tai edelleenlähetysosoitteeseen

Tarkista lihavoitu rivi ensin — postipalvelin allekirjoittaa, reunalaite muokkaa, ja jokainen viesti lähtee allekirjoituksella, joka oli tosi kolmekymmentä millisekuntia.

Miten löydän hypyn, joka muokkaa postiaan?

Differentiaalinen diagnoosi — vertaa toimivaa polkua epäonnistuvaan polkuun:

Lähetä suora testiviesti hallitsemaasi postilaatikkoon suurella vastaanottajalla (Gmail toimii hyvin), ohittaen mahdollisimman paljon lähtevästä ketjustasi.
Lähetä toinen viesti epäonnistuvaa polkua pitkin — yhdyskäytävän kautta, listan kautta, vaikuttuneelle vastaanottajalle.
Vertaa Authentication-Results-rivejä molempien täysien otsakkeiden välillä. Suora lähetys dkim=pass, epäonnistuva polku dkim=fail (tai dkim=neutral) arvolla body hash did not verify: muokkaaja asuu näiden kahden reitin välissä.
Katso vastaanotettua runkoa: vastuuvapauslauseke, banneri tai alatunniste, jota et kirjoittanut? Linkit kirjoitettu uudelleen skannausverkkotunnukseen? Se on sinun hyppysi, nimettynä — ja Received:-ketju näyttää, mikä rele näkyy vain epäonnistuvassa polussa.

DMARC-aggregaattiraporttisi kertovat saman tarinan laajemmassa mittakaavassa: lähde, joka raportoi johdonmukaisesti DKIM-epäonnistumista SPF-läpäisyllä, on yleensä siirrossa tapahtuva muokkaus omalla reitilläsi, ei hyökkääjä.

Miten korjaan sen?

Aja ilmainen skannaus osoitteessa defaults.exposed ennen kuin kosket mihinkään. Se vahvistaa, että julkaistut DKIM-avaimet ja DMARC-käytäntö ovat kunnossa, jotta virheenetsit yhden todellisen ongelman — muokkauksen — etkä jahda aaveita DNS:ssä. Korjaa DKIM -sivu kattaa tietuepuolen tarkistukset.
Allekirjoita muokkaavan hypyn jälkeen. Arkkitehtonisesti oikea korjaus: siirrä DKIM-allekirjoitus uloimman viestiä koskettavan laitteen tehtäväksi. Exchange-plus-yhdyskäytävä -kauppojen pitäisi allekirjoittaa yhdyskäytävässä (Mimecast, Proofpoint ja vastaavat tukevat sitä) ja poistaa allekirjoitus käytöstä ylävirtaan. Jos Google Workspace tai Microsoft 365 on viimeinen hyppysi, allekirjoita siellä äläkä anna minkään muokata postia sen jälkeen — katso aseta DKIM Google Workspacelle tai Microsoft 365:lle.
Tai lopeta muokkaus. Poista muokkaus kuljetuspolulta: vastuuvapauslauseke asiakasallekirjoituksessa tai mallissa kuljetussäännön sijaan; “EXTERNAL:“-banneri rajattu vain saapuvaan postiin (oman lähtevän postin merkitseminen ulkoiseksi on kaksinkertainen virhekonfiguraatio); todennettu lähtevä posti vapautettu linkkien uudelleenkirjoituksesta.
Käytä relaxed/relaxed-kanonisointia (c=relaxed/relaxed). simple-runkokanonisointi epäonnistuu yhdellä uudelleenrivityllä rivillä; relaxed sietää välilyönti- ja rivinlopetuseroja. Ole rehellinen rajoituksesta: relaxed antaa anteeksi muotoilun, ei koskaan sisältöä — lisätty alatunniste epäonnistuu silti, kuten kuuluukin.
Testaa molemmat polut uudelleen, sitten skannaa uudelleen. Molemmilla reiteillä pitäisi nyt näkyä dkim=pass verkkotunnuksellasi d=-arvossa, ja skannausraportin pitäisi olla puhdas.

Pitäisikö minun käyttää l=-tunnistetta saadakseni DKIMin ohittamaan lisätyn sisällön?

Ei — ja epäile mitä tahansa opasta, joka ehdottaa sitä. l=-tunniste tiivistää vain viestin rungon ensimmäiset N tavua, joten lisätty alatunniste ei enää riko allekirjoitusta. Se “toimii” jättämällä viestisi lopun allekirjoittamattomaksi: kuka tahansa pitäen kelvollista allekirjoitettua viestiä voi lisätä mielivaltaista sisältöä ja kelvollinen allekirjoituksesi vahvistuu silti tuloksesta. Tämä on huijauksen aukko, joka on puettu korjauksen vaatteisiin — käytännöllistä väärinkäyttöä on demonstroitu, ja jotkut vastaanottajat rankaisevat tai jättävät l=:n huomiotta juuri tästä syystä. Ratkaise muokkaus; älä poista allekirjoitusta postin osasta.

Entä postituslistat — voinko korjata ne?

Pääasiassa ei — ja sen tietäminen säästää viikkoja. Lista, joka lisää aihetunnisteen tai alatunnisteen, rikkoo runkotiivisteen rakenteellisesti, eikä sinulla ole listaa hallinnassa. Kaksi asiaa auttaa:

Tämä jäänne on täsmälleen syy, miksi DMARC-käyttöönotto on vaiheistettu. Siirtyminen p=none:sta p=quarantine:in kautta pct=-lisäyksellä, samalla kun luet aggregaattiraportteja, tarkoittaa, että listojen muokkaamat viestit karanteenisoidaan eikä tuhoudu kun arvioit vaikutusta — aihe on p=none:sta p=reject:iin ilman laillisen sähköpostin menettämistä.
ARC on vastaanottajan mekanismi, ei sinun. Authenticated Received Chain antaa listan todistaa, miltä todennus näytti saapuessa ja vastaanottajan päättää luottaako siihen. Sinulle, lähettäjälle, ei ole mitään konfiguroitavaa. Hyvin hoidetut listat lieventävät kirjoittamalla From-otsakkeen uudelleen; huonosti hoidetut vain rikkovat postisi.

Edelleenlähetys on viereinen tapaus — se rikkoo luotettavasti SPF:n mutta vain joskus DKIMin, minkä vuoksi linjautunut DKIM on edelleenlähetyksensuojaava jalkasi kun runko säilyy: katso edelleenlähetetty posti epäonnistuu SPF:ssä — miksi et voi korjata sitä.

Miksi DKIM hajoaa niin usein kun niin harvalla verkkotunnuksella on koko pino?

Koska DKIM on triadon hauras keskimmäinen lapsi: SPF on staattinen DNS-tietue, DMARC käytäntölausunto, mutta DKIMin täytyy selviytyä matkasta. Vain 51.84% arvioiduista verkkotunnuksista julkaisee löydettävän DKIM-avaimen DNS:ssä ollenkaan Defaults.Exposed-väestölaskennan mukaan, ja vain 10,092,481 verkkotunnusta — 3.87% 261,086,232 arvioidusta — pitää SPF:ää, DKIMia ja valvovaa DMARC-käytäntöä yhdessä (SPF:n käyttöönottomaturiteettimalli pilkkoo tikkaat alas). Tämän korjauksen oikein tekeminen on vaikein osa 3.87%:n joukkoon liittymisessä.

Usein kysytyt kysymykset

Onko “body hash did not verify” merkki siitä, että joku huijaa verkkotunnustani? Yleensä ei — huijari yleensä ei pysty tuottamaan DKIM-allekirjoitustasi ollenkaan, joten heidän postissaan ei näy allekirjoitusta tai siinä lukee no key. Epäonnistunut runkotiiviste tarkoittaa, että infrastruktuurisi aidosti allekirjoittama viesti muokattiin sen jälkeen. Tarkista oma yhdyskäytäväsi ennen kuin olettaa hyökkääjää.

SPF läpäisee näissä viesteissä — olenko vielä turvassa? Toistaiseksi ehkä: DMARC tarvitsee vain yhden linjautuneen läpäisyn. Mutta SPF:n läpäisy haihtuu heti kun kukaan välittää viestin eteenpäin, ja jos se ei linjaudu From-verkkotunnuksesi kanssa, se ei koskaan laskenut DMARC:lle joka tapauksessa. Vain 3.87%:lla verkkotunnuksista on koko triad (2026-06-29 väestölaskenta 261,086,232 verkkotunnuksesta), “yksi jalka ontuu” on normaali tila — ja korjattava.

Korjaako vaihtaminen relaxed/relaxed-kanonisointiin vastuuvapauslauseke-ongelmani? Ei. Relaxed sietää vain välilyönti- ja rivinvaihtoeroja. Lisätty vastuuvapauslauseke on sisältömuutos, ja tiivisteen täytyy epäonnistua siinä — se on DKIM, joka toimii oikein. Siirrä allekirjoituspistettä tai siirrä vastuuvapauslauseke.

Epäonnistuminen tapahtuu vain yhdelle asiakkaan verkkotunnukselle. Miksi? Heidän puolensa muokkaa lähes varmasti saapuvaa postia — tietoturvalaitteisto kirjoittaa linkit uudelleen tai leimaa bannereita ennen kuin heidän tarkistajansa ajaa, tai sisäinen edelleenlähetys koodaa rungon uudelleen. Lähetä heille tämän sivun diagnoosiosio; korjaus on heidän yhdyskäytävässään, ei DNS:ssäsi.

Lähetä omistajalle raportti

Jos korjaat tätä asiakkaalle tai työnantajallesi, sulje silmukka todisteella. Kun muokkaava hyppy on korjattu, aja ilmainen skannaus uudelleen ja lähetä arvioitu raportti yrityksen omistajalle: päivätty, selkokielinen, DKIM ja DMARC yhdellä sivulla. Se on artefakti, jota he tarvitsevat kyberturvallisuusvakuutuksen uusimiseen ja seuraavaan toimittajakyselyyn — todiste siitä, että yritykseltä lähtevä posti on nyt se posti, joka saapuu.

Tarkista verkkotunnuksesi → · “DKIM-allekirjoitus ei kelpaa” -opas → · Korjaa DKIM → · Miten arvioimme → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.