'DKIM Signature Not Valid' — de oorzaken, in de volgorde om ze na te lopen (2026)

Gepubliceerd 2026-07-08

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

“DKIM signature not valid” heeft vijf veelvoorkomende oorzaken, het best in volgorde na te lopen: onderweg gewijzigde inhoud, een afgekapt sleutelrecord, een gepubliceerde sleutel die niet bij de ondertekenaar past, de verkeerde selector, en kwetsbare canonicalisatie. Slechts 10.092.481 van de 261.086.232 beoordeelde domeinen (3,87%) hebben de volledige triade SPF + DKIM + afdwingend DMARC, volgens de Defaults.Exposed-census (2026-06-29).

De volgorde van de fix doet ertoe, omdat de meest voorkomende oorzaak helemaal niet in uw DNS zit. Controleer eerst wat het bericht onderweg heeft gewijzigd, en werk daarna naar binnen: de integriteit van het sleutelrecord, of het past bij waarmee uw mailserver daadwerkelijk ondertekent, de selector, en ten slotte de ondertekeningsinstellingen. De meeste ongeldige handtekeningen zijn bij stap één of twee verholpen.

Wat betekent “DKIM signature not valid” nu echt?

Elk DKIM-ondertekend bericht draagt een DKIM-Signature-header met een domein (d=), een selector (s=), een hash van de berichttekst (bh=) en een cryptografische handtekening over de body-hash plus geselecteerde headers (b=). De ontvanger haalt uw publieke sleutel op uit DNS op <selector>._domainkey.<domain>, herberekent beide hashes en controleert de handtekening (RFC 6376). “Signature not valid” is checker- en headertaal voor: die verificatie is uitgevoerd en mislukt — de sleutel is gevonden, maar de wiskunde kwam niet uit.

Die laatste zinsnede is diagnostisch goud. Een verifier die uw sleutel niet kan vinden zegt iets anders — doorgaans een header als dkim=fail (no key for signature) — en dat is een selectorprobleem, behandeld in DKIM “no key for signature” — selector- en rotatiefixes. En een verifier die een andere body-hash herberekent, zegt dat meestal expliciet: body hash did not verify — Microsoft rapporteert het als dkim=fail (body hash did not verify), terwijl Gmail dezelfde diagnose vaak toont als dkim=neutral (body hash did not verify). Hoe dan ook wijst het op inhoudswijziging, behandeld in “body hash did not verify” — wat uw bericht heeft gewijzigd. Lees de exacte formulering in de Authentication-Results-header voordat u iets aanraakt: die vertelt u welke van de vijf oorzaken u in handen hebt.

Dit goed krijgen is zeldzaam: slechts 51,84% van de beoordeelde domeinen publiceert überhaupt een vindbare DKIM-sleutel in DNS, volgens de Defaults.Exposed-census, en slechts 3,87% van de 261 miljoen beoordeelde domeinen combineert SPF, DKIM en een afdwingend DMARC-beleid — de configuratie waar de bulkverzenderregels nu van uitgaan. Het beeld per fase staat in het SPF-adoptievolwassenheidsmodel.

Wat zijn de vijf oorzaken, in volgorde?

#	Oorzaak	Het kenmerk	De oplossing
1	Onderweg gewijzigde inhoud — gatewayvoetteksten, juridische disclaimers, onderwerptags van mailinglijsten	`body hash did not verify` in Authentication-Results; externe mail faalt, directe mail slaagt	Onderteken ná de wijziging, of stop met wijzigen — zie de body-hash-gids
2	Afgekapte of verhaspelde lange sleutel	Gepubliceerde `p=` is zichtbaar korter dan de sleutel die u genereerde; elke ontvanger faalt	Publiceer de 2048-bits sleutel opnieuw als correct gesplitste TXT-strings
3	Gepubliceerde sleutel past niet bij de ondertekenaar	Falen begint direct na een rotatie, migratie of providerwissel	Kopieer de huidige publieke sleutel opnieuw van de ondertekenaar; geef de voorkeur aan CNAME-delegatie
4	Verkeerde of ontbrekende selector	`no key for signature` — de lookup zelf faalt	Publiceer de selector die de ondertekenaar daadwerkelijk gebruikt — zie de selectorgids
5	Kwetsbare canonicalisatie of een `l=`-tag	Wisselend falen op triviaal heropgemaakte berichten	`c=relaxed/relaxed`; verwijder `l=` volledig

Oorzaak 1 is vetgedrukt omdat die handtekeningen breekt op berichten die perfect ondertekend waren. Een security-gateway voegt een disclaimer toe, een compliance-voettekst wordt na het ondertekenen gestempeld, een mailinglijst zet [listname] in het onderwerp — de tekst of de ondertekende headers veranderen, de hashes komen niet meer overeen, en de handtekening is ongeldig zonder dat uw DNS iets te verwijten valt. Corresponderen de fouten met mail die door een gateway, een lijst of een archiveringsschakel is gegaan, begin dan daar.

Hoe repareer ik “DKIM signature not valid”?

Voer de gratis scan uit op defaults.exposed voordat u DNS aanraakt. Die toont of uw gepubliceerde sleutelrecord aanwezig, goedgevormd en compleet is — en scheidt “uw DNS is kapot” (oorzaken 2–4) van “uw DNS is in orde, het bericht wordt gewijzigd” (oorzaak 1) in één stap.
Lees de Authentication-Results-header van een falend bericht. body hash did not verify → oorzaak 1, ga naar de body-hash-gids — de gebruikelijke verdachten zijn gatewayvoetteksten en disclaimers, en de fix is ondertekenen na de wijziging. no key for signature → oorzaak 4, ga naar de selectorgids. Een kaal handtekeningfalen → ga verder.
Controleer de gepubliceerde sleutel op afkapping. Zoek <selector>._domainkey.<yourdomain> op als TXT (dig TXT selector._domainkey.example.com). Een 2048-bits RSA-publieke sleutel is langer dan de limiet van 255 tekens van één TXT-string en moet dus worden gepubliceerd als meerdere strings tussen aanhalingstekens die ontvangers aan elkaar plakken — en de webinterfaces van DNS-providers zijn berucht om het stilletjes afkappen van de plak, het verhaspelen van de splitsing of het injecteren van witruimte en aanhalingstekens in de p=-waarde. Vergelijk teken voor teken met de sleutel die uw ondertekenaar genereerde; onze DKIM-installatiegidsen behandelen de eigenaardigheden per provider.
Bevestig dat de gepubliceerde sleutel bij de ondertekenaar past. Na een sleutelrotatie, providermigratie of ESP-herkoppeling komt het vaak voor dat de ondertekenaar een nieuwe privésleutel heeft terwijl DNS nog de oude publieke sleutel serveert — elke handtekening verifieert tegen de verkeerde sleutel en faalt. Kopieer het huidige record opnieuw uit de beheerconsole van uw provider. Beter: waar de provider CNAME-delegatie aanbiedt, gebruik die — de provider roteert sleutels aan de eigen kant en deze hele klasse van falen verdwijnt. En verwijder nooit een oude selector voordat het ermee ondertekende verkeer is uitgestroomd.
Repareer de ondertekeningsinstellingen, niet alleen het record. Zet canonicalisatie op c=relaxed/relaxed, wat het opnieuw afbreken van witruimte en het hervouwen van headers tolereert dat tussenliggende servers legitiem doen; simple-canonicalisatie faalt op wijzigingen die een mens niet eens kan zien. En gebruik de l=-body-lengtetag niet: die was bedoeld om voetteksten door te laten, maar laat iedereen inhoud aan uw ondertekende bericht toevoegen zonder de handtekening te breken — een echte aanvalsvector — en overleeft de meeste gatewaywijzigingen alsnog niet. Geen l= is zowel de veiligere als de betrouwbaardere keuze.
Scan opnieuw, controleer daarna de alignment. Een geldige handtekening helpt DMARC alleen als het d=-domein aligneert met uw From-domein — een handtekening die valideert als d=yourcompany.gappssmtp.com slaagt op DKIM en faalt alsnog op DMARC. Is dat bij u het geval, zie dan de standaardhandtekening-valkuil, en werk daarna alles af wat de scan verder signaleert op de pagina repareer DKIM.

Veelgestelde vragen

Is “DKIM signature not valid” hetzelfde als “body hash did not verify”? De body-hash-melding is één specifiek subgeval: de tekst is na het ondertekenen gewijzigd (voetteksten, disclaimers, lijstherschrijvingen). “Signature not valid” is het parapluoordeel voor elke mislukte verificatie, inclusief slechte sleutels en headerwijzigingen — daarom is stap 2 hierboven het lezen van de header, en heeft het body-hash-geval een eigen gids.

Betekent een ongeldige DKIM-handtekening dat mijn mail wordt geweigerd? Niet op zichzelf — ontvangers behandelen een kapotte handtekening als een ontbrekende. De schade landt via DMARC: slaagt SPF ook niet met alignment, dan faalt het bericht op DMARC en geldt uw gepubliceerde beleid. Per de census van 2026-06-29 hebben slechts 3,87% van de 261.086.232 beoordeelde domeinen SPF, DKIM en een afdwingend DMARC-beleid samen — maar Gmail en Microsoft verwachten precies dat nu van verzenders, dus een kapotte DKIM-poot kost al bezorgbaarheid vóór er iets geweigerd wordt.

Moet ik een 1024-bits of 2048-bits DKIM-sleutel gebruiken? 2048-bits — 1024-bits sleutels zitten onder de huidige cryptografische aanbevelingen en sommige ontvangers waarderen ze af. De addertjes zijn puur operationeel: een 2048-bits sleutel past niet in één TXT-string van 255 tekens en moet dus correct worden gesplitst (oorzaak 2 hierboven). CNAME-delegatie naar uw provider omzeilt het splitsingsprobleem volledig.

Mijn DKIM slaagt bij een checker maar DMARC faalt nog steeds — hoe kan dat? Vrijwel zeker alignment: de handtekening valideert, maar het d=-domein (bijvoorbeeld yourcompany.gappssmtp.com of yourtenant.onmicrosoft.com) komt niet overeen met uw From-domein, dus DMARC kan er niets mee. Schakel de custom-domain-ondertekening van uw provider in — de volledige uitleg staat in de gids over de standaardhandtekening-valkuil.

Kan ik DKIM niet gewoon uitzetten als het blijft falen? Nee — sinds de bulkverzendermandaten van 2024 vereisen Gmail en Yahoo DKIM voor volumeverzenders, en een afdwingend DMARC-beleid heeft realistisch gezien DKIM nodig omdat SPF alleen breekt bij doorsturen. Repareer de handtekening; de oorzaken hierboven zijn allemaal in een middag op te lossen.

Stuur de eigenaar het rapport

Als u dit oplost voor een klant of uw werkgever, sluit dan de cirkel met bewijs. Voer na uw wijzigingen de gratis scan opnieuw uit en stuur het beoordeelde rapport door naar de bedrijfseigenaar: gedateerd, in gewone taal, DKIM op groen. Het is het bewijsstuk dat ze nodig hebben voor de cyberverzekeringsverlenging en de volgende leveranciersbeveiligingsvragenlijst — het verschil tussen “ik heb een DNS-dingetje gerepareerd” en een gedocumenteerd voor-en-na dat zegt dat het domein zijn mail authenticeert.

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