DKIM „Body hash did not verify" — Mi módosította az üzenetét, és hogyan javítsa (2026)

Közzétéve 2026-07-08

Adatok: 2026-06-29 · 7. módszertan. Összesített népszámlálási adatok 261 millió értékelt domain alapján. Lásd: hogyan értékelünk.

A „body hash did not verify” azt jelenti, hogy a DKIM-aláírása érvényes volt, amikor az üzenet elhagyta Önt — és valami utólag átírta az üzenet törzsét. Az aláírás nem sérült; az üzenet módosult szállítás közben. A Defaults.Exposed 261,086,232 domainre kiterjedő népszámlálása szerint (2026-06-29) a domaineknek mindössze 3.87%-a — 10,092,481 — teljesíti a teljes SPF-DKIM-DMARC hármast.

A javítás egy nyomozás, majd egy döntés. Keresse meg azt az ugrópontot, amely módosítja a levelét — egy nyilatkozatot hozzáfűző átjáró, egy hivatkozásokat átíró berendezés, egy lábléget hozzáadó levelezőlista. Majd írjon alá az adott ugróponttól számítva utóbb, szüntesse meg a módosítást, vagy tegye az aláírást tűrővé iránta — ebben a sorrendben.

Mit jelent ténylegesen a „body hash did not verify”?

Egy DKIM-aláírás (RFC 6376) két kivonatot tartalmaz: bh=, az aláírt üzenet törzsének kivonatát, és b=, amely a fejlécek plusz a törzskivonat felett ír alá. Az ellenőrző újraszámolja a törzskivonatot a kapott üzenetből; ha nem egyezik a bh= értékkel, az ellenőrzés megáll az ismert hibaüzenettel — vevői fejlécként:

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

Ez a Microsoft dokumentált indoklási szövege; a Gmail ugyanezt dkim=neutral (body hash did not verify) értékként jeleníti meg. Mindenesetre az ítélet jelentősen leszűkíti a problémát. A DNS-kulcsa, selectora és aláírási konfigurációja mind rendben van. A kriptográfia elvégezte a munkáját: az üzenet törzse megváltozott az aláírás és az ellenőrzés között — egy hozzáfűzött sor, egy átírt URL, egy újrakódolt karakter elég. (Eltérő üzenet — signature did not verify, no key for signature — eltérő hibát jelent; kezdje a „DKIM signature not valid” útmutatóval.) Ez sürgető, mert egy sikertelen aláírás nem adhat igazított átmenetet a DMARC-nak: hacsak az SPF nem megy át igazítással ugyanazon az üzeneten, a levél teljesen megbukik a DMARC-on.

Mi módosította az üzenetét? A szokásos gyanúsítottak

A kézbesítési útvonal valami el lett módosítva az aláírás után. A gyakorlatban négy dolog egyike:

Ki módosította	Mit változtatott	Jellemző árulkodó jel
Kimenő átjáró / okos gazdagép (Exchange átviteli szabályok, Mimecast, Proofpoint, Barracuda…)	Hozzáfűzi a jogi nyilatkozatot, marketing lábléget, vagy „KÜLSŐ:” szalagcímet azután, hogy a levelezőszerver már aláírt	Az adott útvonalon minden üzenet megbukik; az átjárót megkerülő közvetlen küldések átmennek
Biztonsági berendezés / hivatkozásvédelem	Átírja az URL-eket szkennelési átirányításokra, nyomkövető burkolókat ad hozzá	Csak a hivatkozásokat tartalmazó üzenetek buknak meg
Levelezőlista (Google Groups, Mailman…)	Tárgycímkét és lista-lábléget ad hozzá, néha újrarendezi a törzset	Csak a listán keresztül küldött levelek buknak meg
Továbbító / relé MIME-újrakódolással	Átkódolja a karakterkészletet, újracsomagolja a sorokat — az ember számára láthatatlan, egy kivonat számára végzetes	A hibák egy vevőnél vagy egy továbbítási cím körül csoportosulnak

Először az félkövér sort ellenőrizze — a levelezőszerver aláír, a peremeszköz szerkeszt, és minden üzenet harminc milliszekundum után érvényes volt aláírással hagyja el a rendszert.

Hogyan találom meg a levelemet módosító ugrópontot?

Differenciáldiagnózis — hasonlítson össze egy működő útvonalat a meghibásodóval:

Küldjön egy közvetlen tesztüzenetet egy Ön által ellenőrzött postafiókba egy nagy vevőnél (Gmail jól működik), a kimenő lánc lehető legnagyobb részét megkerülve.
Küldjön egy második üzenetet a meghibásodó útvonalon — az átjárón keresztül, a listán keresztül, az érintett vevő domainjéhez.
Hasonlítsa össze az Authentication-Results sorokat mindkét teljes fejlécben. Közvetlen küldés dkim=pass, meghibásodó útvonal dkim=fail (vagy dkim=neutral) body hash did not verify értékkel: a módosító a két útvonal között él.
Nézze meg a kapott törzset: nyilatkozat, szalagcím vagy lábléc, amelyet Ön nem írt? Hivatkozások átírva egy szkennelési domainre? Ez az ugrópontja, megnevezve — és a Received: lánc megmutatja, melyik relé jelenik meg csak a meghibásodó útvonalban.

A DMARC-összesítő jelentései nagy léptékben ugyanezt a történetet mondják el: egy forrás, amely következetesen DKIM-hibát jelent SPF-átmenettel, általában saját útvonalán bekövetkező szállítás közbeni módosítást jelent, nem egy támadót.

Hogyan javítsam?

Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon, mielőtt hozzányúl bármihez. Megerősíti, hogy a közzétett DKIM-kulcsai és a DMARC-szabályzata rendben vannak, tehát az egyetlen valódi problémát, a módosítást, hibakereseti munkával kezeli — nem kísérteteket hajszol a DNS-ben. A DKIM javítása oldal a rekordoldali ellenőrzéseket ismerteti.
Írjon alá a módosító ugróponttól számítva utóbb. Az architekturálisan helyes javítás: helyezze a DKIM-aláírást a legkülső eszközre, amely megérinti az üzenetet. Az Exchange-plusz-átjáró eseteket az átjárón kell aláírni (a Mimecast, Proofpoint és társaik mind támogatják), és le kell tiltani az aláírást a korábbi lépésekben. Ha a Google Workspace vagy a Microsoft 365 az utolsó ugrópontja, ott írjon alá, és ne engedjen semmit szerkeszteni a levélen utána — lásd: DKIM beállítása Google Workspace-en vagy Microsoft 365-ön.
Vagy szüntesse meg a módosítást. Vegye ki a szerkesztést az átviteli útvonalból: nyilatkozat az ügyfél aláírásába vagy sablonba, ne átviteli szabályba; „KÜLSŐ:” szalagcím csak a bejövő levelekre korlátozva (a saját kimenő leveleit külsőként jelölni kétszeres hiba); hitelesített kimenő levelek mentesítve a hivatkozás-átírás alól.
Használja a relaxed/relaxed kanonizációt (c=relaxed/relaxed). A simple törzs-kanonizáció egyetlen újracsomagolt soron megbukik; a relaxed tolerálja a szóköz- és sorkarakter-változásokat. Legyen őszinte a korlátról: a relaxed formázási eltéréseket bocsát meg, tartalmi módosításokat soha — egy hozzáfűzött lábléc még mindig megbukik, ahogy kellene is.
Tesztelje újra mindkét útvonalat, majd futtassa újra a vizsgálatot. Mindkét útvonalnak most dkim=pass értéket kell mutatnia az Ön domainjével a d= értékben, és a vizsgálati jelentésnek tisztának kell lennie.

Használjam az l= taget, hogy a DKIM figyelmen kívül hagyja a hozzáfűzött tartalmat?

Nem — és legyen gyanakodva minden útmutatóval szemben, amely ezt javasolja. Az l= tag csak az üzenet törzsének első N bájtját vonja ki kivonat alá, tehát egy hozzáfűzött lábléc már nem töri meg az aláírást. Ez „működik” azzal, hogy az üzenet végét aláíratlanul hagyja: bárki, aki egy legális aláírt üzenetet tart a kezében, tetszőleges tartalmat fűzhet hozzá, és az érvényes aláírása még mindig ellenőrzi az eredményt. Ez egy hamisítási rés egy javítás jelmezében — gyakorlati visszaélést demonstráltak, és néhány vevő pontosan ezért bünteti vagy figyelmen kívül hagyja az l= értéket. Oldja meg a módosítást; ne hagyja alá nem írni a levele egy részét.

Mi a helyzet a levelezőlistákkal — meg tudom-e javítani azokat?

Nagyrészt nem — és ezt tudva heteket takaríthat meg. Egy olyan lista, amely tárgycímkét vagy lábléget ad hozzá, szándéka szerint töri meg a törzskivonatot, és Ön nem irányítja a listát. Két dolog segít:

Ez a maradék pontosan az oka annak, hogy a DMARC-bevezetés szakaszos. Az p=none-ról a p=quarantine-ra való áttérés pct= emelkedéssel, összesítő jelentések olvasásával, azt jelenti, hogy a lista által megrongált üzenetek karanténba kerülnek, nem pedig megsemmisülnek, miközben felmérjük a hatást — ez a p=none-tól p=reject-ig a jogszerű e-mailek elvesztése nélkül témája.
Az ARC a vevő mechanizmusa, nem az Öné. Az Authenticated Received Chain lehetővé teszi, hogy a lista tanúsítsa, hogyan nézett ki a hitelesítés az érkezéskor, és a vevő döntse el, megbízzon-e benne. Az Ön, a küldő számára nincs semmi beállítanivaló. A jól működő listák a Feladó fejléc átírásával enyhítik a problémát; a rosszul működők egyszerűen tönkreteszik a leveleit.

A továbbítás szomszédos eset — megbízhatóan tönkreteszi az SPF-et, de csak néha a DKIM-et, ezért az igazított DKIM a továbbítás-biztos igazítás, ha a törzs megmarad: lásd: a továbbított e-mail meghibásodik az SPF-en — miért nem javíthatja.

Miért törödik a DKIM olyan sűrűn, ha ilyen kevés domainnek van meg az egész stack?

Mert a DKIM a hármas törékeny középső gyereke: az SPF statikus DNS-rekord, a DMARC szabályzatnyilatkozat, de a DKIM-nek túl kell élnie az utat. A Defaults.Exposed népszámlálása szerint az értékelt domaineknek mindössze 51.84%-a tesz közzé felderíthető DKIM-kulcsot a DNS-ben, és mindössze 10,092,481 domain — 3.87% a 261,086,232 értékelt közül — rendelkezik együttesen SPF-fel, DKIM-mel és érvényesítő DMARC-szabályzattal (az SPF-bevezetési érettségi modell részletezi a létrát). Ennek a javításnak a helyes elvégzése a legnehezebb rész ahhoz, hogy csatlakozzon a 3.87%-hoz.

Gyakran ismételt kérdések

A „body hash did not verify” azt jelzi, hogy valaki hamisítja a domainemet? Általában nem — egy hamisító általában egyáltalán nem tudja előállítani az Ön DKIM-aláírását, tehát a levele aláírás nélkül jelenik meg, vagy no key értékkel. Egy sikertelen törzskivonat azt jelenti, hogy egy, az Ön infrastruktúrája által jogszerűen aláírt üzenet szállítás után szerkesztve lett. Ellenőrizze a saját átjáróját, mielőtt támadóra gyanakszik.

Az SPF átmegy ezeken az üzeneteken — még mindig oké vagyok? Egyelőre talán: a DMARC-nak csak egy igazított átmenet kell. De az SPF átmenete eltűnik, amint bárki továbbítja az üzenetet, és ha nem igazodik a Feladó domainjéhez, a DMARC-hoz egyébként sem számított. Csupán a 3.87% domainnel, amely a teljes hármast tartja (2026-06-29 népszámlálás, 261,086,232 domain), az „egyik igazítás sántít” az átlagos állapot — és a javítható.

A relaxed/relaxed kanonizációra való áttérés megoldja a nyilatkozati problémámat? Nem. A relaxed csak a szóköz- és sorköz-változásokat tolerálja. Egy hozzáfűzött nyilatkozat tartalmi változás, és a kivonatnak meg kell buknia emiatt — ez a DKIM helyes működése. Helyezze át az aláírási pontot vagy a nyilatkozatot.

A hiba csak az egyik ügyfél domainjénél fordul elő. Miért? Az ő oldaluk szinte biztosan módosítja a bejövő leveleket — egy biztonsági berendezés, amely átírja a hivatkozásokat vagy szalagcímeket ad hozzá az ellenőrzőjük futtatása előtt, vagy egy belső továbbítás, amely újrakódolja a törzset. Küldje el nekik az oldal diagnosztikai szakaszát; a javítás az ő átjárójukon van, nem az Ön DNS-ében.

Küldje el a tulajdonosnak a jelentést

Ha egy ügyfélért vagy munkaadójáért végzi a javítást, zárja le a kört bizonyítékkal. Amint a módosító ugrópontot javította, futtassa újra az ingyenes vizsgálatot, és küldje el az értékelt jelentést a vállalkozás tulajdonosának: keltezve, közérthető nyelven, a DKIM és a DMARC egyetlen oldalon zölden. Ez az a dokumentum, amelyre szüksége lesz a kibervédelmi biztosítás megújításakor és a következő szállítói kérdőívnél — annak bizonyítéka, hogy a vállalattól kimenő levél most az a levél, amely megérkezik.

Ellenőrizze a domainjét → · „DKIM signature not valid” útmutató → · DKIM javítása → · Hogyan értékelünk → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.