DKIM "Body hash did not verify" — Vad som ändrade ditt meddelande och hur du åtgärdar det (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

“Body hash did not verify” betyder att din DKIM-signatur var giltig när meddelandet lämnade dig — och något skrev om meddelandekroppen efteråt. Signaturen är inte bruten; meddelandet ändrades under transit. Bara 3.87% av domänerna — 10,092,481 — slutför den fullständiga SPF-DKIM-DMARC-triaden, enligt Defaults.Exposed-censuset med 261,086,232 domäner (2026-06-29).

Fixen är en jakt, sedan ett beslut. Hitta hoppet som modifierar din e-post — en gateway som lägger till en ansvarsfriskrivning, en apparat som skriver om länkar, en e-postlista som lägger till en sidfot. Signera sedan efter det hoppet, stoppa modifieringen, eller gör signaturen tolerant mot den — i den ordningen.

Vad betyder “body hash did not verify” egentligen?

En DKIM-signatur (RFC 6376) bär två hashar: bh=, en hash av meddelandets kropp som signerad, och b=, som signerar rubrikerna plus den body-hashen. Verifieraren beräknar om body-hashen från meddelandet den tog emot; om den inte matchar bh= avslutas verifiering med strängen alla klistrar in i en sökruta — en mottagarubrik som:

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

Det är Microsofts dokumenterade orsakssträng; Gmail renderar ofta samma diagnos som dkim=neutral (body hash did not verify). Hur som helst begränsar domet problemet enormt. Din DNS-nyckel, selektor och signeringskonfiguration är alla fine. Kryptografin gjorde sitt jobb: kroppen ändrades mellan signering och verifiering — en tillagd rad, en omskriven URL, ett omkodat tecken räcker. (Ett annat meddelande — signature did not verify, no key for signature — betyder ett annat fel; börja med “DKIM-signatur ogiltig”.) Och det är brådskande eftersom en misslyckad signatur inte kan ge DMARC ett anpassat godkännande: om inte SPF godkänns med anpassning på samma meddelande misslyckas e-posten med DMARC helt.

Vad ändrade ditt meddelande? De vanliga misstänkta

Något i leveransvägen redigerade kroppen efter att din undertecknare förseglade den. I praktiken är det en av fyra saker:

Vem modifierade det	Vad de ändrar	Typiskt kännetecken
Utgående gateway / smart host (Exchange-transportregler, Mimecast, Proofpoint, Barracuda…)	Lägger till den juridiska ansvarsfriskrivningen, marknadsföringssidfoten eller “EXTERNAL:“-bannern efter att e-postservern redan signerat	Varje meddelande på den rutten misslyckas; direkta sändningar som kringgår gatewayen godkänns
Säkerhetsapparat / länkskydd	Skriver om URL:er till skannerredirects, lägger till spårningsomslagare	Bara meddelanden som innehåller länkar misslyckas
E-postlista (Google Groups, Mailman…)	Lägger till en ämnestag och listsidfot, ibland omflödar kroppen	Bara e-post skickad via listan misslyckas
Vidarebefordrare / relä-omkodning av MIME	Transkodningsstandarder, omsluter rader — osynlig för en människa, dödlig för en hash	Misslyckanden klustrar hos en mottagare eller vidarebefordringsadress

Kontrollera den fetstilta raden först — e-postservern signerar, kantenheten redigerar, och varje meddelande lämnar med en signatur som var sann i trettio millisekunder.

Hur hittar jag hoppet som modifierar min e-post?

Differentialdiagnos — jämför en sökväg som fungerar mot sökvägen som misslyckas:

Skicka ett direkt testmeddelande till en postlåda du kontrollerar hos en stor mottagare (Gmail fungerar bra), och kringgår så mycket av din utgående kedja du kan.
Skicka ett andra meddelande längs den misslyckande vägen — via gatewayen, via listan, till den drabbade mottagarens domän.
Jämför Authentication-Results-raderna i båda fullständiga rubrikerna. Direkt sändning dkim=pass, misslyckande väg dkim=fail (eller dkim=neutral) med body hash did not verify: modifieraren bor mellan dessa två rutter.
Titta på den mottagna kroppen: en ansvarsfriskrivning, banner eller sidfot du inte skrivit? Länkar omskrivna till en skannerdomän? Det är ditt hopp, namngivet — och Received:-kedjan visar vilket relä som bara visas i den misslyckande sökvägen.

Dina DMARC-aggregerade rapporter berättar samma historia i stor skala: en källa som konsekvent rapporterar DKIM-misslyckande med SPF-godkännande är vanligtvis modifiering-under-transit på din egen rutt, inte en angripare.

Hur åtgärdar jag det?

Kör den kostnadsfria sökningen på defaults.exposed innan du rör något. Den bekräftar att dina publicerade DKIM-nycklar och DMARC-policy är sunda, så du felsöker det ena verkliga problemet — modifieringen — utan att jaga spöken i DNS. Sidan åtgärda DKIM täcker postsidans kontroller.
Signera efter det modifierande hoppet. Den arkitektoniskt korrekta fixen: flytta DKIM-signering till den yttersta enheten som rör meddelandet. Exchange-plus-gateway-installationer bör signera vid gatewayen (Mimecast, Proofpoint och liknande stöder det alla) och inaktivera signering uppströms. Om Google Workspace eller Microsoft 365 är ditt sista hopp, signera där och låt ingenting redigera e-post efter det — se konfigurera DKIM på Google Workspace eller Microsoft 365.
Eller stoppa modifieringen. Ta bort redigeringen från transportvägen: ansvarsfriskrivning i klientsignaturen eller mallen istället för en transportregel; “EXTERNAL:“-banner begränsad till enbart inkommande e-post (att tagga din egen utgående e-post som extern är en felkonfiguration dubbelt om); autentiserad utgående e-post undantagen från länkomskrivning.
Använd relaxed/relaxed-kanonisering (c=relaxed/relaxed). simple body-kanonisering misslyckas på en enda omslagen rad; relaxed tolererar blanksteg och radsluts ändringar. Var ärlig om gränsen: relaxed förlåter formatering, aldrig innehåll — en tillagd sidfot misslyckas fortfarande, som den borde.
Testa om båda vägarna, scanna sedan om. Båda rutterna bör nu visa dkim=pass med din domän i d=, och skanrapporten bör vara ren.

Ska jag använda l=-taggen för att få DKIM att ignorera tillagt innehåll?

Nej — och var misstänksam mot alla guider som föreslår det. l=-taggen hashar bara de första N byten av kroppen, så en tillagd sidfot bryter inte längre signaturen. Det “fungerar” genom att lämna slutet av ditt meddelande osignerat: vem som helst som håller ett legitimt signerat meddelande kan lägga till godtyckligt innehåll och din giltiga signatur verifieras fortfarande över resultatet. Det är ett spoofing-hål klädd i en fixs kläder — praktiskt missbruk har demonstrerats, och vissa mottagare straffar eller ignorerar l= exakt av den anledningen. Lös modifieringen; unsignera inte en del av din e-post.

Vad sägs om e-postlistor — kan jag åtgärda dem?

Mestadels nej — och att veta det sparar dig veckor. En lista som lägger till en ämnestag eller sidfot bryter din body-hash med avsikt, och du kontrollerar inte listan. Två saker hjälper:

Den här återstoden är exakt varför DMARC-utrullning sker stegvis. Att flytta från p=none genom p=quarantine med en pct=-upptrappning, medan du läser aggregerade rapporter, innebär att listförvanskat meddelanden hamnar i karantän snarare än att förstöras medan du bedömer konsekvenserna — ämnet för från p=none till p=reject utan att förlora legitim e-post.
ARC är mottagarens mekanism, inte din. Authenticated Received Chain låter listan intyga hur autentisering såg ut vid ankomst och mottagaren besluta om man kan lita på det. Det finns ingenting för dig, avsändaren, att konfigurera. Välskötta listor mildrar genom att skriva om From-rubriken; dåligt skötta bryter bara din e-post.

Vidarebefordring är det angränsande fallet — det bryter tillförlitligt SPF men bara ibland DKIM, vilket är varför anpassad DKIM är ditt vidarebefordringsäkra ben när kroppen överlever: se vidarebefordrad e-post misslyckas med SPF — varför du inte kan åtgärda det.

Varför bryter DKIM så ofta när så få domäner ens har hela stacken?

Eftersom DKIM är det bräckliga mellanbarn av triaden: SPF är en statisk DNS-post, DMARC ett policyuttryck, men DKIM måste överleva resan. Bara 51.84% av graderade domäner publicerar en synlig DKIM-nyckel i DNS överhuvudtaget, enligt Defaults.Exposed-censuset, och bara 10,092,481 domäner — 3.87% av 261,086,232 graderade — håller SPF, DKIM och en tillämpad DMARC-policy tillsammans (SPF-adoptionsmognadsmodellen bryter stegen ner). Att göra den här fixen rätt är den svåraste delen av att gå med i de 3.87%.

Vanliga frågor

Är “body hash did not verify” ett tecken på att någon förfalskar min domän? Vanligtvis inte — en bedragare kan typiskt inte producera din DKIM-signatur alls, så deras e-post visar ingen signatur eller no key. En misslyckad body-hash betyder att ett meddelande genuint signerat av din infrastruktur redigerades efteråt. Kontrollera din egen gateway innan du antar en angripare.

SPF godkänns på dessa meddelanden — är jag fortfarande okej? För tillfället, kanske: DMARC behöver bara ett anpassat godkännande. Men SPF:s godkännande försvinner det ögonblick någon vidarebefordrar meddelandet, och om det inte är anpassat till din From-domän räknades det aldrig för DMARC ändå. Med bara 3.87% av domänerna som håller den fullständiga triaden (2026-06-29-censuset med 261,086,232 domäner) är “ett ben haltande” normaltillståndet — och det åtgärdbara.

Kommer byte till relaxed/relaxed-kanonisering att åtgärda mitt ansvarsfriskrivningsproblem? Nej. Relaxed tolererar bara blanksteg och radomslagningsändringar. En tillagd ansvarsfriskrivning är en innehållsändring, och hashen måste misslyckas på den — det är DKIM som fungerar korrekt. Flytta signeringspunkten eller flytta ansvarsfriskrivningen.

Misslyckandet händer bara hos en kunds domän. Varför? Deras sida modifierar nästan säkert inkommande e-post — en säkerhetsapparat som skriver om länkar eller stämplar banners innan deras verifierare körs, eller en intern vidarebefordran som kodar om kroppen. Skicka dem den här sidan diagnostikavsnitt; fixen är på deras gateway, inte i din DNS.

Skicka ägaren rapporten

Om du åtgärdar detta för en kund eller din arbetsgivare, avsluta loopen med bevis. När det modifierande hoppet är åtgärdat, kör om den kostnadsfria sökningen och vidarebefordra den graderade rapporten till företagsägaren: daterad, klarspråk, DKIM och DMARC stående på en sida. Det är artefakten de behöver för förnyelse av cyberförsäkring och nästa leverantörsenkät — bevis på att e-posten som lämnar företaget nu är e-posten som anländer.

Kontrollera din domän → · “DKIM-signatur ogiltig”-guiden → · Åtgärda DKIM → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.