Hoe je de foutmeldingen ‘DKIM-handtekening is ongeldig’ en ‘Hash van de tekst is niet geverifieerd’ kunt verhelpen

Als je de foutmelding „DKIM-handtekening is ongeldig” hebt ontvangen, is er een probleem met je DKIM-configuratie dat moet worden opgelost. Deze fouten zijn meestal te wijten aan een onjuiste DKIM-DNS-recordvermelding, vertragingen bij de DNS-propagatie, fouten tijdens de evaluatie van de DKIM-handtekening of wijzigingen die in het bericht zijn aangebracht nadat het was ondertekend. 

In deze handleiding worden alle oorzaken en hun oplossingen stap voor stap behandeld, met een apart hoofdstuk over de nauw verwante foutmelding „DKIM-signature body hash not verified”, die wijst op een specifiek en zeer eenvoudig op te lossen probleem.

Over DKIM-handtekeningen

DKIM voegt een cryptografische handtekening toe aan de headers van je e-mail, en de ontvangende server vergelijkt die handtekening met een openbare sleutel die in je DNS is gepubliceerd. Als de twee niet overeenkomen, krijg je de foutmelding „DKIM-handtekening is ongeldig”. Voor een uitgebreide uitleg over hoe het protocol werkt, zie onze handleiding over wat DKIM is.

Aangezien de meeste mensen die deze foutmelding krijgen DKIM al hebben ingesteld en alleen hoeven te verhelpen wat niet meer werkt, richt de rest van deze pagina zich op diagnose en oplossingen in plaats van op de basisprincipes.

Wanneer kan DKIM mislukken met de foutmelding „Uw DKIM-handtekening is ongeldig“?

Je krijgt de melding ‘Je DKIM-handtekening is ongeldig’ te zien wanneer de DKIM-authenticatiecontrole mislukt. Dit zijn de meest voorkomende oorzaken:

• Het DKIM-handtekeningdomein en het afzenderdomein komen niet overeen.
• Het DKIM-record met de openbare sleutel dat in het DNS is gepubliceerd, klopt niet.
• Het record met de openbare DKIM-sleutel wordt helemaal niet in het DNS gepubliceerd.
• De server kan de DNS-zone van het domein van de afzender niet bereiken voor het opzoeken van gegevens; dit komt vaak voor bij onbetrouwbare hostingproviders.
• De lengte van de DKIM-sleutel is onvoldoende. Moderne providers verwachten sleutels van 2048 bits, en oudere sleutels van 1024 bits worden steeds minder vertrouwd, terwijl zeer korte sleutels zonder meer worden afgewezen.
• Het bericht is tijdens het automatisch doorsturen gewijzigd.

Al deze problemen, behalve het laatste, zijn technische kwesties die je direct kunt oplossen. Het geval van doorsturen ligt anders, omdat je geen controle hebt over het feit of de server van een ontvanger een compliance-voettekst toevoegt of het bericht op een andere manier herschrijft. Wat gebeurt er dan als die automatisch doorgestuurde berichten niet voldoen aan zowel SPF- en DKIM-controlesniet doorstaan, en je DMARC-beleid is ingesteld op ‘weigeren’?

Vroeger was dit een echt probleem voor ontvangende servers die legitieme maar niet-geverifieerde doorgestuurde e-mail moesten verwerken. De huidige noodoplossing is de Authenticated Received Chain (ARC)-protocol, waarmee elke e-mailserver in de keten de authenticatieresultaten kan vastleggen die hij heeft waargenomen, zodat de uiteindelijke ontvanger nog steeds kan herkennen dat het bericht was geauthenticeerd voordat het doorsturen het wijzigde. ARC was echter altijd al een experimentele tijdelijke oplossing en de sector laat dit nu achter zich. In een afzonderlijk IETF-ontwerp van april 2026 is voorgesteld om ARC te herclassificeren als een historische standaard, omdat de lessen die hieruit zijn getrokken worden geïntegreerd in DKIM2, een nieuwe versie van DKIM die bij de IETF wordt ontwikkeld (draft-ietf-dkim-dkim2-spec) en die het doorsturen binnen het kernprotocol zelf oplost in plaats van er een tweede mechanisme bovenop te plakken. In plaats van ontvangers te vragen te vertrouwen op het verslag van een tussenpersoon over wat deze heeft waargenomen, laat DKIM2 elke schakel in het proces precies vastleggen wat er is gewijzigd in de vorm van een omkeerbaar recept, zodat de verificateur die wijzigingen ongedaan kan maken en de handtekening van de oorspronkelijke afzender opnieuw kan controleren. Dit wordt nog gestandaardiseerd, dus ARC blijft op dit moment de praktische oplossing, maar het is goed om te weten dat er een echte oplossing voor het doorstuurprobleem op komst is.

Hoe los je de foutmelding „DKIM-handtekening is ongeldig” op?

Zelfs als er DKIM-records zijn ingesteld, kan er nog steeds een foutmelding over een ongeldige handtekening verschijnen. Hieronder vind je de oplossingen, afgestemd op elke hierboven genoemde oorzaak.

Oplossing 1: Problemen met onjuiste DKIM-DNS-vermeldingen oplossen

Zodra je het DKIM TXT-record hebt aangemaakt en aan je DNS-configuratie hebt toegevoegd, is een foutmelding over een ongeldige handtekening vaak terug te voeren op een fout in dat record. Om deze te vinden:

• Gebruik de DKIM-lookup om uw record te controleren.

• Voer je domeinnaam en selector in, of laat het veld voor de selector leeg zodat het platform deze automatisch kan detecteren, en klik vervolgens op ‘Controleren’.

• De tool analyseert je DKIM-DNS-vermelding en markeert eventuele fouten in de syntaxis van je record.

Om het record te corrigeren, log je in op cPanel of de DNS-beheerconsole die je gebruikt, open je de ‘Geavanceerde DNS-zone-editor’ onder ‘Domeinen’, selecteer je je domein, ga je naar ‘DNS-records bewerken’, corrigeer je de waarde van het DKIM-record en sla je de wijzigingen op.

Oplossing 2: Wacht tot de vertragingen bij de DNS-propagatie voorbij zijn

Het kan ook zijn dat je direct na het wijzigen van je DNS-instellingen fouten ziet. Dit is normaal: de DNS-propagatie duurt 24 tot 48 uur, en de exacte tijd hangt af van de TTL-waarde die in het record is ingesteld. Geef het een paar dagen de tijd om volledig door te werken, en houd ondertussen de status bij met onze DNS-propagatiechecker.

Oplossing 3: Breng het DKIM-handtekeningdomein weer in overeenstemming met uw verzenddomein

Open de DKIM-Signature-header van een bericht dat niet is goedgekeurd en controleer de d= waarde af tegen je zichtbare ‘Van’-adres. Als deze niet overeenkomen, ondertekent je verzendservice met zijn eigen domein in plaats van dat van jou, waardoor de afstemming wordt verbroken en de controle mislukt. De oplossing is om die service zo te configureren dat deze met jouw domein ondertekent. De meeste e-mailplatforms hebben hiervoor een instelling voor ‘aangepaste DKIM’ of ‘je domein verifiëren’, en in onze handleiding over het instellen van DKIM wordt het proces uitgelegd.

Oplossing 4: Een te korte sleutel opnieuw genereren

Als je provider nog steeds ondertekent met een sleutel van 1024 bits (of korter), genereer deze dan opnieuw met 2048 bits; dit is de huidige standaard die Google en andere grote providers verwachten. Je kunt een nieuw sleutelpaar genereren in de beheerconsole van je ESP of met onze DKIM-generator. Publiceer de nieuwe openbare sleutel in je DNS en controleer of deze correct wordt omgezet met behulp van onze tool voor het opzoeken van DKIM-records.

Oplossing 5: Een DNS-server oplossen die niet bereikbaar is

Als de ontvangende server je DNS niet kan bereiken om de openbare sleutel op te zoeken, mislukt DKIM, hoe goed de rest ook is geconfigureerd. Controleer met een DNS-propagatiechecker of je record bereikbaar is. Als de DNS van je hostingprovider traag of onbetrouwbaar is, kun je overwegen om je DNS-hosting over te zetten naar een gespecialiseerde provider, zoals Cloudflare of Amazon Route 53.

Oplossing 6: Omgaan met berichten die tijdens het automatisch doorsturen zijn gewijzigd

Wijzigingen bij het doorsturen verstoren DKIM, en er is niet altijd een oplossing aan de kant van de afzender. Als u de doorstuurserver beheert, schakel dan ARC-ondertekening in (en voeg in Microsoft 365 betrouwbare doorstuurdiensten toe aan uw lijst met vertrouwde ARC-ondertekenaars in Defender), zodat legitieme doorgestuurde e-mail niet wordt verwijderd. Als u geen controle hebt over de server, is dit het verwachte gedrag en geen verkeerde configuratie: uw DMARC-aggregatrapporten zullen deze fouten weergeven, en de juiste aanpak is om hiermee rekening te houden in uw beleid en te blijven monitoren in plaats van iedereen achterna te zitten.

Note: ARC is a temporary fix and not a permanent solution. DKIM2 is being designed to fix forwarding at the protocol level, so this whole category of failure should shrink as it rolls out. Keep any existing ARC setup running to support legacy gateways in the meantime, but there's little reason to invest heavily in new ARC engineering now.

Waarom staat er "DKIM-handtekening body hash niet geverifieerd"?

De foutmelding „DKIM-signature body hash not verified” betekent dat de body-hash die de ontvangende server berekent, niet overeenkomt met de waarde die is opgeslagen in de `bh=`-tag van de DKIM-Signature-header. Simpel gezegd: de tekst van de e-mail die de ontvanger heeft gecontroleerd, is niet identiek aan de tekst die jouw server heeft ondertekend. Er is tussentijds iets veranderd aan het bericht.

Het is de moeite waard om dit goed te begrijpen, want het komt frustrerend vaak voor en het betekent meestal dat je DKIM-configuratie verder wel correct is. De controle van de hash van de body vindt plaats vóór de volledige controle van de handtekening, dus als de hash van de body niet klopt, mislukt de hele DKIM-evaluatie en gaat de ontvanger niet eens verder met het verifiëren van de cryptografische handtekening zelf.

Veelvoorkomende oorzaken van storingen in de Body Hash

• Een e-mailgateway of filter heeft inhoud toegevoegd nadat de DKIM-ondertekening was uitgevoerd: Disclaimers, juridische voetteksten, trackingpixels, afmeldblokken, antivirusbanners en marketingvoetteksten die door een uitgaande gateway zijn ingevoegd nadat het bericht al was ondertekend, zullen allemaal de hoofdtekst wijzigen en de hash ongeldig maken. Dit is veruit de meest voorkomende oorzaak.
• Een mailinglijst of doorstuurserver heeft de hoofdtekst gewijzigd: Mailinglijstsoftware voegt standaard footers voor uitschrijving toe of herschrijft de onderwerpregel, en doorstuurservers kunnen headers verwijderen of toevoegen. Beide wijzigen de ondertekende inhoud.
• Een discrepantie in tekencodering of regeleinde: Als het bericht is ondertekend met een bepaalde codering (bijvoorbeeld UTF-8 met een byte-order mark) en de ontvangende server dit anders interpreteert, of als de regeleinden ergens tijdens de overdracht verschuiven tussen CRLF en LF, komt de inhoud op byteniveau niet meer overeen en mislukt de hash.
• De DKIM-ondertekening vindt te vroeg plaats in de uitgaande e-mailstroom: Dit is de hoofdoorzaak van de meeste van de hierboven genoemde problemen. Als uw systeem het bericht ondertekent voordat een downstream-component het wijzigt, zal de hash van de body elke keer mislukken.
• Een onjuiste of gedraaide privésleutel: Als de ondertekeningssleutel niet meer overeenkomt met de openbare sleutel die in DNS is gepubliceerd, mislukt de verificatie.

Hoe stel je een storing in de Body Hash vast?

Volg deze stappen om te achterhalen waar de wijziging precies plaatsvindt:

1. Stuur hetzelfde testbericht naar Gmail, Outlook of Hotmail en naar één interne mailbox. Zorg ervoor dat de inhoud, de links en de route in alle drie de gevallen identiek zijn.
2. Controleer bij elke ontvanger de header ‘Authentication-Results’. Als de hash van de body bij alle drie de ontvangers mislukt, ligt het probleem aan de verzendende kant. Als dit slechts bij één ontvanger het geval is (Outlook is hier meestal de boosdoener), ligt het probleem waarschijnlijk eerder aan de MIME-structuur of de tekencodering dan aan je ondertekeningsconfiguratie.
3. Controleer de volgorde van uw e-mailverwerking en ga na of de DKIM-ondertekening plaatsvindt vóór of na eventuele wijzigingen aan de uitgaande inhoud.
4. Controleer het DKIM-DNS-record en ga na of de selector en de openbare sleutel overeenkomen met de gegevens in de ongeldige handtekening, met behulp van onze tool voor het opzoeken van DKIM-records.
5. Stuur een testbericht in platte tekst zonder tracking, voettekst of bijlagen. Als dat bericht wel doorkomt terwijl je normale e-mail wordt tegengehouden, heb je de oorzaak door middel van uitsluiting vastgesteld.

Hoe fouten in de Body-hash te verhelpen

• Onderteken het bericht als laatste, na elke wijziging in de inhoud: Dit is de meest gebruikelijke en meest effectieve oplossing. Verander de volgorde van “opstellen, DKIM-ondertekenen, disclaimer toevoegen, verzenden” naar “opstellen, disclaimer toevoegen, DKIM-ondertekenen, verzenden”, zodat u precies dat bericht ondertekent dat de ontvanger zal ontvangen.
• Stel uitgaande gateways zo in dat ze de berichttekst niet wijzigen: Of stel ze zo in dat ze opnieuw met DKIM ondertekenen nadat ze de wijzigingen hebben aangebracht.
• Standaardiseer uw codering naar UTF-8 zonder byte-order mark en zorg ervoor dat de CRLF-regeleinden gedurende het hele verzendtraject consistent blijven. Dit is vooral van belang voor Exchange- en Microsoft 365-omgevingen.
• Gebruik ‘relaxed’ canonicalisatie (c=relaxed/relaxed): Dit tolereert kleine verschillen in witruimte en opmaak die anders een handtekening zouden ongeldig maken bij strikte “eenvoudige” canonieke verwerking. Het redt een handtekening niet wanneer een volledige disclaimer of voettekst wordt toegevoegd, maar het voorkomt fouten die worden veroorzaakt door onbeduidende opmaakwijzigingen.

Fouten met de Body-hash in Outlook en Microsoft 365

Een veelvoorkomend patroon, dat ook op de ondersteuningsforums van Microsoft zelf veelvuldig terugkomt, is een bericht dat de DKIM-controle bij Gmail en Yahoo doorstaat, maar bij Outlook of Hotmail wordt afgewezen. Dit komt meestal voor bij berichten die bijlagen of ingesloten afbeeldingen bevatten, en het wijst erop dat het te maken heeft met de manier waarop het systeem van Microsoft omgaat met de MIME-structuur en tekencodering, en niet met een probleem in uw ondertekeningsinstellingen.

De duidelijkste manier om dit te controleren, is door de header ‘Authentication-Results’ van hetzelfde bericht bij beide ontvangers te vergelijken. De uitkomsten ‘pass’ en ‘fail’ zien er als volgt uit:

Geen

# Bij Gmail (goedgekeurd)

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1;
spf=pass; dmarc=pass

# In Outlook (mislukt bij hetzelfde bericht)

Authentication-Results: protection.outlook.com;
dkim=fail (body hash did not verify)
header.d=yourdomain.com header.s=selector1;
spf=pass; dmarc=fail (p=none)

Als je een DKIM-fout ziet, kun je de oorzaak het snelst achterhalen door de authenticatieheaders van het bericht zelf te bekijken, in plaats van te gaan gissen naar de oorzaak.

Hoe de Authentication-Results-header te interpreteren

Open het bericht in Gmail, klik op het menu met de drie puntjes en selecteer “Origineel weergeven.” Zoek de koptekst Authentication-Results en zoek naar het dkim=-resultaat. Dit kan ‘pass’, ‘fail’ of ‘neutral’ zijn, en wordt meestal gevolgd door een reden, zoals ‘body hash did not verify’, ‘signature did not verify’ of ‘key too short’. Aan de hand van die reden kun je zien met welk soort probleem je te maken hebt, en dus welke van de bovenstaande oplossingen van toepassing is.

Terwijl je de koptekst leest, zijn de DKIM-Signature-tags handige aanknopingspunten:

v= DKIM-versie (bijv. v=1)

een= ondertekeningsalgoritme (bijv. a=rsa-sha256)

d= ondertekeningsdomein (controleer of dit overeenkomt met uw 'Van'-adres)

s= selector, wordt gebruikt om de openbare sleutel in DNS te vinden

h= de headers die in de handtekening zijn opgenomen

bh= de body-hash (de waarde die leidt tot de foutmelding 'body-hash niet geverifieerd')

b= de cryptografische handtekening zelf

Door de d=-waarde te vergelijken met het zichtbare ‘Van’-domein kun je controleren of deze overeenkomt; de s=-selector geeft aan welk DNS-record je moet controleren, en een afwijking in de bh=-waarde bevestigt dat de tekst na ondertekening is gewijzigd.

Als de afzender een naam blijkt te zijn die je niet herkent, controleer dan of deze tot je geautoriseerde afzenders behoort en vergelijk deze met je DMARC-foutrapporten om te zien wat voor soort e-mail deze verstuurt, en controleer of het IP-adres op een van de zwarte lijsten staat. 

Als het een legitieme afzender is, stel dan DMARC dan correct in om deze te autoriseren. Als dat niet het geval is, is dat een signaal van spoofing dat om actie vraagt.

Ik heb de foutmelding ‘DKIM-handtekening is ongeldig’ verholpen. Wat nu?

Om je DKIM-configuratie vanaf hier te verbeteren:

1. Meld je aan bij onze Hosted DKIM om uw DKIM-authenticatieresultaten in de loop van de tijd te volgen.
2. Schakel SPF en DMARC in voor extra beveiliging en nauwkeurigere authenticatie.
3. Wissel uw DKIM-sleutels regelmatig om voor een betere beveiliging te zorgen.

Ik kan de fout nog steeds niet herstellen

Als de foutmelding ‘DKIM-handtekening ongeldig’ blijft verschijnen, neem dan contact op met uw e-mailprovider voor hulp, of neem dan contact met ons op voor deskundig advies over alles wat met e-mailverificatie te maken heeft.

Veelgestelde Vragen

Wat betekent „DKIM-handtekening body-hash niet geverifieerd“? 

Dit betekent dat de hash van de berichttekst die de ontvangende server heeft berekend, niet overeenkomt met de `bh=`-waarde die uw server heeft vastgelegd toen het bericht werd ondertekend. In de praktijk is de tekst van het e-mailbericht na het ondertekenen gewijzigd, meestal door een disclaimer, voettekst, trackingpixel of een aanpassing door een gateway die later in het verzendtraject is toegevoegd.

Waarom slaagt de DKIM-body-hash alleen in Outlook niet, terwijl hij in Gmail wel wordt geaccepteerd? 

Wanneer een bericht wel bij Gmail aankomt maar niet bij Outlook of Hotmail, ligt de oorzaak meestal in de manier waarop het systeem van Microsoft omgaat met de MIME-structuur en tekencodering, en niet in uw ondertekeningsconfiguratie. Dit komt het vaakst voor bij berichten met bijlagen of ingesloten afbeeldingen. Vergelijk de ruwe broncode bij beide ontvangers, standaardiseer uw overdrachtscodering en maak gebruik van versoepelde canonieke verwerking.

Hoe zorg ik ervoor dat DKIM-ondertekening plaatsvindt nadat de disclaimers zijn toegevoegd? 

Pas de volgorde van je uitgaande e-mailstroom zodanig aan dat het ondertekenen de laatste stap is waarbij de inhoud wordt gewijzigd. In plaats van eerst te ondertekenen en daarna een disclaimer toe te voegen, voeg je eerst de disclaimer toe en onderteken je daarna. Je kunt dit bereiken door je DKIM-ondertekeningsprogramma na de inhoudsfilters en de disclaimer- of ondertekeningsdiensten uit te voeren, zodat het het definitieve bericht ondertekent dat de ontvanger daadwerkelijk ontvangt.

Wat is het verschil tussen „body hash niet geverifieerd“ en „handtekening niet geverifieerd“? 

“Body hash did not verify” betekent dat de inhoud van het bericht na het ondertekenen is gewijzigd; de oplossing ligt dus in de inhoud of de e-mailstroom. “Signature did not verify” is een bredere foutmelding en duidt vaak op een wijziging in de ondertekende header, een sleutelconflict of een DNS- of sleutelprobleem. De redentekst in de Authentication-Results-header geeft aan met welke situatie je te maken hebt.

Filtert DKIM e-mailberichten? 

DKIM filtert e-mail niet rechtstreeks. Het geeft een ‘geslaagd’ of ‘mislukt’ signaal af, waarmee ontvangende servers rekening houden bij het bepalen van hun eigen spamscore. E-mail afkomstig van een vertrouwd domein die de DKIM-controle doorstaat, krijgt mogelijk een lagere spamscore, terwijl een mislukte DKIM-controle ertoe kan leiden dat een bericht als spam wordt gemarkeerd of in quarantaine wordt geplaatst.

Kan ik DKIM-fouten negeren als DMARC is ingesteld op p=none? 

Bij p=none wordt mislukte e-mail nog steeds afgeleverd, dus een DKIM-fout leidt niet direct tot blokkering. Maar als je dit negeert, gaat het doel van de overgang naar strikte handhaving verloren en kun je je eigen authenticatiegegevens niet meer vertrouwen. Het is beter om fouten op te lossen terwijl p=none is ingesteld, zodat je later veilig kunt overgaan naar p=quarantine en p=reject.

Hoe vaak moet ik DKIM-sleutels vernieuwen? 

Het is gebruikelijk om sleutels om de zes maanden tot een jaar te vernieuwen. Door sleutels regelmatig te vernieuwen, blijft de schade beperkt als een privésleutel ooit openbaar wordt. Het is belangrijk om bij het vernieuwen ook de gepubliceerde openbare sleutel in het DNS bij te werken, aangezien een vernieuwde sleutel die niet in het DNS is bijgewerkt, zelf tot fouten bij het ondertekenen leidt.

• Over
• Laatste berichten

Yunes Tarada

Expert op het gebied van domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• Hoe de fouten „DKIM-handtekening is ongeldig” en „Hash van de tekst is niet geverifieerd” te verhelpen - 16 juli 2026
• Handleiding voor het instellen van DKIM, DMARC en SPF - 6 juli 2026
• NIST SP 800-81r3: Richtlijnen voor DNS-beveiliging bij e-mail - 25 juni 2026