Dev / CodingAI-generated

DKIM en DMARC instellen in Microsoft 365: waarom het belangrijk is en hoe je het doet

Vorige week deed ik een M365-security audit voor een klant. Secure Score: 72% — niet slecht. Maar tussen de bevindingen stond iets dat ik vaker zie bij kleinere organisaties: DKIM uitgeschakeld en geen DMARC record.

Dit zijn geen exotische beveiligingsmaatregelen. Ze zijn de basis van e-mailauthenticatie. Zonder ze kan iemand e-mails versturen die er uitzien alsof ze van jouw domein komen — en veel mailservers zullen ze gewoon doorlaten.

In dit artikel leg ik uit wat DKIM en DMARC doen, hoe ze samenhangen met SPF, en hoe je ze stap voor stap instelt in Microsoft 365.

De drie pijlers van e-mailauthenticatie

Voordat we aan de slag gaan: een korte uitleg van SPF, DKIM en DMARC. Ze werken samen, maar doen elk iets anders.

SPF — wie mag mailen namens jouw domein?

SPF (Sender Policy Framework) is een DNS-record dat bepaalt welke mailservers e-mail mogen versturen namens jouw domein. Een ontvangende mailserver controleert: "komt dit bericht van een IP-adres dat het SPF-record van dit domein toestaat?"

SPF beschermt tegen spoofing op het envelope-niveau — de technische afzender die de meeste gebruikers nooit zien.

DKIM — is dit bericht onderweg niet gemanipuleerd?

DKIM (DomainKeys Identified Mail) voegt een digitale handtekening toe aan elke uitgaande e-mail. De ontvangende server controleert die handtekening met een publieke sleutel die in je DNS staat.

Als de handtekening klopt, weet je twee dingen: het bericht komt echt van jouw mailsysteem, en de inhoud is onderweg niet aangepast.

DMARC — wat moet er gebeuren als SPF of DKIM faalt?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is het beleid dat bovenop SPF en DKIM staat. Het vertelt ontvangende mailservers wat ze moeten doen als een bericht de checks niet doorstaat: accepteren, in quarantaine plaatsen of weigeren.

DMARC stuurt ook rapporten — je kunt zien welke bronnen e-mail versturen namens jouw domein.

De drie records werken als een keten: SPF en DKIM leveren het bewijs, DMARC bepaalt wat er met mislukt bewijs gebeurt.

Waarom ontbreken ze zo vaak?

Bij kleine organisaties zie ik twee oorzaken:

  1. Ze waren er nooit — bij het opzetten van de tenant is alleen het SPF-record aangemaakt (Microsoft doet dat gedeeltelijk automatisch), maar DKIM en DMARC zijn handmatige stappen die documentatie vereisen.

  2. Ze zijn vergeten na een migratie — als je overstapt naar een nieuwe mailprovider of een extra verzenddomein toevoegt (Exclaimer, Mailchimp, SendGrid), moet je de DNS-records bijwerken. Dat wordt regelmatig vergeten.

DKIM instellen in Microsoft 365

Stap 1: CNAME-records aanmaken bij je DNS-provider

Microsoft 365 gebruikt twee CNAME-records voor DKIM. Je vindt de exacte waarden in het Microsoft 365 Defender-portaal.

Ga naar: security.microsoft.com → Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM

Selecteer je domein. Je ziet twee CNAME-records die je moet aanmaken:

selector1._domainkey.jouwdomein.nl  →  selector1-jouwdomein-nl._domainkey.jouwtenant.onmicrosoft.com
selector2._domainkey.jouwdomein.nl  →  selector2-jouwdomein-nl._domainkey.jouwtenant.onmicrosoft.com

De exacte waarden zijn tenant-specifiek — kopieer ze uit het portaal, typ ze niet over.

Maak deze twee CNAME-records aan bij je DNS-provider (Oxilion, TransIP, Cloudflare, of wie je DNS beheert).

Stap 2: Wacht op DNS-propagatie

DNS-wijzigingen hebben tijd nodig — meestal 15 minuten tot een uur, soms langer. Je kunt de propagatie controleren met:

nslookup -type=CNAME selector1._domainkey.jouwdomein.nl

Of via een online DNS-checker.

Stap 3: DKIM activeren in M365

Terug in het Defender-portaal, selecteer je domein en klik Enable. Als de CNAME-records correct zijn aangemaakt en gepropageerd, activeert DKIM direct.

Is de knop nog grijs of krijg je een foutmelding? DNS is nog niet gepropageerd. Wacht en probeer opnieuw.

DMARC instellen

DMARC is een TXT-record in je DNS. Begin altijd met een monitor-only policy — je wilt eerst zien wat er gebeurt voordat je berichten gaat weigeren.

Minimale DMARC-record

Naam:   _dmarc.jouwdomein.nl
Type:   TXT
Waarde: v=DMARC1; p=none; rua=mailto:dmarc-reports@jouwdomein.nl

De drie onderdelen:

  • v=DMARC1 — versie, altijd zo
  • p=none — beleid: monitor alleen, geen actie bij mislukking
  • rua= — stuur geaggregeerde rapporten naar dit e-mailadres

Van none naar quarantine of reject

Na een paar weken monitor-only kun je de rapporten analyseren. Zie je alleen legitieme bronnen? Verhoog het beleid:

p=quarantine   → verdachte berichten gaan naar spam
p=reject       → verdachte berichten worden geweigerd

Doe dit stapsgewijs. Stel eerst p=quarantine; pct=10 in (geldt voor 10% van het verkeer), observeer een week, verhoog dan naar 25%, 50%, 100%, en uiteindelijk p=reject.

Haast je niet naar p=reject zonder de rapporten te lezen. Als je een externe mailprovider gebruikt (nieuwsbriefsoftware, ticketsysteem, boekhoudpakket) die nog niet in je SPF staat, worden die berichten geweigerd.

SPF: de veelgemaakte fout

Zolang je bezig bent: controleer je SPF-record. Een veelgemaakte fout is ~all (soft fail) in plaats van -all (hard fail) aan het einde.

v=spf1 include:spf.protection.outlook.com -all

Het verschil: ~all zegt "berichten van onbekende bronnen zijn verdacht". -all zegt "wijs ze af". De meeste tenants staan op ~all omdat Microsoft dat als standaard instelt. Met DMARC op p=reject maakt het minder uit, maar het is netter om ook SPF hard te laten falen.

Let op: elke externe mailprovider die je gebruikt (Mailchimp, SendGrid, Exclaimer) moet een include: entry hebben in je SPF-record. Mis je er een, dan falen berichten van die provider de SPF-check.

Controleren of het werkt

Stuur een testmail naar een Gmail-adres en bekijk de headers. Zoek naar:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@jouwdomein.nl
  spf=pass
  dmarc=pass

Alle drie op pass? Je e-mailauthenticatie staat correct ingesteld.

Alternatief: gebruik mail-tester.com — plak het testadres in je mailclient, stuur een bericht, en je krijgt een gedetailleerde score met uitleg per onderdeel.

Tot slot

DKIM en DMARC zijn geen rocket science, maar ze vereisen wel aandacht voor detail — de juiste DNS-records op de juiste plek, in de juiste volgorde. De meeste problemen die ik zie komen door haast: DKIM activeren voordat de CNAME-records gepropageerd zijn, of DMARC op p=reject zetten voordat alle verzendende bronnen in kaart zijn.

Neem de tijd, begin met p=none, lees de rapporten. Twee weken geduld levert een robuuste configuratie op die jaren meegaat.