DKIM faalt na het wisselen van e-mailtool: de CNAME- en selector-migratiegids (2026)

Gepubliceerd 2026-07-08

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

DKIM breekt na een toolwissel om twee mechanische redenen: uw DNS-paneel heeft de CNAME-doelen van de nieuwe tool verhaspeld — meestal door uw eigen zone eraan vast te plakken — of de selectors van de oude tool zijn verwijderd voordat de mail ervan was uitgestroomd. Slechts 3,87% van de domeinen — 10.092.481 — heeft de SPF+DKIM+DMARC-triade compleet, volgens de Defaults.Exposed-census van 261.086.232 beoordeelde domeinen.

De volgorde van de fix: scan het domein, controleer daarna van elke nieuwe CNAME het opgeslagen doel met dig — een doel dat eindigt op uw eigen domeinnaam is het rokende pistool. Herstel de records bij de autoritatieve nameservers, bevestig dat de nieuwe tool ondertekent en slaagt voordat u echte mail erdoorheen routeert, en houd de selectors van de oude tool gepubliceerd totdat het verkeer ervan is uitgestroomd.

Waarom brak DKIM toen u van tool wisselde?

Aan DKIM zelf is niets veranderd — aan uw selectors wel. De oude tool ondertekende met haar selectors; de nieuwe ondertekent met andere, meestal gedelegeerd via twee of drie CNAME-records die tijdens de onboarding zijn toegevoegd. Vier valkuilen verklaren vrijwel elk DKIM-falen na een migratie:

Uw DNS-paneel heeft uw zone aan het CNAME-doel geplakt. Veel panelen behandelen elke geplakte hostnaam als relatief en slaan stilletjes target.provider.com.yourdomain.com op in plaats van target.provider.com. Het record bestaat, het paneel toont een groen vinkje, en het resolvet naar niets.
Verwarring over de punt aan het einde. Sommige panelen vereisen een afsluitende punt (target.provider.com.) in de betekenis “absoluut — plak mijn zone er niet aan”; andere wijzen de punt af als ongeldig en regelen absoluutheid zelf. Dezelfde geplakte waarde is juist in het ene paneel en verhaspeld in het volgende.
De selectors van de oude tool zijn op de wisseldag verwijderd. Mail die de oude tool al heeft ondertekend, zit dagenlang in retry-wachtrijen en doorstuurpaden; haar selectors verwijderen — of het oude account sluiten, wat haar gedelegeerde CNAMEs doodt — breekt die mail met terugwerkende kracht.
U hebt geverifieerd bij de verkeerde nameservers. Omvatte de migratie een nameserverwissel, dan kunnen de gerepareerde records bij de ene NS-set bestaan terwijl ontvangers nog de andere bevragen.

Slechts 51,84% van de 261 miljoen domeinen in de census toont op het scanmoment een vindbare DKIM-sleutel (gegevens per 2026-06-29).

Dezelfde migratie laat meestal ook SPF-puin achter — 1.013.416 domeinen, ongeveer 1 op de 138 van de domeinen die SPF proberen, draaien twee v=spf1-records, het klassieke teken dat een providerwissel een record heeft toegevoegd in plaats van samengevoegd. Die kant van de verhuizing heeft een eigen gids: SPF werkt niet meer na wisselen van e-mailprovider.

Hoe herken ik een verhaspeld CNAME-record?

Vertrouw het paneel niet — vraag DNS wat het daadwerkelijk heeft opgeslagen. Vraag voor elke selector die de nieuwe tool u gaf het CNAME-doel op. Een illustratief voorbeeld, naar het model van een SendGrid-achtige gedelegeerde selector (de doelvorm van uw provider zal afwijken):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

De provider vroeg om s1.domainkey.u1234567.wl123.sendgrid.net — maar het opgeslagen doel eindigt op .yourdomain.com. Het paneel heeft de zone eraan geplakt; die naam resolvet naar niets, dus ontvangers vinden geen sleutel. De gezonde versie:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Eén afsluitende punt in de dig-uitvoer is normaal — die markeert een volledig gekwalificeerde naam.) Is het doel juist, volg het dan één stap verder: dig TXT s1._domainkey.yourdomain.com +short moet de sleutel van de provider teruggeven. Een leeg antwoord bij een correcte CNAME betekent dat het probleem aan de providerkant van de delegatie zit — rond hun verificatiestap af, of zie DKIM “no key for signature” voor de diagnose op selectorniveau.

Het migratiedraaiboek: vóór, tijdens, na

Het falen zit meestal niet in de records — het zit in de volgorde. DKIM-migraties gaan mis op het omschakelmoment omdat de verificatie na de wissel plaatsvindt, wanneer echte mail al faalt.

Fase	Wat te doen	Poort voordat u verdergaat
Vóór de wissel	Voeg de DKIM-CNAMEs van de nieuwe tool toe (en de bounce-domeinrecords), en bewijs ze daarna: `dig` het opgeslagen doel van elke CNAME van buiten uw netwerk, rond de eigen verificatiestap van de tool af en stuur via de nieuwe tool een test naar een mailbox die u beheert	Testbericht toont `dkim=pass` met `d=` = uw domein — routeer nooit echte mail door een ongeverifieerde tool
Wisseldag	Verplaats echt verkeer naar de nieuwe tool. Raak niets aan dat van de oude tool is: laat haar selectors, CNAMEs en account in leven	Mail van de nieuwe tool slaagt bij echte ontvangers; de oude tool blijft slagen voor alles wat er nog doorheen stroomt
Na het uitstromen	Volg de DMARC-aggregaatrapporten totdat de selectors van de oude tool niet meer verschijnen (retry-wachtrijen en doorsturingen lopen dagen door — reken op een week of meer), trek daarna haar records en account in	Oude selectors ≥ 7 dagen afwezig in de rapporten vóór verwijdering

De vetgedrukte rij is waar migraties worden gered of verloren: elke controle erin kan dagen vóór de omschakeling gebeuren, met nul risico voor live mail. De mechaniek van selector-uitfasering — inclusief waarom opnieuw publiceren met een lege p= beter is dan verwijderen — staat in het rotatiedraaiboek; deze tabel gaat over de volgordelijkheid van de toolwissel zelf.

Hoe repareer ik DKIM na de wissel?

Voer de gratis scan uit op defaults.exposed voordat u DNS aanraakt. Die leest uw live records en toont wat ontvangers daadwerkelijk zien — inclusief CNAME-doelen waar de zone aan vastgeplakt is en selectors die niet resolven.
Noteer de DKIM-records die de nieuwe tool verwacht. Uit haar beheerconsole — voor mailboxproviders tonen de installatiegidsen voor Google Workspace en Microsoft 365 waar; nieuwsbrief- en CRM-tools vermelden hun CNAMEs onder domeinauthenticatie (zie Mailchimp/Brevo/Klaviyo-mails falen op DMARC).
Controleer de opgeslagen waarde van elk record met dig CNAME <name> +short en vergelijk die teken voor teken met wat de tool vroeg. Een doel dat eindigt op uw eigen domein = zone-aangeplakt; voer het opnieuw in, en blijft het paneel aanplakken, voeg dan de afsluitende punt toe (of verwijder die, als het paneel punten afwijst).
Verifieer bij de autoritatieve nameservers. dig +short NS yourdomain.com, herhaal daarna de CNAME-controles @<die nameserver>. Heeft de migratie de nameservers gewijzigd, controleer dan beide sets — ontvangers kunnen de oude blijven bevragen totdat de delegatie is doorgevoerd.
Voer de verificatie van de tool opnieuw uit en stuur een testbericht. De Authentication-Results-header moet dkim=pass tonen met d= gelijk aan uw domein — een pass op het standaarddomein van de tool aligneert niet voor DMARC.
Laat de selectors van de oude tool gepubliceerd totdat haar mail is uitgestroomd, en trek ze daarna bewust in. Scan vervolgens opnieuw en werk alles af wat verder wordt gesignaleerd op de pagina repareer DKIM.

Veelgestelde vragen

Heb ik de afsluitende punt op mijn DKIM-CNAME nodig of niet? Dat hangt volledig van het paneel af. De punt betekent “absolute naam — plak mijn zone er niet aan”; sommige panelen vereisen hem, sommige voegen hem voor u toe, sommige wijzen hem af. De enige test die telt is de uitvoer van dig CNAME <selector>._domainkey.yourdomain.com +short na het opslaan: eindigt het doel op uw eigen domein, dan heeft het paneel de zone aangeplakt en hebt u de punt (of een ander invoerformaat) nodig.

Mag ik de DKIM-records van de oude tool op de wisseldag verwijderen? Nee. Mail die de oude tool heeft ondertekend zit nog in retry-wachtrijen en doorstuurpaden, en het verwijderen van de sleutel waarnaar die verwijst breekt die berichten met terugwerkende kracht. Houd de oude selectors live totdat ze niet meer in uw DMARC-aggregaatrapporten verschijnen — een week of langer — en sluit ook het oude account niet eerder.

Mijn DNS-paneel en de nieuwe tool zeggen allebei “verified”, maar ontvangers laten DKIM nog steeds falen. Hoe kan dat? Twee veelvoorkomende gevallen: de tool verifieerde tegen een gecachte controle terwijl de autoritatieve nameservers iets anders serveren (bevraag ze rechtstreeks met dig @<ns>), of DKIM slaagt maar op het standaard-ondertekeningsdomein van de tool in plaats van het uwe, zodat DMARC alsnog faalt op alignment. De scan maakt het onderscheid.

Kunnen de DKIM-records van beide tools naast elkaar bestaan tijdens de overlap? Ja — en dat hoort ook. DKIM kent geen één-record-regel: elke selector is een eigen DNS-naam, dus de records van beide tools staan zonder conflict naast elkaar, waardoor de regel houd-oude-selectors-tot-het-uitstromen gratis te volgen is. (SPF is het tegenovergestelde — twee v=spf1-records maken het ongeldig, en daarom draait de SPF-migratiegids om samenvoegen.)

Stuur de eigenaar het rapport

Voert u deze migratie uit voor een klant of uw werkgever, sluit haar dan af met bewijs. Zodra de nieuwe tool ondertekent en aligneert, voert u de gratis scan opnieuw uit en stuurt u het beoordeelde rapport door naar de bedrijfseigenaar: gedateerd bewijs in gewone taal dat de wissel het domein volledig geauthenticeerd heeft achtergelaten. Het is het bewijsstuk dat ze nodig hebben voor de cyberverzekeringsverlenging en de volgende leveranciersbeveiligingsvragenlijst — het maakt van “de migratie is klaar” een document in plaats van een bewering.

Controleer uw DKIM gratis

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

Controleer uw domein → · SPF kapot na wisselen van provider → · Repareer DKIM → · DKIM instellen op Google Workspace → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.