Waarom DKIM niet altijd automatisch geactiveerd kan worden
Het controlepaneel kan de DKIM-sleutel wél altijd genereren, maar het kan de bijhorende DNS-record niet altijd zelf publiceren. En zonder die publicatie doet DKIM niets. Dat verschil zit in wie de controle heeft over de DNS-zone en over de uitgaande mailstroom.
1. De DNS-zone wordt extern beheerd
DKIM leeft in DNS, niet op de mailserver. Het controlepaneel kan enkel records schrijven in zones die het zelf beheert. Wijzen de nameservers van uw domein naar Cloudflare, naar uw registrar (bijv. Openprovider, Combell, GoDaddy), of naar een DNS-server van een derde partij, dan heeft Enhance daar geen schrijfrechten. De sleutel wordt aangemaakt en getoond, maar de record moet u handmatig overzetten.
Dit is de meest voorkomende reden. De hosting staat bij ons, de DNS niet.
2. E-mail loopt via een externe provider
Als uw mail niet via onze servers verstuurd wordt, maar via bijvoorbeeld:
- Microsoft 365 / Exchange Online
- Google Workspace
- Amazon SES
- Mailchimp, Brevo, Mailjet, ActiveCampaign
- een CRM- of ERP-pakket dat zelf mail verstuurt
… dan tekent die provider de mails, niet onze server. Elke provider heeft zijn eigen sleutelpaar en zijn eigen selector (bijv. selector1._domainkey bij Microsoft 365, of s1._domainkey en s2._domainkey bij een SES-configuratie). De DKIM-sleutel die ons controlepaneel genereert, staat volledig los daarvan en zou op die mails niets verifiëren.
Het paneel kan onmogelijk raden welke externe diensten u gebruikt, welke selectors die hanteren, of welke sleutels ze verwachten. Die records moeten uit het dashboard van die provider komen.
3. Gemengde mailstromen
In de praktijk versturen veel domeinen mail vanuit meerdere bronnen tegelijk: het contactformulier op de website via de hostingserver, de dagelijkse correspondentie via Microsoft 365, en de nieuwsbrief via Mailchimp. Elk van die drie heeft een eigen DKIM-record nodig.
Meerdere DKIM-records naast elkaar zijn geen probleem — zolang de selectors verschillen. Maar automatische activatie kan die situatie niet inschatten en zou hoogstens één van de drie afdekken. Een half ingestelde configuratie geeft een vals gevoel van veiligheid en levert alsnog dkim=fail op voor twee van de drie mailstromen.
4. Bestaande records en risico op conflict
Sommige domeinen hebben al een DKIM-record staan, uit een eerdere migratie of van een vorige hoster. Automatisch overschrijven zou lopende mailstromen kunnen breken. Om die reden gebeurt de publicatie bewust met een menselijke controle ertussen.
5. Delegatie en beperkingen bij de registrar
Een aantal registrars en DNS-panelen laten geen lange TXT-waarden toe, kappen ze af boven de 255 tekens, of bieden geen API waarmee een extern systeem records kan aanmaken. Zelfs als het controlepaneel de record zou willen publiceren, kan het dat technisch niet.
Wanneer het wél automatisch gaat
DKIM wordt automatisch gepubliceerd wanneer alle onderstaande punten kloppen:
- De DNS-zone van het domein draait op onze nameservers en wordt beheerd binnen Enhance;
- De uitgaande mail voor het domein loopt via onze mailservers;
- Er staat nog geen conflicterende
_domainkey-record in de zone.
In alle andere gevallen genereert het paneel de sleutel, maar publiceert u de record zelf — of haalt u ze op bij de externe mailprovider.
Praktische regel
DKIM hoort bij de verzender, niet bij de hoster.
Stel uzelf bij elke mailstroom de vraag: welke server zet deze mail effectief op het net? Die partij levert de DKIM-record. Verstuurt u vanuit drie systemen, dan hebt u drie records nodig.
