DKIM «Body Hash Did Not Verify» — hva endret meldingen din, og hvordan fikser du det (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

«Body hash did not verify» betyr at DKIM-signaturen var gyldig da meldingen forlot deg — og noe omskrev meldingskroppen etterpå. Signaturen er ikke ødelagt; meldingen ble modifisert under transport. Bare 3.87% av domener — 10,092,481 — fullfører den fulle SPF-DKIM-DMARC-triaden, ifølge Defaults.Exposed-sensus over 261,086,232 domener (2026-06-29).

Fiksen er en jakt, og deretter en beslutning. Finn hoppet som modifiserer e-posten din — en gateway som legger til en ansvarsfraskrivelse, en appliance som skriver om lenker, en e-postliste som legger til en bunntekst. Signer deretter etter det hoppet, stopp modifikasjonen, eller gjør signaturen tolerant for det — i den rekkefølgen.

Hva betyr «body hash did not verify» egentlig?

En DKIM-signatur (RFC 6376) bærer to hasher: bh=, en hash av meldingskroppen som signert, og b=, som signerer overskriftene pluss den body-hashen. Bekreftelsesinstansen omberegner body-hashen fra meldingen den mottok; hvis den ikke samsvarer med bh=, stopper bekreftelsen med strengen alle limer inn i en søkeboks — en mottaker-overskrift som:

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

Det er Microsofts dokumenterte årsaksstreng; Gmail gjengir ofte den samme diagnosen som dkim=neutral (body hash did not verify). Uansett innsnevrer dommen problemet enormt. DNS-nøkkelen din, velgeren og signeringskonfigurasjonen er alle i orden. Kryptografien gjorde jobben sin: kroppen endret seg mellom signering og bekreftelse — én vedlagt linje, én omskrevet URL, ett re-kodet tegn er nok. (En annen melding — signature did not verify, no key for signature — betyr en annen feil; start med «DKIM-signatur ikke gyldig».) Og det haster fordi en mislykket signatur ikke kan gi DMARC et justert pass: med mindre SPF bestås med justering på den samme meldingen, feiler e-posten DMARC helt.

Hva endret meldingen? De vanlige mistenkte

Noe i leveringsstien redigerte kroppen etter at signereren forseglet den. I praksis er det en av fire ting:

Hvem modifiserte den	Hva de endrer	Typisk kjennetegn
Utgående gateway / smart host (Exchange-transportregler, Mimecast, Proofpoint, Barracuda…)	Legger til den juridiske ansvarsfraskrivelsen, markedsføringsbunnteksten, eller «EKSTERN:»-banneret etter at e-postserveren allerede har signert	Alle meldinger på den ruten feiler; direktesendte som omgår gatewayen består
Sikkerhetsappliance / lenke-beskyttelse	Skriver om URL-er til skanneredigeringer, legger til sporingsomslag	Bare meldinger som inneholder lenker feiler
E-postliste (Google Groups, Mailman…)	Legger til emnemerke og listebunntekst, omflyter noen ganger kroppen	Bare e-post sendt gjennom listen feiler
Videresender / relé som re-koder MIME	Transkoder tegnsett, ombryter linjer — usynlig for et menneske, fatal for en hash	Feil samles på én mottaker eller videresendingsadresse

Sjekk den uthevede raden først — e-postserveren signerer, kantenheten redigerer, og alle meldinger forlater med en signatur som var sann i tretti millisekunder.

Hvordan finner jeg hoppet som modifiserer e-posten min?

Differensialdiagnose — sammenlign en sti som fungerer mot stien som feiler:

Send en direkte testmelding til en postkasse du kontrollerer hos en stor mottaker (Gmail fungerer godt), som omgår så mye av den utgående kjeden din som mulig.
Send en ny melding langs den sviktende stien — gjennom gatewayen, gjennom listen, til den berørte mottakerens domene.
Sammenlign Authentication-Results-linjene i begge fulle overskrifter. Direktesendt dkim=pass, sviktende sti dkim=fail (eller dkim=neutral) med body hash did not verify: modifisereren bor mellom de to rutene.
Se på den mottatte kroppen: en ansvarsfraskrivelse, et banner eller en bunntekst du ikke skrev? Lenker omskrevet til et skanne-domene? Det er hoppet ditt, navngitt — og Received:-kjeden viser hvilket relé som bare dukker opp i den sviktende stien.

DMARC-samlede rapporter forteller samme historie i stor skala: en kilde som konsekvent rapporterer DKIM-feil med SPF-pass er vanligvis en modifikasjon under transport på din egen rute, ikke en angriper.

Hvordan fikser jeg det?

Kjør den gratis skanningen på defaults.exposed før du rører noe. Den bekrefter at de publiserte DKIM-nøklene og DMARC-policyen er i orden, slik at du feilsøker det ene reelle problemet — modifikasjonen — og ikke jakter spøkelser i DNS. Siden fiks DKIM dekker postsiden sjekker.
Signer etter det modifiserende hoppet. Den arkitektonisk korrekte fiksen: flytt DKIM-signering til den ytterste enheten som berører meldingen. Exchange-pluss-gateway-oppsett bør signere ved gatewayen (Mimecast, Proofpoint og likestilte støtter det alle) og deaktivere signering oppstrøms. Hvis Google Workspace eller Microsoft 365 er ditt siste hopp, signer der og la ingenting redigere e-post etter det — se sett opp DKIM på Google Workspace eller Microsoft 365.
Eller stopp modifikasjonen. Ta redigeringen ut av transportstien: ansvarsfraskrivelse i klientsignaturen eller malen i stedet for en transportregel; «EKSTERN:»-banner avgrenset til kun innkommende e-post (å merke din egen utgående e-post som ekstern er en feilkonfigurasjon to ganger over); autentisert utgående e-post unntatt fra omskriving av lenker.
Bruk relaxed/relaxed canonicalization (c=relaxed/relaxed). simple body-canonicalization feiler på en eneste ombrutt linje; relaxed tåler mellomrom- og linjeavslutningsendringer. Vær ærlig om grensen: relaxed tilgir formattering, aldri innhold — en vedlagt bunntekst feiler fortsatt, slik den bør.
Test begge stier på nytt, og skann deretter på nytt. Begge ruter bør nå vise dkim=pass med domenet ditt i d=, og skannerapporten bør være ren.

Bør jeg bruke l=-taggen for å få DKIM til å ignorere vedlagt innhold?

Nei — og vær skeptisk til enhver veiledning som foreslår det. l=-taggen hasher bare de første N bytene av kroppen, slik at en vedlagt bunntekst ikke lenger bryter signaturen. Det «fungerer» ved å la slutten av meldingen din være usignert: hvem som helst som holder en legitimt signert melding kan vedlegge vilkårlig innhold og den gyldige signaturen din bekrefter fortsatt over resultatet. Det er et forfalskningshull i en fiks sin klesdrakt — praktisk misbruk er demonstrert, og noen mottakere straffer eller ignorerer l= av nøyaktig denne grunnen. Løs modifikasjonen; ikke signere bort en del av e-posten din.

Hva med e-postlister — kan jeg fikse de?

Stort sett nei — og å vite det sparer deg uker. En liste som legger til et emnemerke eller en bunntekst bryter body-hashen din ved design, og du kontrollerer ikke listen. To ting hjelper:

Denne resten er nøyaktig grunnen til at DMARC-utrulling er trinnvis. Å flytte fra p=none gjennom p=quarantine med en pct=-rampe, mens du leser samlede rapporter, betyr at liste-manglete meldinger settes i karantene i stedet for å ødelegges mens du vurderer påvirkningen — emnet for fra p=none til p=reject uten å miste legitim e-post.
ARC er mottakerens mekanisme, ikke din. Authenticated Received Chain lar listen bekrefte hvordan autentisering så ut ved ankomst og mottakeren bestemme om de skal stole på det. Det er ingenting for deg, avsenderen, å konfigurere. Godt drevne lister begrenser ved å skrive om Fra-overskriften; dårlig drevne bryter bare e-posten din.

Videresending er det tilstøtende tilfellet — det bryter pålitelig SPF men bare noen ganger DKIM, noe som er grunnen til at justert DKIM er ditt videresendingssikre ben når kroppen overlever: se videresendt e-post feiler SPF — hvorfor du ikke kan fikse det.

Hvorfor bryter DKIM så ofte når så få domener har hele stakken?

Fordi DKIM er det skjøre midtbarnet i triaden: SPF er en statisk DNS-post, DMARC en policyerklæring, men DKIM må overleve reisen. Bare 51.84% av graderte domener publiserer en oppdagbar DKIM-nøkkel i DNS overhodet, ifølge Defaults.Exposed-sensus, og bare 10,092,481 domener — 3.87% av 261,086,232 graderte — holder SPF, DKIM og en håndhevende DMARC-policy samlet (SPF-adopsjonens modenhetsmodell bryter ned stigen). Å få denne fiksen riktig er den vanskeligste delen av å bli med i det 3.87%.

Ofte stilte spørsmål

Er «body hash did not verify» et tegn på at noen forfalsker domenet mitt? Vanligvis ikke — en svindler kan typisk ikke produsere DKIM-signaturen din overhodet, så e-posten deres viser ingen signatur eller no key. En mislykket body-hash betyr at en melding genuint signert av infrastrukturen din ble redigert etterpå. Sjekk din egen gateway før du antar en angriper.

SPF bestås på disse meldingene — er jeg fortsatt OK? Foreløpig, kanskje: DMARC trenger bare ett justert pass. Men SPF-beståelsen fordamper i det øyeblikket noen videresender meldingen, og hvis den ikke er justert til Fra-domenet ditt telte den aldri for DMARC uansett. Med bare 3.87% av domener som holder hele triaden (2026-06-29-sensus av 261,086,232 domener), er «ett ben haltende» normaltilstanden — og den fixerbare.

Vil bytte til relaxed/relaxed canonicalization fikse problemet mitt med ansvarsfraskrivelse? Nei. Relaxed tåler bare mellomrom- og linjebryteendringer. En vedlagt ansvarsfraskrivelse er en innholdsendring, og hashen må feile på den — det er DKIM som fungerer korrekt. Flytt signeringspunktet eller flytt ansvarsfraskrivelsen.

Feilen skjer bare hos én kundes domene. Hvorfor? Deres side modifiserer nesten sikkert innkommende e-post — en sikkerhetsappliance som skriver om lenker eller stempel bannere før bekreftelsesinstansen kjører, eller en intern videresendt re-koder kroppen. Send dem diagnosedelen på denne siden; fiksen er på deres gateway, ikke i din DNS.

Send eieren rapporten

Hvis du fikser dette for en klient eller arbeidsgiveren din, lukk løkken med bevis. Når det modifiserende hoppet er fikset, kjør den gratis skanningen på nytt og videresend den graderte rapporten til bedriftseieren: datert, på enkelt norsk, DKIM og DMARC stående på én side. Det er artefakten de vil trenge til fornyelse av cyberforsikring og neste leverandørsikkerhets-spørreskjema — bevis for at e-posten som forlater selskapet nå er e-posten som ankommer.

Sjekk domenet ditt → · «DKIM-signatur ikke gyldig»-veiledning → · Fiks DKIM → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.