DKIM "No Key for Signature": selector- en rotatiefixes (2026)

Gepubliceerd 2026-07-08

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

“No key for signature” betekent dat de ontvanger het DNS-record heeft opgevraagd waarnaar uw DKIM-handtekening verwijst — selector._domainkey.yourdomain — en geen sleutel vond: die is nooit gepubliceerd, of halverwege een rotatie verwijderd. Publiceer de selector die uw ondertekenaar daadwerkelijk gebruikt. Slechts 10.092.481 domeinen — 3,87% — hebben de SPF+DKIM+DMARC-triade compleet, volgens de Defaults.Exposed-census van 261.086.232 beoordeelde domeinen.

De fix is één DNS-record, te vinden in één header. Lees de tags s= en d= uit een echte DKIM-Signature-header om te weten met welke selector uw mail is ondertekend, publiceer (of herstel) exact dat record, en geef de voorkeur aan CNAME-delegatie zodat uw provider de sleutels voor u roteert. Roteer daarna volgens het draaiboek hieronder — deze fout betekent meestal dat iemand een oude selector te vroeg heeft verwijderd.

Wat betekent “dkim no key for signature”?

Elke DKIM-handtekening draagt twee tags die de ontvanger vertellen waar de publieke sleutel op te halen is: d= (ondertekeningsdomein) en s= (selector). De ontvanger vraagt één DNS-naam op die daaruit is opgebouwd — s._domainkey.d — voor de sleutel. “No key for signature” betekent dat die query leeg terugkwam: de handtekening bestaat, maar de sleutel die zij noemt niet.

De formulering verschijnt in Authentication-Results-headers en DMARC-aggregaatrapporten — de exacte bewoording verschilt per ontvanger, maar twee varianten doen ertoe:

Resultaatstring (fragment, zoals breed waargenomen)	Wat er werkelijk gebeurde	Voorbijgaand?
`dkim=temperror (no key for signature)`	De DNS-query is mislukt of verlopen — de ontvanger kreeg helemaal geen antwoord	Ja — nieuwe pogingen slagen vaak; onderzoek alleen bij aanhouden
`dkim=permerror (no key for signature)`	De DNS-query slaagde en het antwoord was “no such record” — de selector is echt afwezig	Nee — het record ontbreekt totdat u het publiceert

Een eenmalige temperror is DNS-weer. Een permerror — of een temperror die dagenlang en bij meerdere ontvangers terugkeert — betekent dat het record waarnaar de handtekening verwijst niet in uw zone staat. Daarover gaat deze gids.

Het gevolg: een niet-verifieerbare handtekening telt als helemaal geen DKIM, dus DMARC valt terug op alleen SPF — en SPF breekt bij doorsturen. Is de handtekening aanwezig maar ongeldig in plaats van afwezig (body-hash, verhaspelde sleutel), dan is dat een ander falen — zie “DKIM signature not valid”.

Hoe vind ik met welke selector mijn mail is ondertekend?

Gok niet op basis van de documentatie van uw provider — lees het uit een echt bericht:

Stuur vanaf het getroffen systeem een bericht naar een mailbox die u beheert (een Gmail-adres werkt goed).
Open de ruwe bron (“Show original” in Gmail, “View message source” in Outlook).
Zoek de DKIM-Signature:-header en lees twee tags: s= is de selector, d= is het ondertekeningsdomein. Een illustratief voorbeeld: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Het record dat de ontvanger opvraagt is s._domainkey.d — hier mail2026._domainkey.yourdomain.com. Controleer het zelf: dig TXT mail2026._domainkey.yourdomain.com +short. Leeg antwoord = de fout is echt voor elke ontvanger.
Herhaal per verzendend systeem. Een bericht kan meerdere DKIM-handtekeningen dragen — mailboxprovider, nieuwsbrieftool, helpdesk — elk met een eigen s=/d=-paar en record. Repareer de falende, en let op de d=: alleen een handtekening waarvan de d= overeenkomt met uw From-domein helpt DMARC.

Waarom ontbreekt het selectorrecord?

Vier oorzaken verklaren vrijwel al deze fouten — loop ze in deze volgorde na:

Het is nooit gepubliceerd. De ondertekenaar is ingeschakeld (of stond standaard aan) met een selector die niemand aan DNS heeft toegevoegd. Komt veel voor bij nieuwe tools en gateways die onverwacht ondertekenen.
Het is halverwege een rotatie verwijderd. Iemand heeft de oude selector “opgeruimd” terwijl berichten die ermee waren ondertekend nog onderweg waren, in de retry-wachtrij stonden of op doorsturen wachtten. Die mail is al ondertekend met s=old; old._domainkey verwijderen breekt elk van die berichten met terugwerkende kracht.
Uw DNS-interface heeft een CNAME-doel verhaspeld. Veel providers delegeren via CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), en veel DNS-panelen plakken stilletjes uw zone aan het doel — waardoor s1.domainkey.u123.esp.com.yourdomain.com wordt opgeslagen, wat naar niets resolvet. Verifieer het doel: dig CNAME s1._domainkey.yourdomain.com +short. Dezelfde valkuil bijt tijdens toolmigraties — zie DKIM faalt na het wisselen van e-mailtool.
De provider roteerde, uw zone niet. Een providersleutel die als statisch TXT-record is geplakt (in plaats van hun CNAMEs) raakt verweesd bij hun geplande rotatie — de ondertekenaar stapt over op een selector die u nooit hebt gepubliceerd. Slechts 51,84% van de 261 miljoen domeinen in de census toont op het scanmoment een vindbare DKIM-sleutel (gegevens per 2026-06-29).

Hoe repareer ik “no key for signature”?

Voer de gratis scan uit op defaults.exposed voordat u DNS aanraakt. Die leest uw live DKIM-, SPF- en DMARC-records en toont wat ontvangers daadwerkelijk zien — inclusief of de selector resolvet en of een CNAME-doel verhaspeld is.
Publiceer de selector die de ondertekenaar daadwerkelijk gebruikt — de s=-waarde uit de header, niet die uit een oud draaiboek. Haal het record uit de beheerconsole van uw provider (Google Workspace DKIM instellen · Microsoft 365 DKIM instellen) en voeg het toe op exact s._domainkey.yourdomain.com.
Geef de voorkeur aan CNAME-delegatie boven het plakken van een TXT-sleutel. Biedt uw provider DKIM-CNAMEs aan, gebruik die dan: de sleutel leeft in hun zone, dus zij roteren hem zonder dat u DNS nog aanraakt — oorzaak 4 wordt onmogelijk. Vrijwel alle nieuwsbriefplatforms werken zo; zie Mailchimp/Brevo/Klaviyo-mails falen op DMARC.
Verifieer van buiten uw paneel. dig TXT s._domainkey.yourdomain.com +short (of dig CNAME … voor gedelegeerde selectors) vanaf een machine buiten uw netwerk. Dat het paneel het record toont, bewijst niets als de zone iets anders serveert.
Scan opnieuw en verstuur het testbericht opnieuw. Authentication-Results moet nu dkim=pass tonen. Werk daarna alles af wat de scan verder signaleert op de pagina repareer DKIM — een slagende handtekening die niet aligneert met uw From-domein faalt nog steeds op DMARC.

Hoe roteer ik DKIM-sleutels zonder deze fout te veroorzaken?

Rotatie is waar werkende opstellingen breken. De regel die het voorkomt: een selector wordt pas verwijderd nadat het laatste ermee ondertekende bericht is uitgestroomd — nooit op het omschakelmoment. Ondertekende mail leeft langer dan u denkt: retry-wachtrijen lopen dagen door, en doorgestuurde berichten worden opnieuw geverifieerd telkens wanneer ze bewegen.

Stap	Actie	Poort vóór de volgende stap
1. Toevoegen	Publiceer de nieuwe selector (`s2._domainkey…`) naast de oude	`dig` bevestigt dat hij van buitenaf resolvet
2. Omschakelen	Richt de ondertekenaar op de nieuwe selector	Testbericht toont `s=s2` en `dkim=pass`
3. Wachten	Laat de oude selector gepubliceerd terwijl onderweg zijnd, gequeued en doorgestuurd verkeer uitstroomt	≥ 7 dagen; volg DMARC-aggregaatrapporten totdat de oude selector niet meer verschijnt
4. Uitfaseren	Verwijder de oude sleutel — of beter, publiceer hem opnieuw met een lege `p=`-tag: “uitgefaseerd”, niet “nooit bestaan”	Begin hier nooit mee op het omschakelmoment — voortijdig verwijderen is oorzaak #1 van “no key for signature”

Met CNAME-delegatie draait uw provider precies dit draaiboek binnen de eigen zone en ziet u er nooit iets van — het sterkste argument om te delegeren.

Veelgestelde vragen

Is “no key for signature” een temperror of een permerror? Beide strings bestaan: temperror is een DNS-lookup die mislukte of verliep — voorbijgaand, vaak weg bij een nieuwe poging — terwijl permerror betekent dat DNS “no such record” antwoordde. Een temperror die bij meerdere ontvangers terugkeert, blijkt meestal ook een echt ontbrekend record. Controleer met dig en vertrouw het antwoord, niet het etiket.

Betekent deze fout dat iemand mijn domein spooft? Nee — een spoofer zou niet met uw selector ondertekenen. Het betekent dat uw eigen mail een handtekening draagt die ontvangers niet kunnen verifiëren, dus telt die als onondertekend en leunt DMARC op alleen SPF. Volledige, gealigneerde authenticatie is zeldzaam: slechts 10.092.481 van de 261.086.232 domeinen (3,87%) hadden de SPF+DKIM+DMARC-triade compleet in de Defaults.Exposed-census (gegevens per 2026-06-29).

Kan ik de oude selector gewoon verwijderen zodra de nieuwe werkt? Niet meteen. Berichten die ermee zijn ondertekend zitten nog in retry-wachtrijen en doorstuurpaden; de sleutel verwijderen breekt ze met terugwerkende kracht. Houd het oude record minstens een week aan, volg uw DMARC-rapporten totdat de oude selector niet meer verschijnt, en faseer hem daarna uit — bij voorkeur met een lege p= in plaats van verwijderen.

De checker van mijn provider zegt dat DKIM is geconfigureerd, maar ontvangers melden nog steeds no key. Hoe kan dat? Vrijwel altijd de CNAME-doelvalkuil: uw DNS-paneel heeft uw zone aan het doel geplakt (…esp.com.yourdomain.com), zodat het record bestaat maar nergens naartoe wijst. dig CNAME selector._domainkey.yourdomain.com +short toont het opgeslagen doel letterlijk — vergelijk het teken voor teken met wat de provider vroeg.

Stuur de eigenaar het rapport

Als u dit oplost voor een klant of uw werkgever, sluit dan de cirkel met bewijs. Voer de gratis scan opnieuw uit zodra de selector resolvet en stuur het beoordeelde rapport door naar de bedrijfseigenaar: gedateerd, in gewone taal, DKIM verifieert nu. Het is het bewijsstuk dat ze nodig hebben voor de cyberverzekeringsverlenging en de volgende leveranciersbeveiligingsvragenlijst — bewijs van een werkende maatregel, niet slechts een gesloten ticket.

Controleer uw DKIM gratis

Zie of uw selectors resolven — en precies wat u moet repareren — privé en alleen voor de eigenaar.

Controleer uw domein → · “DKIM signature not valid” → · Repareer DKIM → · DKIM instellen op Google Workspace → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.