DMARC voor Nederlandse overheden — Logius pas-toe-of-leg-uit toegelicht

Sinds 2020 staat DMARC op de "pas toe of leg uit"-lijst van Forum Standaardisatie. In 2026 is "uitleggen" geen optie meer voor de meeste overheidsorganisaties — Logius rapporteert publiek welke gemeenten en ZBO's nog onder de norm presteren, en de NIS2-implementatiewet maakt het bestuurlijk aansprakelijk. Toch zien we wekelijks gemeenten met een DMARC-record op p=none, vaak omdat de uitvoering bij een externe IT-dienstverlener ligt die de overheidseisen niet kent.

Dit artikel doorloopt wat Logius letterlijk verlangt, welke records dat technisch impliceert, en waar de meest voorkomende uitvoeringsfouten zitten.

Wat staat er precies op de pas-toe-of-leg-uit-lijst

Voor overheidscommunicatie via e-mail noemt Forum Standaardisatie zes verplichte technische standaarden. In volgorde van wat een MSP doorgaans als eerste fixt:

1. SPF — moet eindigen op een hardfail (-all). Niet ~all, niet ?all.
2. DKIM — minimaal RSA-2048 of Ed25519, per uitzendend systeem een eigen selector.
3. DMARC — policy p=reject. Niet p=quarantine, niet p=none. Bovendien pct=100.
4. STARTTLS + DANE — opportunistische TLS is niet genoeg; je MX moet een TLSA-record publiceren én SMTP-server-side DANE valideren.
5. DNSSEC — DS-records bij de registry, signed zone, RRSIG over alle relevante records.
6. IPv6 — MX-hosts moeten via AAAA bereikbaar zijn.

Vier van de zes (SPF, DKIM, DMARC, STARTTLS/DANE) raakt SenderProof direct. De andere twee (DNSSEC en IPv6) zijn een DNS-hostingvraag — wij detecteren of ze er staan en flaggen ontbrekende configuratie, maar de implementatie gebeurt bij je registrar of bij Logius' eigen DNS-omgeving.

De "leg uit"-route bestaat technisch niet meer

Voor 2024 kon je in de Forum-rapportage onderbouwen waarom een norm nog niet was ingevoerd. Sinds de NIS2-implementatie (en de aansluitende update van het Logius-handvest) is die exception voor de essentiële en belangrijke entiteiten effectief afgesloten. Concreet betekent dat:

• Gemeenten, provincies, waterschappen, ministeries en zelfstandige bestuursorganen krijgen dwingende deadlines.
• Niet-naleving wordt opgenomen in het jaarlijkse Forum-rapport én in het NIS2-toezichtsregime van NCSC.
• Bestuurlijke aansprakelijkheid is verplaatst naar de directie — IT-uitvoering als excuus telt niet meer.

Voor een MSP betekent dit dat overheidsklanten je gaan vragen om aantoonbare compliance. Een spreadsheet met scores volstaat niet meer — auditors willen een geautomatiseerd evidence-pack dat hen toont welke records vandaag actief zijn, welke historisch hebben gestaan, en welke alerts er bij regressies zijn uitgegaan.

Waar het meestal misgaat

1. SPF eindigt op ~all "voor de zekerheid"

Een veelvoorkomende keuze bij IT-afdelingen die historisch e-mailproblemen hebben gehad. Probleem: ~all (softfail) telt voor Logius als niet voldaan. Mailservers behandelen softfails inconsistent — Gmail accepteert ze, Outlook markeert ze, andere reject'en. De norm vereist -all.

Pragmatisch: voor je naar -all gaat, run een week DMARC-monitoring met p=none en valideer dat al je legitieme afzenders in de SPF staan. Wij doen die analyse automatisch en geven per source-IP aan of hij in je huidige SPF zit.

2. DMARC blijft op p=quarantine hangen

Veel implementaties stoppen op p=quarantine omdat p=reject "eng" voelt. Voor Logius is dat geen voldoende — alleen p=reject met pct=100 telt. De tussenstap is logisch tijdens migratie, maar de roadmap moet p=reject als einddoel hebben binnen 6 weken.

3. DKIM-selectoren staan jaren onaangeroerd

De norm zelf eist geen jaarlijkse DKIM-rotatie, maar best-practice is rotatie elke 6-12 maanden. We zien geregeld selectoren die 3+ jaar oud zijn, soms nog met 1024-bit RSA-keys. Naast het beveiligingsrisico is dit een rode vlag voor auditors.

4. MTA-STS staat los van de hoofd-checklist

MTA-STS staat niet op de Logius-lijst, omdat DANE (de Logius-keuze) sterker is. Maar in de praktijk hebben veel ontvangende systemen wel MTA-STS-support en geen DANE-support — Microsoft 365 inkomend is hier het belangrijkste voorbeeld. Onze aanbeveling: implementeer beide. DANE voor de norm, MTA-STS voor de praktijk.

De rol van NTA 7516 voor zorginstellingen

Zorginstellingen die onder NTA 7516 vallen (verzending van persoonlijke gezondheidsinformatie) hebben naast de Logius-stack ook eisen rond identiteitsverificatie van de afzender en verplichte TLS — eisen die deels overlappen met DMARC/DKIM/STARTTLS, maar verder gaan in de zin dat een ontvanger ook moet kunnen verifiëren dat de afzender daadwerkelijk geautoriseerd is om die specifieke patiëntdata te versturen.

SenderProof dekt de e-mailauthenticatie-laag; de NTA-specifieke applicatie-headers (zoals X-NTA-7516 en de gateway-handshake met ZorgMail) blijven het domein van je mailgateway-leverancier. Voor de e-maillaag onder die gateway zorgen wij dat het basis-werk correct staat — anders bouwt NTA op zand.

Wat een evidence-pack typisch bevat

Wanneer een gemeenten haar accountant of Logius-auditor moet aantonen dat ze compliant is, exporteren we vanuit SenderProof een PDF met:

• Per beschermd domein de huidige DMARC-, SPF- en DKIM-records, met timestamp en bron-DNS-resolver.
• De historische tijdlijn van die records over de afgelopen 12 maanden — auditors willen zien dat het niet pas vorige week is rechtgezet.
• Geaggregeerde DMARC-rapporten met pass/fail-percentages per source-IP, gegroepeerd per maand.
• Alle Brand Watch-detecties met hun triage-status (false positive / confirmed / ignored).
• De configuratiehistorie: wie wijzigde wat en wanneer.

De NIS2-toezichthouder vraagt niet meer "is je DMARC op p=reject?" maar "kan je aantonen dat je het sinds [datum] is, en dat je tussentijdse regressies binnen 24 uur hebt gedetecteerd en hersteld?" Het tweede is alleen aantoonbaar met geautomatiseerde monitoring.

Praktische start voor een MSP met overheidsklanten

Begin niet met de tien gemeenten die het meest belangrijk zijn — begin met één gemeente waar je een goede relatie hebt, doorloop de volledige migratie naar p=reject, en gebruik die als referentie-case. Onze ervaring: 6-8 weken voor de eerste, daarna 2-3 weken per volgende.

Wil je sparren over een specifieke compliance-vraag of een aanbestedingseis? Mail ons — we kennen de NL-overheidsmarkt en hebben de checklist klaarliggen.