DKIM-fout: wat elke fout betekent en hoe je deze kunt verhelpen

DomainKeys Identified Mail (DKIM) is een van de fundamentele pijlers van e-mailverificatie. Door een cryptografische handtekening aan uitgaande berichten toe te voegen, stelt DKIM ontvangende mailservers in staat om te controleren of een e-mail daadwerkelijk door de domeineigenaar is geautoriseerd en of de inhoud ervan tijdens het verzenden niet is gemanipuleerd.

Wanneer een ontvangende server echter een inkomende e-mail controleert en in de header de status ‘dkim=fail’ aantreft, mislukt de authenticatie. Een DKIM-fout geeft aan ontvangende gateways zoals Google Workspace, Microsoft 365 of Apple Mail aan dat ofwel de berichttekst is gewijzigd nadat het bericht de afzender heeft verlaten, ofwel de openbare sleutel niet uit het DNS kon worden opgehaald, ofwel de cryptografische handtekening zelf ongeldig is.

Afhankelijk van het DMARC-beleid van uw domein en de beveiligingsinstellingen van de ontvanger kunnen DKIM-fouten ervoor zorgen dat legitieme zakelijke e-mails in de spamfolder terechtkomen of helemaal worden geweigerd. Deze handleiding dient als een overzicht van foutmeldingen en helpt u de exacte fouttekst in de headers van uw e-mails te achterhalen, de onderliggende oorzaak te identificeren en het probleem snel op te lossen.

Veel voorkomende redenen voor DKIM falen

Hoewel fouten bij de DKIM-validatie uiteindelijk het gevolg zijn van een afwijkende hash of een fout bij het ophalen van de sleutel, vallen de daadwerkelijke operationele oorzaken meestal onder een aantal voorspelbare categorieën. Door deze onderliggende oorzaken te vergelijken met de specifieke foutmelding in de headers van uw e-mail, komt u direct bij de oplossing terecht.

1. Wijzigingen in berichten door e-mailgateways en beveiligingsapparatuur

De meest voorkomende oorzaak van DKIM-fouten in bedrijfsomgevingen is dat een tussenliggende dienst de inhoud van een bericht wijzigt nadat de DKIM-handtekening al is aangebracht. Beveiligingsapparatuur, uitgaande gateways, antispamfilters en tools voor gegevensverliespreventie (DLP) passen uitgaande berichten vaak aan door bedrijfsvoetteksten toe te voegen, trackinglinks in te voegen, tekensets opnieuw te coderen of MIME-grenzen te wijzigen. 

Als de ondertekening plaatsvindt op de primaire mailserver voordat de e-mail deze apparaten passeert, zal de door de ontvanger berekende hash van de e-mailtekst niet overeenkomen met de oorspronkelijke handtekening, waardoor een dkim=fail-fout (hash van de e-mailtekst kon niet worden geverifieerd) wordt gegenereerd.

2. Mailinglijsten en automatische e-maildoorsturing

Wanneer een e-mail naar een mailinglijst wordt verzonden of automatisch wordt doorgestuurd via tussenliggende mailtransferagenten (MTA’s), wijzigt de doorstuurserver vaak de kopteksten van het bericht (zoals ‘Onderwerp’ of ‘Aan’) of voegt hij voetnoten toe die betrekking hebben op het beheer van de mailinglijst (zoals links om je uit te schrijven of disclaimers van de lijst). Aangezien de cryptografische handtekening deze onderdelen omvat, maakt elke wijziging na het ondertekenen de verificatiecontrole ongeldig. 

Hoewel moderne protocollen zoals Authenticated Received Chain (ARC) doorstuurders helpen de authenticatiestatus te behouden, mislukken onbewerkte DKIM-controles op doorgestuurde berichten vaak.

3. Ontbrekende, verkeerd geconfigureerde of afgekorte DNS-TXT-records

Ontvangende mailservers moeten uw openbare sleutel ophalen uit een specifiek DNS TXT-record op selector._domainkey.yourdomain.com. Als dit DNS-record ontbreekt, onder een onjuiste selectienaam is gepubliceerd of vertraging oploopt door DNS-propagatie, kan de ontvanger de sleutel niet ophalen, wat leidt tot een dkim=fail-fout (geen sleutel voor ondertekening).

Bovendien doet zich een specifiek en veelvoorkomend probleem voor bij 2048-bits RSA-sleutels. Volgens RFC 1035 is een afzonderlijke tekenreeks binnen een DNS TXT-record beperkt tot 255 bytes. Een met Base64 gecodeerde 2048-bits RSA-sleutel is ongeveer 392 tekens lang. Als uw DNS-provider of -beheerder een 2048-bits sleutel als één enkele tekenreeks zonder aanhalingstekens invoert, kunnen oudere DNS-beheertools de inhoud van de sleutel afkappen, wat leidt tot een onvolledige openbare sleutel in het DNS en een dkim=fail-fout (handtekening niet geverifieerd) veroorzaakt.

4. Sleutelverschillen, onaangekondigde sleutelrotatie en migraties van providers

Om de DKIM-verificatie te laten slagen, moet de privésleutel die door de verzendende mailserver wordt gebruikt om de handtekening te genereren, wiskundig overeenkomen met de openbare sleutel die in uw DNS is gepubliceerd. Er is sprake van een cryptografische discrepantie als:

• De ondertekenende mailserver genereert een nieuwe privésleutel, maar het DNS-record wordt niet tegelijkertijd bijgewerkt.
• Een e-mailserviceprovider (ESP) wisselt zijn ondertekeningssleutels af zonder uw gepubliceerde TXT-record of CNAME-doel bij te werken.
• Een domein wordt gemigreerd naar een nieuw hostingplatform, terwijl de e-mailserver blijft ondertekenen met een oude selector of een buiten gebruik gesteld sleutelpaar.

5. Syntaxfouten in DNS-records en strikte instellingen voor canonieke verwerking

Kleine opmaakfouten in het record van de openbare sleutel (zoals ontbrekende puntkomma’s, losse spaties in de Base64-sleutel of onjuiste tag-namen) zorgen ervoor dat de openbare sleutel niet kan worden geparseerd door ontvangende MTA’s. 

Evenzo geldt dat, als je ondertekeningsserver gebruikmaakt van eenvoudige canonieke verwerking voor headers of de inhoud van de body (c=simple/simple), zelfs kleine aanpassingen in regeleinden (CRLF versus LF) of aanpassingen aan witruimte aan het einde van de tekst, veroorzaakt door tussenliggende relays, de verificatie zullen verstoren.

Beoordeling Syntaxis van het DKIM-record.

6. U hebt DKIM niet ingesteld voor uw externe e-mailproviders

Als u gebruikmaakt van meerdere externe e-mailproviders om namens uw organisatie e-mails te versturen, dient u contact met hen op te nemen voor instructies over het activeren van DKIM voor uw uitgaande e-mails. Als u uw eigen aangepaste domeinen of subdomeinen gebruikt die bij deze externe dienst zijn geregistreerd om e-mails naar uw klanten te versturen, moet u uw provider vragen om DKIM voor u te regelen.

Als je e-mailverwerking uitbesteedt aan een externe leverancier, zou deze je domein idealiter moeten configureren door een DKIM-record op hun DNS te publiceren met behulp van een DKIM-selector die uniek is voor u, zonder dat u daar zelf iets voor hoeft te doen.

OF, 

U kunt een DKIM-sleutelpaar genereren en de privésleutel aan uw e-mailprovider overdragen, terwijl u de openbare sleutel op uw eigen DNS publiceert. 

Verkeerde configuraties hierin kunnen leiden tot DKIM-storingen, dus je moet open communiceren met je serviceprovider over je DKIM-configuratie. 

Opmerking: Sommige e-mailservers van derden voegen opgemaakte voetteksten toe aan de hoofdtekst van het bericht. Als deze servers als tussenstations fungeren in een e-maildoorstuurproces, kan de samengevoegde voettekst een van de oorzaken zijn van een mislukte DKIM-verificatie. 

7. Problemen met de communicatie met de server

In bepaalde situaties kan het voorkomen dat de e-mail wordt verzonden vanaf een server waarop DKIM is uitgeschakeld. In dergelijke gevallen zal DKIM voor die e-mail mislukken, zelfs als andere servers in uw infrastructuur correct zijn geconfigureerd. Het is belangrijk om ervoor te zorgen dat alle betrokken partijen DKIM correct hebben ingeschakeld. 

8. DNS-storing / DNS-uitval

Dit is een veel voorkomende reden voor DKIM-fouten. DNS-uitval kan om verschillende redenen optreden, waaronder denial of service-aanvallen. Routinematig onderhoud van uw naamserver kan ook de reden zijn achter een DNS-uitval. Tijdens deze (meestal korte) periode kunnen ontvangende servers geen DNS-query's uitvoeren. 

Aangezien we weten dat DKIM in je DNS bestaat als een TXT/CNAME-record, voert de client-server tijdens de authenticatie een lookup uit om de DNS van de afzender te bevragen naar de publieke sleutel. Tijdens een storing wordt dit niet mogelijk geacht, waardoor DKIM kan worden verbroken. 

9. OpenDKIM gebruiken

OpenDKIM is een open-source DKIM-implementatie die op uw eigen e-mailserver kan worden geïnstalleerd om uitgaande e-mail te ondertekenen en te verifiëren. Bij gebruik van een zelfgehoste OpenDKIM-installatie communiceert de dienst doorgaans met de e-mailserver via poort 8891.

Om er zeker van te zijn dat OpenDKIM correct werkt, kun je een online poortcontrole gebruiken om te controleren of poort 8891 op je server open en toegankelijk is. Controleer ook of de vereiste machtigingen correct zijn geconfigureerd. Onjuiste machtigingen kunnen ervoor zorgen dat OpenDKIM geen toegang krijgt tot de socket of er niet correct aan kan worden gekoppeld.

Controleer de configuratie van uw server en de map waarin de OpenDKIM-socket zich bevindt, om er zeker van te zijn dat de map bestaat en over de juiste eigenaarschap en machtigingen beschikt.

10. DKIM-controle op afwijkingen in de uitlijning

Als u DMARC voor uw domein hebt ingesteld naast DKIM, tijdens DKIM-controlemoet de domeinwaarde in het veld d= op de DKIM-handtekening in de e-mailheader overeenkomen met het domein in het Van-adres. Dit kan een strikte afstemming zijn, waarbij de twee domeinen exact moeten overeenkomen, of een soepele afstemming, waarbij een organisatorische overeenkomst voldoende is om de controle te doorstaan. 

Er kan een DKIM-fout optreden als het domein in de DKIM-handtekeningheader niet overeenkomt met het domein in de ‘From’-header; dit kan een typisch geval zijn van domeinspoofing of een identiteitsfraude-aanval. 

Uitleg over DKIM-foutmeldingen (per foutmelding)

Zoek hieronder de exacte foutmelding om te begrijpen wat er op de ontvangende server is gebeurd en hoe u dit kunt oplossen.

dkim=fail (hash van de body kon niet worden geverifieerd)

De foutmelding `dkim=fail` (hash van de berichttekst niet geverifieerd) geeft aan dat de openbare sleutel met succes uit het DNS is opgehaald en dat de algemene handtekeningheader correct is opgemaakt, maar dat de cryptografische hash van de berichttekst, zoals berekend door de ontvanger, niet overeenkomt met de hashwaarde die is opgeslagen in de `bh=`-tag van de handtekening.

Simpel gezegd: de hoofdtekst van de e-mail is gewijzigd nadat de verzendende server deze had ondertekend.

Belangrijkste oorzaken:

• Outbound-beveiligingsgateways, disclaimertools of CRM-plug-ins voegden na de ondertekeningsfase juridische disclaimers, promotionele voetteksten of trackingpixels toe.
• Tussenliggende relais pasten tijdens de overdracht regeleinden, tekensets of witruimte aan.
• Software voor het doorsturen van e-mails of voor mailinglijsten heeft de inhoud van het bericht gewijzigd.

Hoe dit op te lossen:

1. Pas de volgorde van je uitgaande e-mailstroom zodanig aan dat de DKIM-ondertekening als allerlaatste stap wordt uitgevoerd voordat het bericht je netwerkinfrastructuur verlaat, zodat alle voetteksten en trackinglinks al vóór de ondertekening zijn toegevoegd.
2. Zorg ervoor dat uw e-mailserver gebruikmaakt van ‘relaxed body canonicalization’ (c=relaxed/relaxed of c=relaxed/simple), waardoor kleine variaties in witruimte en regeleinden tijdens het verzenden worden getolereerd.
3. Als u een l= (lengte)-tag in uw DKIM-headers gebruikt, verwijder deze dan. De l=-tag beperkt het deel van de body dat wordt ondertekend en leidt tot beveiligingsrisico’s, terwijl het problemen met wijzigingen in de body niet oplost.

dkim=fail (geen sleutel voor handtekening)

De foutmelding „dkim=fail“ (geen sleutel voor handtekening) treedt op wanneer de ontvangende server het domein (d=) en de selector (s=) uit de DKIM-Signature-header van de e-mail haalt en probeert een DNS-query uit te voeren op s=._domainkey.d=, maar er geen geldig openbaar sleutelrecord kan vinden.

Deze fout wijst erop dat het probleem specifiek te maken heeft met de DNS-configuratie of afwijkingen in de selectie.

Belangrijkste oorzaken:

• De selectornamen die door uw verzendende toepassing is opgegeven, komt niet overeen met het selectorvoorvoegsel dat in DNS is gepubliceerd.
• Het TXT- of CNAME-record is nooit op de gezaghebbende DNS-server gepubliceerd.
• Het DKIM-record is onlangs gepubliceerd en is nog niet volledig doorgevoerd in alle DNS-resolvers wereldwijd.
• Het openbare-sleutelrecord is per ongeluk verwijderd tijdens een domeinmigratie of het opschonen van sleutels.

Hoe dit op te lossen:

1. Bekijk de ruwe e-mailheader om de exacte selectiestring in de s=-tag te achterhalen.
2. Controleer of er een DNS TXT- of CNAME-record bestaat op selector._domainkey.yourdomain.com (voor instructies over het vinden van selector-strings, zie onze uitgebreide handleiding over hoe u uw DKIM-selector kunt vinden).
3. Controleer of het DNS-record de verplichte tags v=DKIM1; en k=rsa; (of k=ed25519;) bevat, samen met de p=-payload van de openbare sleutel.

dkim=fail (handtekening kon niet worden geverifieerd)

In tegenstelling tot een ‘body hash’-fout betekent de foutmelding ‘dkim=fail’ (handtekening niet geverifieerd) dat de cryptografische evaluatie van de hoofdhandtekeningreeks (de ‘b=’-tag) is mislukt. De ontvanger heeft een openbare sleutel opgehaald uit het DNS, maar met die sleutel kon de payload van de headerhandtekening niet worden gedecodeerd en geverifieerd.

Deze fout wijst rechtstreeks op een ongeldig sleutelpaar of gewijzigde headervelden.

Belangrijkste oorzaken:

• Sleutelpaar komt niet overeen: De privésleutel die door de verzendende server wordt gebruikt om het bericht te ondertekenen, komt niet overeen met de openbare sleutel die in DNS onder die selector is gepubliceerd.
• Afgeknotte DNS-sleutel: Een 2048-bits sleutel werd ten onrechte gepubliceerd als één enkele tekenreeks van meer dan 255 bytes, waardoor de DNS-server de gegevens van de openbare sleutel afkorte.
• Wijziging van de header: Een tussenliggende e-mailserver of gateway heeft de headers die expliciet in de h=-tag van de handtekening zijn opgenomen (zoals From, To, Subject of Date) gewijzigd nadat de handtekening was gegenereerd.

Hoe dit op te lossen:

1. Controleer of je 2048-bits openbare sleutel in het DNS-record correct is opgesplitst in meerdere tekenreeksen tussen aanhalingstekens van elk minder dan 255 bytes.
2. Controleer of uw privésleutel op de e-mailserver overeenkomt met de gepubliceerde openbare sleutel. Als u twijfelt, genereer dan een nieuw sleutelpaar, werk de DNS bij en controleer of ze met elkaar overeenkomen.
3. Zorg ervoor dat tussengeschakelde beveiligingsapparaten de ondertekende headervelden tijdens de overdracht niet wijzigen.

DKIM-softfail

Bij e-mailverificatie is is “soft fail” geen standaardstatus van het DKIM-protocol. Terwijl SPF expliciet een SoftFail-resultaat (~all) definieert, definieert RFC 6376 DKIM-uitkomsten strikt als pass, fail, policy, neutral, temperror of permerror.

Wanneer beheerders of e-mailbeveiligingstools een „DKIM soft fail“ melden, bedoelen ze doorgaans een van de volgende twee scenario’s:

1. DMARC-beoordeling bij p=none: Een bericht faalt bij de DKIM-authenticatie, maar omdat het DMARC-beleid van de domeineigenaar is ingesteld op de monitoringmodus (p=none), bezorgt de ontvangende mailboxprovider de e-mail in de inbox en markeert de interne evaluatiestatus als een ‘soft failure’.
2. Gateway-specifieke classificatie: E-mailbeveiligingsgateways (zoals Cisco Secure Email of Mimecast) geven soms interne diagnostische labels weer, zoals ‘soft fail’, wanneer een e-mail niet voldoet aan DKIM, maar wel aan SPF met de juiste DMARC-afstemming, wat betekent dat het bericht in zijn geheel mag worden afgeleverd.

Als je in de logbestanden de melding ‘soft fail’ tegenkomt, behandel dit dan als een standaard DKIM-fout en controleer je headers op de bijbehorende RFC-foutmelding (de hash van de body kon niet worden geverifieerd of er was geen sleutel voor de handtekening).

Andere DKIM-fouten die je kunt tegenkomen

Ontvangende mailservers kunnen ook de volgende gestandaardiseerde DKIM-diagnosecodes weergeven in hun Authentication-Results-headers:

DKIM mislukt, maar SPF slaagt (en andere gemengde resultaten)

Bij het bekijken van rapporten over de afleverbaarheid van e-mail zult u vaak situaties tegenkomen waarin de protocolresultaten tegenstrijdig zijn. Om problemen op te lossen, is het essentieel te begrijpen hoe ontvangende gateways deze combinaties beoordelen.

Volgens de DMARC-specificaties (RFC 7489) voldoet een e-mail aan de algemene DMARC-validatie, mits ten minste één onderliggend protocol (SPF of DKIM) de status PASS oplevert en correct is afgestemd op het domein dat wordt weergegeven in de zichtbare „From:“-header.

Hieronder wordt uitgelegd hoe veelvoorkomende protocolcombinaties tijdens de levering worden afgehandeld:

Waarom wordt mijn bericht geblokkeerd vanwege DKIM?

Als SPF wordt goedgekeurd, maar je bericht toch wordt geblokkeerd of als spam wordt gemarkeerd vanwege een DKIM-fout, is er sprake van een van de volgende twee situaties:

1. SPF is niet afgestemd: De SPF-controle is geslaagd voor een serverdomein van een derde partij (bijv. mail.mcsv.net), maar kwam niet overeen met het daadwerkelijke domein in de From:-header. Omdat de SPF-afstemming is mislukt en DKIM volledig is mislukt, is DMARC mislukt.
2. Strikte handhaving door providers: Grote ontvangers zoals Google en Microsoft hanteren strikte beveiligingsbeleidsregels voor bulkverzenders. Als een e-mail naast sterke signalen van spamklachten ook structurele authenticatiefouten vertoont, kunnen de algoritmen van de ontvanger het bericht blokkeren, ongeacht of het gedeeltelijk aan de eisen voldoet.

Om te begrijpen hoe de handhaving van het beleid van invloed is op e-mails die niet aan de regels voldoen, kun je onze handleiding raadplegen over wat een DMARC-beleid is en test je domein met onze gratis DMARC-recordchecker.

Hoe je DKIM-resultaten in je e-mailheaders kunt interpreteren

Om de exacte foutmelding te achterhalen, moet u de onbewerkte internetheaders van een afgeleverde test-e-mail bekijken.

Stap 1: De ‘Raw Headers’ openen in je e-mailprogramma

• Gmail: Open het bericht, klik op de drie verticale puntjes naast de knop 'Beantwoorden' en selecteer 'Origineel weergeven'.
• Microsoft Outlook (Web): Open het bericht, klik op de drie puntjes in de actiebalk, selecteer Weergave en klik op Berichtdetails weergeven.
• Apple Mail: Open de e-mail, klik op 'Weergave' in de menubalk bovenaan, plaats de muisaanwijzer op 'Bericht' en selecteer 'Ruwe bron'.

Stap 2: Zoek de header ‘Authentication-Results’

Blader door de ruwe headertekst om het blok ‘Authentication-Results’ te vinden. Zoek naar de vermelding ‘dkim=’.

Een typisch voorbeeld van een header-vermelding die een fout vertoont, ziet er als volgt uit:

Authenticatieresultaten: mx.google.com;
dkim=mislukt (hash van de body kon niet worden geverifieerd) [email protected] header.s=s1 header.b=W8xKz2L;
spf=geslaagd (google.com: het domein [email protected] wijst 192.0.2.1 aan als toegestane afzender) [email protected];
dmarc=geslaagd (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Belangrijke header-tags om te controleren:

• dkim=: Geeft de directe verificatiestatus weer (geslaagd, mislukt, permanente fout, enz.), gevolgd door de expliciete foutmelding tussen haakjes.
• header.i=: Geeft de identiteit/het domein weer dat de e-mail heeft ondertekend.
• header.s=: Geeft de exacte selector aan die wordt gebruikt om de openbare sleutel op te halen uit het DNS.
• header.d=: Geeft het domein van de organisatie aan die de verantwoordelijkheid voor de handtekening op zich neemt.

Het handmatig controleren van onbewerkte e-mailheaders kan ingewikkeld, tijdrovend en over het algemeen lastig zijn. Je kunt deze stappen overslaan door gebruik te maken van onze gratis E-mailheader-analysetool , waarmee u direct voor mensen leesbare inzichten krijgt in uw SPF-, DKIM- en DMARC-authenticatieresultaten. 

Hoe DKIM-fouten te verhelpen en te voorkomen dat ze terugkomen

Volg deze stapsgewijze werkwijze voor het verhelpen van DKIM-problemen in uw verzendinfrastructuur:

1. Controleer de geldigheid van de openbare sleutel in DNS

Gebruik een online opzoekfunctie zoals onze DKIM Record Lookup om de openbare sleutel te controleren die is gepubliceerd op selector._domainkey.yourdomain.com.

• Zorg ervoor dat er geen syntaxisfouten, typefouten of dubbele puntkomma’s in staan.
• Controleer of de sleutel correct in delen is opgesplitst: als je een sleutel van 2048 bits gebruikt, zorg er dan voor dat je DNS-editor de payload heeft opgesplitst in segmenten met aanhalingstekens van minder dan 255 tekens (bijv. “v=DKIM1; k=rsa; p=part1…” “part2…”). Maak nooit afzonderlijke TXT-records aan voor dezelfde selector.

2. Verplaats de DKIM-ondertekening naar de laatste uitgaande hop

Als uw organisatie e-mail via secundaire beveiligingsgateways, disclaimertools of CRM-oplossingen doorstuurt, zorg er dan voor dat de DKIM-ondertekening plaatsvindt nadat deze tools hun aanpassingen hebben aangebracht. Als een apparaat de inhoud moet wijzigen, configureer dat apparaat dan zo dat het de laatste DKIM-ondertekeningsstap namens uw domein uitvoert.

3. Instellingen voor canonicalisatie bijwerken

Wijzig de canonicalisatie-instellingen van uw e-mailserver in „relaxed/relaxed” (of „c=relaxed/relaxed” in de DKIM-header). Hiermee wordt aan ontvangende e-mailservers aangegeven dat ze witruimte, spaties aan het einde van een regel en de opmaak van headervelden moeten normaliseren voordat ze de hash opnieuw berekenen. Zo worden valse verificatiefouten als gevolg van kleine wijzigingen tijdens het transport voorkomen.

4. Zorg ervoor dat de sleutelparen bij rotaties op elkaar zijn afgestemd

Wanneer u DKIM-sleutels vervangt, moet u de nieuwe openbare sleutel altijd eerst onder een nieuwe selectornamen in DNS publiceren. Wacht 24 tot 48 uur totdat de DNS-wijzigingen zijn doorgevoerd voordat u uw e-mailserver configureert om berichten met de nieuwe privésleutel te ondertekenen. Zodra de migratie is voltooid, moet u het oude openbare sleutelrecord nog enkele dagen in DNS laten staan, zodat berichten die al onderweg zijn of in de wachtrij staan en met de oude selector zijn ondertekend, nog steeds kunnen worden geverifieerd.

Houd er rekening mee dat we enkele veelvoorkomende foutmeldingen bij DKIM en de mogelijke oorzaken daarvan hebben besproken, en daarbij een mogelijke oplossing hebben gegeven. Er kunnen echter fouten optreden als gevolg van diverse onderliggende oorzaken die specifiek zijn voor uw domein en servers, en die in dit artikel niet aan bod zijn gekomen. 

U moet voldoende kennis opdoen over authenticatieprotocollen voordat u deze binnen uw organisatie implementeert of uw beleid handhaaft. Een fout bij DKIM, SPF of DMARC-validatie kan de afleverbaarheid van uw e-mail beïnvloeden. 

Veelgestelde Vragen

Wat betekent „body hash niet geverifieerd“?

“Body hash did not verify” betekent dat de openbare sleutel in DNS is gevonden en dat de header-indeling geldig was, maar dat de inhoud van het bericht is gewijzigd nadat het was ondertekend. Omdat de body tijdens de overdracht is gewijzigd (door disclaimers, beveiligingsgateways, hercodering of doorsturing), kwam de door de ontvanger berekende hash niet overeen met de oorspronkelijke hash die was vastgelegd in de bh=-tag van de handtekening.

Hoe los ik een DKIM-fout op?

Om een DKIM-fout op te lossen, zoekt u de exacte foutmelding in de `Authentication-Results`-header van uw e-mail. Als de fout een ontbrekende sleutel betreft (geen sleutel voor ondertekening), publiceert u het TXT-record van de openbare sleutel in DNS onder de juiste selector of corrigeert u dit. Als de fout een niet-overeenkomende body-hash is (de body-hash kon niet worden geverifieerd), pas dan uw e-mailstroom zo aan dat de DKIM-ondertekening plaatsvindt als laatste stap nadat alle footers en links zijn toegevoegd, en stel de canonicalisatie in op ‘relaxed/relaxed’.

Wat houdt een DKIM-overtreding in?

Een „DKIM-overtreding” is een term die door bepaalde e-mailbeveiligingsgateways wordt gebruikt om aan te geven dat een inkomende e-mail niet door de DKIM-validatiecontroles is gekomen. Dit betekent meestal dat de cryptografische handtekening ongeldig was, dat het bericht tijdens het verzenden is gemanipuleerd, of dat de afzender heeft geprobeerd de e-mail te ondertekenen met een domein dat niet overeenkomt met het zichtbare afzenderadres.

Betekent een DKIM-fout dat mijn e-mail niet wordt afgeleverd?

Niet per se. Als je domein een geldig SPF-record heeft dat voldoet aan de juiste DMARC-alignment, zal de e-mail in de meeste gevallen nog steeds de algemene DMARC-controle doorstaan en in de inbox terechtkomen. Als je echter uitsluitend op SPF vertrouwt, wordt je afleverbaarheid kwetsbaar wanneer e-mails worden doorgestuurd. Bovendien geldt dat, als DMARC op beide protocollen faalt en je domeinbeleid is ingesteld op p=quarantine of p=reject, de e-mail die niet door de controle komt in de spamfolder terechtkomt of volledig wordt geweigerd.

• Over
• Laatste berichten

Maitham Al Lawati

Cyberbeveiligingsexpert, CEO bij PowerDMARC

Maitham is een technisch ondernemer, cyberbeveiligingsexpert, CEO en oprichter van PowerDMARC met meer dan 15 jaar ervaring in de sector. Maitham heeft een Global MBA van de Universiteit van Manchester en diverse professionele certificeringen waaronder CISSP, CISM, CRISC en ISC2 CCSP.

Laatste berichten van Maitham Al Lawati (Bekijk alle berichten)

• DKIM-fout: wat elke fout betekent en hoe je deze kunt verhelpen - 13 september 2026
• Methoden voor e-mailverificatie: hoe SPF, DKIM en DMARC uw domein beschermen - 9 augustus 2026
• Wat is een DMARC-beleid? Geen, Quarantaine en Weigeren - 27 juli 2026