DKIM instellen als bedrijf: complete stappengids voor DNS en Microsoft 365
DKIM zorgt dat uitgaande zakelijke e-mail cryptografisch wordt ondertekend. U publiceert de selector-DNS-records van uw mailprovider, activeert de handtekening in uw mailplatform en controleert daarna of ontvangers “dkim=pass” zien in plaats van een botsing met spamfilters. Dat is de kern van DKIM instellen voor een bedrijf: DNS-publicatie, activatie en vervolgens verificatie. Het resultaat is direct meetbaar in betere afleverbaarheid en minder kans dat uw domein wordt misbruikt voor spoofing.
Kort samengevat:
- Het correct configureren van DKIM vereist het nauwkeurig toevoegen van selectors en publieke sleutels in DNS, afhankelijk van de verzendbron en met aandacht voor hoofdlettergebruik en propagatietijden.
- Microsoft 365 gebruikt specifieke CNAME-records en biedt PowerShell-commando’s om DKIM te activeren, waarbij de status
Validaangeeft dat alles correct is ingesteld.- CNAME-records wijzen doorgaans door naar de infrastructuur van de provider, terwijl TXT-records zelfde publieke sleutel bevatten; bij moderne platforms is 2048-bits encryptie de standaard.
- Het testen van DKIM gebeurt door een externe mail te beoordelen op de aanwezigheid van een
dkim=pass-header en door gebruik te maken van online testtools voor verificatie.- Het uitbesteden van DKIM-beheer aan een gespecialiseerde partner zoals NLXS bespaart tijd, voorkomt fouten en zorgt voor snelle, betrouwbare implementatie en monitoring.
Inhoudsopgave
- Hoe stel je DKIM in voor je bedrijf: het stappenplan
- Microsoft 365 en DKIM: CNAME-syntaxis en PowerShell-commando’s
- Selectors, CNAME versus TXT en de juiste keysize
- Werkt DKIM echt? Zo test je het
- Sleutelrotatie, TTL en monitoring op de lange termijn
- Wat gaat er vaak mis bij DKIM en hoe los je dat op
- Wanneer schakelt u een ICT-partner in voor DKIM-beheer
- DKIM is geen doel op zichzelf
- DKIM-configuratie uitbesteden aan NLXS
- Bronnen
- Veelgestelde vragen
Hoe stel je DKIM in voor je bedrijf: het stappenplan
DKIM configureren voor bedrijven volgt in de praktijk altijd dezelfde volgorde, ongeacht welk mailplatform u gebruikt. De volgorde is belangrijker dan de details: sla een stap over en u krijgt een half werkende configuratie die nergens goed op reageert.
1. Bepaal wie uw mail daadwerkelijk verzendt.
Voordat u ook maar één DNS-record aanmaakt, moet u weten welke partij als verzendbron optreedt. Is dat Microsoft 365, Google Workspace, een marketingtool zoals Mailchimp, of een eigen mailserver? Elke bron heeft eigen selectors en eigen sleutels, en die moeten allemaal een plek krijgen in uw DNS.
2. Verkrijg de selector en de publieke sleutel.
Uw mailprovider genereert een sleutelpaar en geeft u een selectornaam (bijvoorbeeld selector1 of sig1) plus een bijbehorende CNAME- of TXT-waarde. Bij Microsoft 365 vindt u deze gegevens in Microsoft Defender voor Office 365, onder de instellingen voor e-mailauthenticatie.
3. Maak de juiste DNS-records aan.
Dit is de stap waar DKIM-record toevoegen vaak misgaat. De hostnaam volgt altijd het patroon selector._domainkey.uwdomein.nl, en de waarde is óf een CNAME die naar de infrastructuur van uw provider verwijst, óf een TXT-record met de publieke sleutel zelf. Welke van de twee u nodig heeft, bepaalt uw provider, niet u.
4. Activeer DKIM in het mailplatform.
Een DNS-record alleen doet niets. U moet de ondertekening ook daadwerkelijk inschakelen in het beheerpaneel van uw mailprovider. Bij zelfgehoste omgevingen gebeurt dit via de mailserver-configuratie, bijvoorbeeld met OpenDKIM.
5. Wacht op DNS-propagatie en test.
DNS-wijzigingen zijn niet direct overal zichtbaar. Reken op enkele uren, en bij sleutelrotatie bij Microsoft 365 zelfs op ongeveer 96 uur voordat de nieuwe sleutel overal actief is, zoals Microsoft Learn documenteert.
6. Stem SPF en DMARC af.
DKIM instellen zonder SPF en DMARC is als een slot op één deur zetten in een huis met drie ingangen. Zorg dat uw SPF-record de juiste verzendbonnen bevat en dat u minimaal een DMARC-record met beleid p=none publiceert om rapportages te ontvangen.
Enkele punten die in de praktijk vaak over het hoofd worden gezien:
- Selectors zijn hoofdlettergevoelig bij sommige registrars, dus kopieer ze exact.
- Sommige registrars voegen automatisch een punt toe aan het einde van een hostnaam; controleer dit dubbel.
- Test altijd vanuit een extern e-mailadres, nooit vanuit hetzelfde domein, om een realistisch beeld te krijgen.
- Documenteer welke selector bij welke verzendbron hoort, zeker als u meerdere mailtools gebruikt naast Microsoft 365.
Pro-tip: Maak een simpel overzicht (een spreadsheet volstaat) met per verzendbron de selectornaam, het recordtype en de datum van de laatste sleutelrotatie. Bij een storing scheelt dat uren zoeken.
Zodra deze zes stappen zijn doorlopen, hebt u de basis van hoe DKIM instellen werkt voor vrijwel elk zakelijk mailplatform. De volgende sectie gaat dieper in op de praktijk bij Microsoft 365, omdat dat platform net iets meer stappen en eigen commando’s vereist.
Microsoft 365 en DKIM: CNAME-syntaxis en PowerShell-commando’s
Microsoft 365 is voor veel Nederlandse bedrijven het startpunt, en het platform heeft een aantal eigenaardigheden die het waard zijn om apart te behandelen. De CNAME-waarden voor DKIM vindt u in het Microsoft Defender-portaal, onder E-mail & samenwerking > Beleidsregels & regels > Bedreigingsbeleid > E-mailverificatie instellingen. Daar ziet u per domein of DKIM actief is en welke twee CNAME-records nodig zijn.
De standaardsyntaxis ziet er zo uit voor een domein bedrijf.nl:
- Hostnaam:
selector1._domainkey.bedrijf.nl→ waarde:selector1-bedrijf-nl._domainkey.bedrijf.onmicrosoft.com - Hostnaam:
selector2._domainkey.bedrijf.nl→ waarde:selector2-bedrijf-nl._domainkey.bedrijf.onmicrosoft.com
Deze twee records zet u bij uw registrar of DNS-provider. Bij sommige registrars werkt Domain Connect, waardoor Microsoft de records automatisch kan plaatsen; ontbreekt die ondersteuning, dan voert u ze handmatig in.
Voor beheerders die liever met scripts werken dan met een portaal, biedt Exchange Online PowerShell drie kerncommando’s:
Get-DkimSigningConfigtoont de huidige status van DKIM per domein.New-DkimSigningConfigmaakt een nieuwe configuratie aan wanneer het domein nog geen DKIM-instellingen heeft.Set-DkimSigningConfig -Enabled $trueschakelt de ondertekening daadwerkelijk in nadat de CNAME-records geverifieerd zijn.
De status die Get-DkimSigningConfig teruggeeft, is direct bruikbaar voor troubleshooten.** NoDKIMKeys betekent dat er nog geen configuratie is aangemaakt. CnameMissing betekent dat Microsoft de CNAME-records niet in DNS kan vinden, meestal door een tikfout in de selectornaam of doordat propagatie nog niet is afgerond. Valid bevestigt dat alles correct staat en actief is.
Eén detail dat regelmatig verwarring geeft: sommige gebruikers zien via een externe DNS-query maar één van de twee selectors actief, terwijl de andere geen antwoord geeft. Dat is meestal geen fout, maar ontwerp van hoe Microsoft de sleutelrotatie tussen selector1 en selector2 afhandelt.
Wanneer u de sleutels roteert, gebeurt dat via die twee selectors: terwijl de ene actief blijft, wordt de andere voorbereid. Na de omschakeling duurt het meerdere dagen voordat de nieuwe sleutel overal in de Microsoft-datacenters is doorgevoerd, dus plan rotatie nooit vlak voor een belangrijke mailcampagne.
Selectors, CNAME versus TXT en de juiste keysize
Elk DKIM-record volgt hetzelfde formaat: selector._domainkey.uwdomein.nl. De selector is een vrij te kiezen naam die uw provider meestal al voor u bepaalt, en de puntnotatie met _domainkey is vastgelegd in RFC 6376, de officiële DKIM-specificatie.
Een CNAME-record wijst simpelweg door naar een record dat uw provider zelf beheert:
mail._domainkey.bedrijf.nl→ CNAME →mail.bedrijf.dkim.provider.com
Een TXT-record bevat de publieke sleutel direct in uw eigen DNS:
mail._domainkey.bedrijf.nl→ TXT →v=DKIM1; k=rsa; p=MIGfMA0GCSq...
Providers zoals Microsoft 365 en de meeste grote mailplatformen kiezen voor CNAME, omdat zij dan sleutels kunnen roteren zonder dat u iets in uw eigen DNS moet aanpassen. TXT-records zijn typisch nodig wanneer u zelf sleutels genereert, bijvoorbeeld bij een eigen mailserver met OpenDKIM of bij sommige e-mailmarketingtools die geen CNAME-ondersteuning bieden.
Over keysize, oftewel dkim 1024 vs 2048, bestaat weinig discussie meer in de praktijk: 2048 bit is de huidige standaard voor nieuwe implementaties. Een sleutel van 1024 bit is technisch nog steeds werkend, maar biedt aanzienlijk minder cryptografische marge en wordt door beveiligingsrichtlijnen inmiddels als verouderd beschouwd. Het enige praktische nadeel van 2048 bit is een iets langere TXT-waarde, wat bij een handjevol oudere DNS-systemen tot fragmentatieproblemen kan leiden. Voor de overgrote meerderheid van bedrijven is dat geen reden om voor 1024 bit te kiezen.
Werkt DKIM echt? Zo test je het
Na activatie wilt u zekerheid, niet aannames. Test met deze stappen:
- Stuur een testmail naar een extern adres, bijvoorbeeld een Gmail-account, en bekijk de volledige headers via “origineel bericht weergeven” of vergelijkbare functie.
- Zoek de
DKIM-Signatureheader en controleer de waarden achters=(de selector) end=(het domein). Kloppen deze met wat u in DNS heeft gepubliceerd? - Gebruik een externe testtool zoals de e-mailtest van internet.nl, die per verzendbron laat zien of DKIM, SPF en DMARC correct samenwerken.
- Interpreteer de uitslag: “geen sleutel gevonden” wijst meestal op een DNS-fout of propagatie die nog niet is afgerond, “fail” wijst op een mismatch tussen sleutel en handtekening, en “pass” bevestigt dat alles werkt.
Een veelvoorkomende valkuil is dat testtools soms “niet-testbaar” tonen, terwijl DKIM wel degelijk actief is. Dat komt door verschillen in hoe nameservers reageren op een DNS-query: het verschil tussen een NOERROR-antwoord zonder resultaat en een NXDOMAIN-antwoord kan testtools in verwarring brengen, zoals blijkt uit de resultaten van internet.nl.
Pro-tip: Test altijd twee keer met een tussenpoos van een paar uur. Eén enkele “fail” direct na het aanmaken van een record zegt vaak meer over propagatietijd dan over een echte fout.
Sleutelrotatie, TTL en monitoring op de lange termijn
DKIM instellen is geen eenmalige klus. Sleutels verouderen, en periodiek roteren beperkt de schade als een sleutel ooit gecompromitteerd raakt. Bij Microsoft 365 gebeurt dit via de twee selectors die elkaar afwisselen; reken op ongeveer 96 uur voordat een nieuwe sleutel volledig actief is in alle datacenters.
Voor de TTL-waarde van uw DKIM-records geldt een simpele vuistregel: te laag geeft onnodige DNS-belasting, te hoog vertraagt elke wijziging onnodig. Een TTL tussen 3.600 en 14.400 seconden (1 tot 4 uur) is voor de meeste bedrijven een goede balans tussen snelheid bij wijzigingen en stabiliteit in het dagelijkse gebruik.
Monitoring hoeft niet ingewikkeld te zijn. Periodieke controle via een testtool, gecombineerd met DMARC-rapportages die u laten zien welk percentage van uw mail slaagt of faalt op DKIM, geeft al een goed beeld. Grotere organisaties automatiseren dit met scripts die maandelijks de DNS-records tegen de verwachte waarden controleren.
Wat gaat er vaak mis bij DKIM en hoe los je dat op
De meeste DKIM-problemen zijn saai en voorspelbaar, wat goed nieuws is: ze zijn ook snel te verhelpen.
- Tikfouten in de selectornaam of het CNAME-doel zijn de meest voorkomende oorzaak van een
CnameMissing-status; controleer letter voor letter tegen wat uw provider aangeeft. - Forwarding en mailinglijsten wijzigen berichtheaders, wat een geldige handtekening ongeldig kan maken. Overweeg canonicalization in te stellen op “relaxed” voor headers, zodat kleine wijzigingen tijdens transport de handtekening niet direct breken.
- DNS-propagatie is nog niet voltooid, vaak verward met een echte configuratiefout. Wacht enkele uren en test opnieuw voordat u verder gaat zoeken.
- De registrar ondersteunt geen CNAME met onderstrepingstekens, wat bij een klein aantal verouderde DNS-panelen voorkomt; neem in dat geval contact op met de support van uw registrar.
Wanneer schakelt u een ICT-partner in voor DKIM-beheer
Niet elk bedrijf heeft een IT-afdeling die selectors, PowerShell-commando’s en propagatietijden erbij kan pakken naast de dagelijkse werkzaamheden. Een ICT-partner kan deze taken overnemen: DNS-publicatie, verificatie na iedere wijziging, monitoring van de status, en periodieke sleutelrotatie zonder dat u er zelf achteraan moet.
Sommige ICT-partners ontzorgen organisaties met veilige webhosting en infrastructuur die is afgestemd op hun specifieke situatie. Een structurele aanpak van DKIM, SPF en DMARC wordt vaak onderdeel van vast onderhoud in plaats van een losse actie.
DKIM is geen doel op zichzelf
DKIM lost precies één probleem op: het bevestigt dat een bericht ongewijzigd is verzonden vanaf een geautoriseerde bron. Dat is waardevol, maar het vertelt een ontvanger nog niets over wat er moet gebeuren als de controle faalt. Daarom is de gangbare aanbeveling om DKIM los te zien van SPF en DMARC een misvatting die bedrijven blijft achtervolgen.
De meeste winst zit niet in het instellen zelf, maar in wat daarna gebeurt: monitoring, tijdige sleutelrotatie en een DMARC-beleid dat daadwerkelijk actie afdwingt. Wie dat combineert met heldere interne afspraken over wie verantwoordelijk is bij een storing, bouwt een e-mailbeveiliging die standhoudt.
— Ken
DKIM-configuratie uitbesteden aan NLXS
NLXS is voor DKIM, SPF en DMARC wat een vaste ICT-partner altijd zou moeten zijn: iemand die het technische gedoe overneemt zodat u zich weer met uw bedrijf kunt bezighouden. Waar veel bedrijven zelf uren besteden aan selectors, CNAME-syntaxis en propagatietijden, regelt NLXS domeinverificatie inclusief DKIM-publicatie binnen één dag, met dezelfde snelle probleemoplossing die klanten als de TU Eindhoven en JCI Breda al ervaren.
Naast domeinverificatie combineert NLXS dit vaak met managed webhosting of volledige ICT-dienstverlening, zodat DNS, mailbeveiliging en serverbeheer bij één aanspreekpunt liggen in plaats van verspreid over meerdere leveranciers. Geen verrassingen in de factuur, geen wekenlang wachten op een reactie. Vraag een gratis ICT-scan aan of plan een kennismakingsgesprek via Nlxs om te bepalen hoe uw DKIM-, SPF- en DMARC-configuratie er nu voorstaat.
Bronnen
Voor verdere verdieping zijn deze bronnen relevant:
- Microsoft Learn — Configure DKIM for your custom domain
- Internet.nl e-mailtest — DKIM, SPF en DMARC checks
Veelgestelde vragen
Hoe stel ik DKIM in voor mijn bedrijf?
U verkrijgt een selector en sleutel van uw mailprovider, maakt het bijbehorende CNAME- of TXT-record aan in uw DNS, en activeert de ondertekening in het mailplatform. Test daarna met een externe testmail of de header “dkim=pass” toont, zoals beschreven in het stappenplan hierboven.
Is DKIM verplicht voor bedrijven?
Voor overheidsdomeinen in Nederland is toepassing van SPF, DKIM en DMARC verplicht volgens de streefbeeldafspraken van Forum Standaardisatie en het NCSC. Voor commerciële bedrijven is het niet wettelijk verplicht, maar zonder DKIM accepteren veel grote mailproviders uw berichten steeds moeilijker.
Hoe stel ik DKIM in voor Microsoft 365?
U vindt de twee benodigde CNAME-waarden in Microsoft Defender onder e-mailverificatie instellingen, voegt deze toe bij uw registrar, en schakelt DKIM in met het commando Set-DkimSigningConfig -Enabled $true in PowerShell. De status Valid bij Get-DkimSigningConfig bevestigt dat de configuratie werkt, zoals Microsoft Learn uitlegt.
Wat is DKIM precies?
DKIM staat voor DomainKeys Identified Mail en is een cryptografische handtekening die aan uitgaande e-mail wordt toegevoegd om te bewijzen dat het bericht daadwerkelijk van het opgegeven domein komt en niet is gewijzigd tijdens transport. De specificatie is vastgelegd in RFC 6376.
Wat is het verschil tussen DKIM 1024 en 2048 bit?
Een sleutel van 2048 bit biedt aanzienlijk meer cryptografische marge dan 1024 bit en is de huidige standaard voor nieuwe DKIM-implementaties. 1024 bit werkt technisch nog, maar geldt inmiddels als verouderd en wordt afgeraden voor nieuwe configuraties.
Reacties0
Nog geen reacties
Deel als eerste uw gedachten.
Meld u aan of registreer u om een reactie te plaatsen.