DKIM 'Body Hash Did Not Verify' — wat uw bericht heeft gewijzigd, en hoe u het oplost (2026)

Gepubliceerd 2026-07-08

Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.

“Body hash did not verify” betekent dat uw DKIM-handtekening geldig was toen het bericht bij u vertrok — en dat iets daarna de berichttekst heeft herschreven. De handtekening is niet kapot; het bericht is onderweg gewijzigd. Slechts 3,87% van de domeinen — 10.092.481 — heeft de volledige SPF-DKIM-DMARC-triade compleet, volgens de Defaults.Exposed-census van 261.086.232 domeinen (2026-06-29).

De oplossing is een speurtocht, dan een beslissing. Vind de schakel die uw mail wijzigt — een gateway die een disclaimer toevoegt, een appliance die links herschrijft, een mailinglijst die een voettekst toevoegt. Onderteken vervolgens ná die schakel, stop de wijziging, of maak de handtekening er tolerant voor — in die volgorde.

Wat betekent “body hash did not verify” nu echt?

Een DKIM-handtekening (RFC 6376) draagt twee hashes: bh=, een hash van de berichttekst zoals ondertekend, en b=, die de headers plus die body-hash ondertekent. De verifier berekent de body-hash opnieuw op basis van het ontvangen bericht; komt die niet overeen met bh=, dan stopt de verificatie met de tekst die iedereen in een zoekmachine plakt — een ontvanger-header zoals:

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

Dat is de gedocumenteerde reden-string van Microsoft; Gmail toont dezelfde diagnose vaak als dkim=neutral (body hash did not verify). Hoe dan ook: het oordeel verkleint het probleem enorm. Uw DNS-sleutel, selector en ondertekeningsconfiguratie zijn allemaal in orde. De cryptografie deed haar werk: de tekst is gewijzigd tussen ondertekening en verificatie — één toegevoegde regel, één herschreven URL, één opnieuw gecodeerd teken is genoeg. (Een andere melding — signature did not verify, no key for signature — betekent een ander falen; begin dan bij “DKIM signature not valid”.) En het is urgent omdat een gefaalde handtekening DMARC geen gealigneerde pass kan geven: tenzij SPF met alignment slaagt op hetzelfde bericht, faalt de mail zonder meer op DMARC.

Wat heeft uw bericht gewijzigd? De gebruikelijke verdachten

Iets in het bezorgpad heeft de tekst bewerkt nadat uw ondertekenaar deze had verzegeld. In de praktijk is het een van vier dingen:

Wie heeft het gewijzigd	Wat ze veranderen	Typisch kenmerk
Uitgaande gateway / smart host (Exchange-transportregels, Mimecast, Proofpoint, Barracuda…)	Voegt de juridische disclaimer, marketingvoettekst of “EXTERNAL:“-banner toe nadat de mailserver al heeft ondertekend	Elk bericht op die route faalt; directe verzendingen die de gateway omzeilen slagen
Security-appliance / linkbescherming	Herschrijft URL’s naar scanning-redirects, voegt tracking-wrappers toe	Alleen berichten met links falen
Mailinglijst (Google Groups, Mailman…)	Voegt een onderwerptag en lijstvoettekst toe, herschikt soms de tekst	Alleen mail via de lijst faalt
Forwarder / relay die MIME hercodeert	Zet tekensets om, herverpakt regels — onzichtbaar voor een mens, fataal voor een hash	Fouten clusteren bij één ontvanger of doorstuuradres

Controleer eerst de vetgedrukte rij — de mailserver ondertekent, het edge-apparaat bewerkt, en elk bericht vertrekt met een handtekening die dertig milliseconden lang waar was.

Hoe vind ik de schakel die mijn mail wijzigt?

Differentiaaldiagnose — vergelijk een route die werkt met de route die faalt:

Stuur een direct testbericht naar een mailbox die u beheert bij een grote ontvanger (Gmail werkt goed), waarbij u zo veel mogelijk van uw uitgaande keten omzeilt.
Stuur een tweede bericht langs de falende route — via de gateway, via de lijst, naar het domein van de getroffen ontvanger.
Vergelijk de Authentication-Results-regels in beide volledige headers. Directe verzending dkim=pass, falende route dkim=fail (of dkim=neutral) met body hash did not verify: de wijziger zit tussen die twee routes in.
Kijk naar de ontvangen tekst: een disclaimer, banner of voettekst die u niet hebt getypt? Links herschreven naar een scanning-domein? Dat is uw schakel, bij naam genoemd — en de Received:-keten toont welke relay alleen in de falende route voorkomt.

Uw DMARC-aggregaatrapporten vertellen hetzelfde verhaal op schaal: een bron die consequent DKIM fail met SPF pass rapporteert, is meestal wijziging-onderweg op uw eigen route, geen aanvaller.

Hoe los ik het op?

Voer de gratis scan uit op defaults.exposed voordat u iets aanraakt. Die bevestigt dat uw gepubliceerde DKIM-sleutels en DMARC-beleid in orde zijn, zodat u het ene echte probleem debugt — de wijziging — en geen spoken najaagt in DNS. De pagina repareer DKIM behandelt de controles aan de recordkant.
Onderteken ná de wijzigende schakel. De architectonisch juiste oplossing: verplaats DKIM-ondertekening naar het buitenste apparaat dat het bericht aanraakt. Organisaties met Exchange plus gateway moeten bij de gateway ondertekenen (Mimecast, Proofpoint en soortgenoten ondersteunen het allemaal) en ondertekening stroomopwaarts uitschakelen. Is Google Workspace of Microsoft 365 uw laatste schakel, onderteken dan daar en laat niets de mail daarna nog bewerken — zie DKIM instellen op Google Workspace of Microsoft 365.
Of stop de wijziging. Haal de bewerking uit het transportpad: de disclaimer in de clienthandtekening of het sjabloon in plaats van in een transportregel; de “EXTERNAL:“-banner beperkt tot uitsluitend inkomende mail (uw eigen uitgaande mail als extern taggen is een dubbele misconfiguratie); geauthenticeerde uitgaande mail uitgezonderd van link-herschrijving.
Gebruik relaxed/relaxed-canonicalisatie (c=relaxed/relaxed). simple-body-canonicalisatie faalt al op één opnieuw afgebroken regel; relaxed tolereert wijzigingen in witruimte en regeleinden. Wees eerlijk over de grens: relaxed vergeeft opmaak, nooit inhoud — een toegevoegde voettekst faalt nog steeds, zoals het hoort.
Test beide routes opnieuw, scan daarna opnieuw. Beide routes moeten nu dkim=pass tonen met uw domein in d=, en het scanrapport moet schoon zijn.

Moet ik de l=-tag gebruiken zodat DKIM toegevoegde inhoud negeert?

Nee — en wantrouw elke gids die het aanraadt. De l=-tag hasht alleen de eerste N bytes van de tekst, zodat een toegevoegde voettekst de handtekening niet meer breekt. Het “werkt” door het einde van uw bericht onondertekend te laten: iedereen die een legitiem ondertekend bericht in handen heeft, kan er willekeurige inhoud aan toevoegen en uw geldige handtekening verifieert nog steeds over het resultaat. Dat is een spoofing-gat in de kleren van een oplossing — praktisch misbruik is aangetoond, en sommige ontvangers bestraffen of negeren l= om precies deze reden. Los de wijziging op; onderteken niet een deel van uw mail weg.

En mailinglijsten — kan ik die repareren?

Meestal niet — en dat weten bespaart u weken. Een lijst die een onderwerptag of voettekst toevoegt, breekt uw body-hash per definitie, en u beheert de lijst niet. Twee dingen helpen:

Dit residu is precies waarom DMARC-uitrol gefaseerd verloopt. Van p=none via p=quarantine met een pct=-opbouw, terwijl u aggregaatrapporten leest, betekent dat door lijsten verminkte berichten in quarantaine gaan in plaats van vernietigd worden terwijl u de impact beoordeelt — het onderwerp van van p=none naar p=reject zonder legitieme e-mail te verliezen.
ARC is het mechanisme van de ontvanger, niet het uwe. Authenticated Received Chain laat de lijst verklaren hoe de authenticatie er bij aankomst uitzag en laat de ontvanger beslissen of die dat vertrouwt. Er valt voor u, de verzender, niets te configureren. Goed beheerde lijsten mitigeren door de From-header te herschrijven; slecht beheerde breken uw mail gewoon.

Doorsturen is het aangrenzende geval — het breekt SPF betrouwbaar maar DKIM slechts soms, en daarom is gealigneerde DKIM uw doorstuurbestendige poot wanneer de tekst intact blijft: zie doorgestuurde e-mail faalt op SPF — waarom u het niet kunt repareren.

Waarom breekt DKIM zo vaak terwijl zo weinig domeinen überhaupt de volledige stack hebben?

Omdat DKIM het kwetsbare middelste kind van de triade is: SPF is een statisch DNS-record, DMARC een beleidsverklaring, maar DKIM moet de reis overleven. Slechts 51,84% van de beoordeelde domeinen publiceert überhaupt een vindbare DKIM-sleutel in DNS, volgens de Defaults.Exposed-census, en slechts 10.092.481 domeinen — 3,87% van de 261.086.232 beoordeelde — hebben SPF, DKIM én een afdwingend DMARC-beleid samen (het SPF-adoptievolwassenheidsmodel ontleedt die ladder). Deze fix goed uitvoeren is het moeilijkste deel van toetreden tot die 3,87%.

Veelgestelde vragen

Is “body hash did not verify” een teken dat iemand mijn domein spooft? Meestal niet — een spoofer kan uw DKIM-handtekening doorgaans helemaal niet produceren, dus diens mail toont geen handtekening of no key. Een gefaalde body-hash betekent dat een bericht dat echt door uw infrastructuur is ondertekend, achteraf is bewerkt. Controleer uw eigen gateway voordat u een aanvaller vermoedt.

SPF slaagt op deze berichten — zit ik dan nog goed? Voorlopig misschien: DMARC heeft maar één gealigneerde pass nodig. Maar de pass van SPF verdampt zodra iemand het bericht doorstuurt, en als die niet is gealigneerd met uw From-domein telde die voor DMARC toch al niet. Met slechts 3,87% van de domeinen met de volledige triade (census van 261.086.232 domeinen, 2026-06-29) is “één poot mank” de normale toestand — en de oplosbare.

Lost overschakelen op relaxed/relaxed-canonicalisatie mijn disclaimerprobleem op? Nee. Relaxed tolereert alleen wijzigingen in witruimte en regelafbreking. Een toegevoegde disclaimer is een inhoudswijziging, en de hash moet daarop falen — dat is DKIM dat correct werkt. Verplaats het ondertekeningspunt of verplaats de disclaimer.

Het falen treedt alleen op bij het domein van één klant. Waarom? Hun kant wijzigt vrijwel zeker inkomende mail — een security-appliance die links herschrijft of banners stempelt voordat hun verifier draait, of een interne doorstuur die de tekst hercodeert. Stuur ze het diagnosegedeelte van deze pagina; de fix zit op hun gateway, niet in uw DNS.

Stuur de eigenaar het rapport

Als u dit oplost voor een klant of uw werkgever, sluit dan de cirkel met bewijs. Zodra de wijzigende schakel is gerepareerd, voert u de gratis scan opnieuw uit en stuurt u het beoordeelde rapport door naar de bedrijfseigenaar: gedateerd, in gewone taal, DKIM- en DMARC-status op één pagina. Het is het bewijsstuk dat ze nodig hebben voor de cyberverzekeringsverlenging en de volgende leveranciersvragenlijst — bewijs dat de mail die het bedrijf verlaat nu de mail is die aankomt.

Controleer uw domein → · Gids “DKIM signature not valid” → · Repareer DKIM → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.