Defaults.Exposed › Rettelser › Guides

DKIM 'Body hash did not verify' — hvad ændrede din besked, og hvordan du retter det (2026)

Udgivet 2026-07-08

Tal fra 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi graderer.

“Body hash did not verify” betyder, at din DKIM-signatur var gyldig, da beskeden forlod dig — og noget omskrev beskedens body bagefter. Signaturen er ikke brækket; beskeden blev ændret under transit. Kun 3.87% af domæner — 10,092,481 — fuldfører den fulde SPF-DKIM-DMARC-triade, ifølge Defaults.Exposed-census over 261,086,232 domæner (2026-06-29).

Løsningen er en jagt, derefter en beslutning. Find det hop, der ændrer din mail — en gateway, der tilføjer en ansvarsfraskrivelse, et apparat, der omskriver links, en mailingliste, der tilføjer en footer. Signér derefter efter det hop, stop ændringen, eller gør signaturen tolerant over for den — i den rækkefølge.

Hvad betyder “body hash did not verify” egentlig?

En DKIM-signatur (RFC 6376) bærer to hashes: bh=, en hash af beskedens body som signeret, og b=, der signerer headerne plus den body-hash. Verifikatoren genberegner body-hashen fra den besked, den modtog; stemmer den ikke overens med bh=, stopper verifikationen med den streng, alle indsætter i en søgemaskine — en modtager-header som:

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

Det er Microsofts dokumenterede årsagsstreng; Gmail gengiver ofte den samme diagnose som dkim=neutral (body hash did not verify). Under alle omstændigheder indsnævrer dommen problemet enormt. Din DNS-nøgle, selektor og signeringskonfiguration er alle fine. Kryptografien gjorde sit arbejde: body’en ændrede sig mellem signering og verifikation — én tilføjet linje, én omskrevet URL, ét gen-kodet tegn er nok. (En anden besked — signature did not verify, no key for signature — betyder en anden fejl; start med “DKIM-signatur ikke gyldig”.) Og det haster, fordi en fejlet signatur ikke kan give DMARC et justeret godkendelsesresultat: medmindre SPF godkendes med justering på den samme besked, fejler mailen DMARC direkte.

Hvad ændrede din besked? De sædvanlige mistænkte

Noget i leveringsforløbet redigerede body’en, efter at din underskriver forseglede den. I praksis er det typisk et af fire ting:

Kontrollér den fremhævede række først — mailserveren signerer, edge-enheden redigerer, og alle beskeder afgår med en signatur, der var sand i tredive millisekunder.

Hvordan finder jeg det hop, der modificerer min mail?

Differentialdiagnose — sammenlign en rute, der virker, med den rute, der fejler:

1. Send en direkte testbesked til en postkasse, du kontrollerer, hos en stor modtager (Gmail fungerer godt), uden om så meget af din udgående kæde som muligt.
2. Send en anden besked ad den fejlende rute — via gatewayen, via listen, til det berørte modtagerdomæne.
3. Sammenlign Authentication-Results-linjerne i begge fulde headere. Direkte afsendelse dkim=pass, fejlende rute dkim=fail (eller dkim=neutral) med body hash did not verify: modifikatoreren befinder sig mellem disse to ruter.
4. Se på den modtagne body: en ansvarsfraskrivelse, et banner eller en footer, du ikke har skrevet? Links omskrevet til et scanningsdomæne? Det er dit hop, navngivet — og Received:-kæden viser, hvilken relay der kun optræder i den fejlende rute.

Dine DMARC-aggregerede rapporter fortæller den samme historie i stor skala: en kilde, der konsekvent rapporterer DKIM-fejl med SPF-godkendelse, er typisk ændring under transit på din egen rute, ikke en angriber.

Hvordan løser jeg det?

1. Kør den gratis scanning på defaults.exposed inden du rører noget som helst. Den bekræfter, at dine udgivne DKIM-nøgler og DMARC-politik er sunde, så du debugger det ene reelle problem — ændringen — og ikke jager spøgelser i DNS. Siden ret DKIM dækker post-siden.
2. Signér efter det modificerende hop. Den arkitektonisk korrekte løsning: flyt DKIM-signering til den yderste enhed, der rører beskeden. Exchange-plus-gateway-shops bør signere ved gatewayen (Mimecast, Proofpoint og lignende understøtter det alle) og deaktivere signering opstrøms. Hvis Google Workspace eller Microsoft 365 er dit sidste hop, signér der og lad ingenting redigere mail efterfølgende — se opsæt DKIM på Google Workspace eller Microsoft 365.
3. Eller stop ændringen. Tag redigeringen ud af transportforløbet: ansvarsfraskrivelse i klientsignaturen eller skabelonen i stedet for en transportregel; “EKSTERN:“-banner afgrænset til kun indgående mail (at markere din egen udgående mail som ekstern er en fejlkonfiguration to gange); godkendt udgående mail undtaget fra link-omskrivning.
4. Brug relaxed/relaxed-kanonisering (c=relaxed/relaxed). simple body-kanonisering fejler på en enkelt gen-ombrækket linje; relaxed tolererer ændringer i mellemrum og linjeskift. Vær ærlig om begrænsningen: relaxed tilgiver formatering, aldrig indhold — en tilføjet footer fejler stadig, som den skal.
5. Test begge ruter igen, og scan derefter igen. Begge ruter bør nu vise dkim=pass med dit domæne i d=, og scannerapporten bør være ren.

Bør jeg bruge l=-tagget til at få DKIM til at ignorere tilføjet indhold?

Nej — og vær mistænksom over for enhver vejledning, der foreslår det. l=-tagget hasher kun de første N bytes af body’en, så en tilføjet footer ikke længere bryder signaturen. Det “virker” ved at lade slutningen af din besked forblive usigneret: alle, der er i besiddelse af en legitim signeret besked, kan tilføje vilkårligt indhold, og din gyldige signatur verificerer stadig over resultatet. Det er et spoofing-hul i forklædning af en løsning — praktisk misbrug er blevet demonstreret, og nogle modtagere straffer eller ignorerer l= af præcis den grund. Løs ændringen; lad ikke en del af din mail forblive usigneret.

Hvad med mailinglister — kan jeg rette dem?

Mestendels nej — og det at vide det sparer dig for uger. En liste, der tilføjer et emne-tag eller en footer, bryder din body-hash med vilje, og du kontrollerer ikke listen. To ting hjælper:

• Denne rest er præcis grunden til, at DMARC-udrulning er trinvis. At flytte fra p=none via p=quarantine med en pct=-rampe, mens du læser aggregerede rapporter, betyder, at liste-ændrede beskeder sendes til spam i stedet for at blive afvist, mens du vurderer konsekvenserne — emnet i fra p=none til p=reject uden at miste legitim e-mail.
• ARC er modtagerens mekanisme, ikke din. Authenticated Received Chain lader listen attestere, hvordan godkendelse så ud ved ankomst, og modtageren beslutter, om det skal stoles på. Du som afsender har ingenting at konfigurere. Velkørte lister afhjælper ved at omskrive Fra-headeren; dårligt kørte brækker bare din mail.

Videresendelse er det tilstødende tilfælde — det bryder pålideligt SPF men kun sommetider DKIM, og det er grunden til, at justeret DKIM er dit videresendelsessikre ben, når body’en overlever: se videresendt e-mail fejler SPF — hvorfor du ikke kan rette det.

Hvorfor bryder DKIM så ofte, når så få domæner overhovedet har hele stakken?

Fordi DKIM er det skrøbelige mellembarn i triaden: SPF er en statisk DNS-post, DMARC er en politikerklæring, men DKIM skal overleve rejsen. Kun 51.84% af graderede domæner udgiver en synlig DKIM-nøgle i DNS overhovedet, ifølge Defaults.Exposed-census, og kun 10,092,481 domæner — 3.87% af 261,086,232 graderede — har SPF, DKIM og en håndhævet DMARC-politik tilsammen (SPF-adoptionsmodenheds-modellen bryder stigen ned). At løse denne fejl korrekt er den sværeste del af at tilslutte sig de 3.87%.

Ofte stillede spørgsmål

Er “body hash did not verify” et tegn på, at nogen spoofar mit domæne? Typisk ikke — en spoofer kan normalt slet ikke producere din DKIM-signatur, så deres mail viser ingen signatur eller no key. En mislykket body-hash betyder, at en besked, der rent faktisk er signeret af din infrastruktur, er blevet redigeret bagefter. Kontrollér din egen gateway, inden du antager en angriber.

SPF godkendes på disse beskeder — er jeg stadig okay? For nu, måske: DMARC behøver kun ét justeret godkendelsesresultat. Men SPFs godkendelse forsvinder, så snart nogen videresender beskeden, og er den ikke justeret med dit Fra-domæne, talte den aldrig for DMARC alligevel. Med kun 3.87% af domæner, der har hele triaden (2026-06-29-census over 261,086,232 domæner), er “det ene ben halter” normaltilstanden — og den, der kan løses.

Vil skift til relaxed/relaxed-kanonisering løse mit ansvarsfraskrivelsesproblem? Nej. Relaxed tolererer kun ændringer i mellemrum og linjeskift. En tilføjet ansvarsfraskrivelse er en indholdsændring, og hashen skal fejle på den — det er DKIM, der fungerer korrekt. Flyt signeringspunktet eller flyt ansvarsfraskrivelsen.

Fejlen sker kun hos én kundes domæne. Hvorfor? Deres side ændrer højst sandsynligt indgående mail — et sikkerhedsapparat, der omskriver links eller stempler bannere inden deres verifikator kører, eller en intern videresendelse, der gen-koder body’en. Send dem diagnosedelen af denne side; løsningen er på deres gateway, ikke i din DNS.

Send ejeren rapporten

Retter du dette for en klient eller din arbejdsgiver, så afslut med dokumentation. Når det modificerende hop er rettet, skal du køre den gratis scanning igen og videresende den graderede rapport til virksomhedsejeren: dateret, klart sprog, DKIM og DMARC stående på én side. Det er det artefakt, de skal bruge til fornyelse af cyberforsikring og det næste leverandørspørgeskema — bevis for, at den mail, der forlader virksomheden, nu er den mail, der ankommer.

Kontrollér dit domæne → · “DKIM-signatur ikke gyldig”-vejledning → · Ret DKIM → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.