Gebruik van standaarden voor e-mailbeveiliging in Nederland (september 2025): slechts 14% DANE, 6% MTA-STS

Samenvatting

• Slechts 14% van de onderzochte domeinen ondersteunt DANE en slechts 6% MTA-STS. Dat betekent dat ruim 80% van de domeinen nog niet voldoet aan de basisnorm voor veilige e-mailtransport.
• Eén op de drie domeinen (32,5%) heeft helemaal geen enkele standaard geconfigureerd. Hierdoor worden e-mails nog steeds vaak onversleuteld of via kwetsbare STARTTLS-verbindingen afgeleverd.
• Gewogen naar e-mailvolume scoren de grote organisaties beter: 25% van alle e-mails loopt via DANE en 19,1% via MTA-STS (vooral door @gmail.com en @hotmail.com berichten). Toch gaat nog altijd 13,6% van alle mailverkeer naar domeinen zonder enige beveiliging.
• De trend tussen juli en september 2025 is fragiel: 47 domeinen verbeterden naar DANE, maar 33 domeinen vielen terug naar ‘geen standaard’. Daarmee is er vooruitgang, maar ontbreekt structurele borging.

Conclusie: zonder gebruik van een verzendende mailserver met multistandaard-ondersteuning (DANE, MTA-STS en DNSSEC + certificaatvalidatie) en een veilige fallback blijft e-mailverkeer in Nederland zowel kwetsbaar als non-compliant met NIS2, BIO, NTA 7516 en NEN 7510.

1. Inleiding

E-mail is in 2025 nog altijd het meest gebruikte communicatiemiddel in Nederland. Zorginstellingen wisselen patiëntgegevens uit, gemeenten communiceren met burgers en bedrijven versturen contracten, facturen en vertrouwelijke informatie. Juist die alomtegenwoordigheid maakt e-mail kwetsbaar.

Het onderliggende protocol, SMTP, stamt uit 1982 en kent van oorsprong geen enkele beveiliging. Zonder aanvullende maatregelen kan e-mail onderweg eenvoudig worden afgeluisterd, gemanipuleerd of onderschept. Dit is niet alleen een theoretisch risico: in de praktijk leidt het tot datalekken, juridische problemen en reputatieschade.

Daarom is sterke transportbeveiliging (TLS met afdwingbare standaarden) de absolute ondergrens. Zonder betrouwbare versleuteling tussen verzender en ontvanger stort de hele piramide van veilig mailen in. Zelfs een vertrouwelijke of aangetekende mail is waardeloos wanneer de onderliggende verbinding kan worden teruggezet naar onveilig SMTP.

In deze blog brengen we de staat van transportbeveiligingsstandaarden in Nederland in kaart. Op basis van een analyse van de 10.000 meest gemailde domeinen door Zivver-klanten geven we een realistisch beeld van hoe goed organisaties voorbereid zijn op veilig mailen. Daarbij kijken we niet alleen naar de huidige stand van zaken, maar ook naar de trend in adoptie, en leggen we de cijfers naast de verplichtingen uit NIS2, BIO, NTA 7516 en NEN 7510.

Lees ook: De werking en toepassing van standaarden voor beveiligd mailen

2. Drie niveaus van veilig mailen

Het is belangrijk onderscheid te maken tussen verschillende niveaus van veilig mailen:

1. Beveiligde mail (sterke transportbeveiliging): TLS-versleuteling van de verbinding tussen verzendende en ontvangende mailservers met zekerheid over de ontvangende mailserver voorkomt meelezen onderweg.
2. Vertrouwelijke mail: Extra authenticatie voor de ontvanger (bijv. sms-code); beschermt tegen ongeautoriseerde toegang door het meelezen van mail door leveranciers, hackers, beheerders en andere mensen met (onbevoegde) toegang tot mailboxen.
3. Aangetekende mail: Juridisch geldig bewijs van aflevering en inhoud.

Deze blog richt zich op niveau 1: transportbeveiliging. Want als dit fundament ontbreekt, stort de hele piramide in.

3. Transportbeveiliging: afhankelijk van twee kanten

Transportbeveiliging bij e-mail lijkt op een handshake: het werkt alleen als beide handen elkaar stevig vastpakken. Als één partij loslaat, is de beveiliging weg. Dat maakt e-mail anders dan veel andere beveiligingstechnieken: het succes hangt af van zowel verzender als ontvanger.

Aan de verzendende kant kan een organisatie instellen dat e-mail alleen via TLS wordt afgeleverd en proberen standaarden zoals DANE of MTA-STS af te dwingen. Maar als de ontvangende server deze standaarden niet ondersteunt, wordt de verbinding automatisch teruggezet naar een zwakker protocol zoals STARTTLS of zelfs naar plain SMTP zonder enige versleuteling.

Aan de ontvangende kant kan een organisatie netjes een DANE-record publiceren of een MTA-STS-policy instellen. Maar als de verzendende mailserver deze standaarden niet begrijpt of niet ondersteunt, blijft de mail alsnog kwetsbaar voor downgrade- of man-in-the-middle-aanvallen.

In de praktijk betekent dit dat een veilige route alleen tot stand komt wanneer zowel de verzender als de ontvanger een ondersteunde standaard aanbieden én de verzender kan kiezen en afdwingen.

Dit tweezijdige karakter zorgt voor een “zwakste schakel”-probleem: de beveiliging is altijd zo sterk als de minst geavanceerde partij in de keten. Juist omdat e-mailketens vaak lang zijn – denk aan ziekenhuizen die mailen met kleine leveranciers, of gemeenten die communiceren met burgers – is de kans groot dat ergens in de keten de zwakste schakel de verbinding openbreekt.

Daarom is brede adoptie van alle drie de standaarden (DANE, MTA-STS, DNSSEC) essentieel, én moet de verzendende kant een veilige fallback kunnen toepassen. Alleen dan kunnen organisaties garanderen dat berichten onderweg niet onbeschermd worden afgeleverd.

4. De drie standaarden in detail

Transportbeveiliging met TLS klinkt eenvoudig: “versleutel de verbinding en klaar.” In werkelijkheid is het complexer, omdat TLS zonder extra borging kwetsbaar blijft voor aanvallen en verkeerde configuraties. Daarom zijn er drie standaarden ontwikkeld die TLS afdwingbaar en betrouwbaar maken.

4.1 DANE (DNS-Based Authentication of Named Entities)

DANE koppelt het TLS-certificaat van een mailserver cryptografisch aan het domein via DNSSEC. Hierdoor kan een verzendende mailserver controleren of het aangeboden certificaat ook écht bij de ontvangende server hoort.

Voordelen:

• Hoogste niveau van zekerheid: voorkomt man-in-the-middle-aanvallen.
• Door Forum Standaardisatie aangewezen als enige verplichte standaard voor de overheid.
• Vastgelegd in de BIO (Baseline Informatiebeveiliging Overheid).

Beperkingen:

• Vereist correcte DNSSEC-implementatie; foutgevoelig bij beheer.

Conclusie: DANE is de meest robuuste standaard en moet in Nederland als basis worden gezien.

4.2 MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS laat domeineigenaren via een HTTPS-policy publiceren dat hun mailservers alleen via TLS bereikbaar zijn. Verzenders die MTA-STS ondersteunen, weigeren verbindingen zonder TLS.

Voordelen:

• Breed geadopteerd door internationale partijen, o.a. Google.
• Maakt downgrade-aanvallen lastiger.
• Minder complex te beheren dan DANE.

Beperkingen:

• Afhankelijk van HTTPS en certificaatbeheer.
• Minder robuust dan DANE (geen cryptografische koppeling in DNS).

Conclusie: MTA-STS is een waardevolle aanvulling voor interoperabiliteit, vooral in internationale communicatie.

4.3 DNSSEC + certificaatvalidatie (NTA 7516, bijlage C)

Naast DANE en MTA-STS beschrijft de NTA 7516 een alternatief waarbij certificaten via DNSSEC gevalideerd worden. Dit biedt extra zekerheid in ketens waar DANE (nog) niet is ingevoerd.

Voordelen:

• Beschermt tegen eenvoudige downgrade-aanvallen.
• Past binnen de zorgcontext (NTA 7516 bijlage C).

Beperkingen:

• Minder sterk dan DANE of MTA-STS.
• Vereist DNSSEC, wat niet overal consistent wordt toegepast.

Conclusie: nuttige aanvulling, maar geen volwaardig alternatief.

Belangrijk om te beseffen: drie losse standaarden

DANE, MTA-STS en DNSSEC-certificaatvalidatie zijn niet uitwisselbaar, maar complementair. Een verzender die alleen DANE ondersteunt, kan nog steeds onveilig afleveren bij een ontvanger die uitsluitend MTA-STS heeft. Voor maximale dekking moet een verzendende mailserver daarom alle drie de standaarden ondersteunen en actief afdwingen.

Waarom “gewoon TLS” (STARTTLS) niet genoeg is

Veel organisaties vertrouwen nog op opportunistische TLS via STARTTLS. Dat lijkt veilig (“de verbinding is immers versleuteld”), maar de praktijk is anders:

• Downgrade-aanvallen: STARTTLS kan door een aanvaller eenvoudig worden uitgeschakeld.
• Fallback naar onveilig SMTP: zonder afdwingbare standaarden kan een mailserver alsnog terugvallen op onversleutelde verzending.
• Geen certificaatcontrole: vaak wordt het certificaat niet gevalideerd, waardoor een man-in-the-middle onopgemerkt kan meekijken.

Daarom geldt: alleen met DANE, MTA-STS of DNSSEC-validatie wordt transportbeveiliging écht betrouwbaar.

Meer achtergrond hierover lees je in mijn eerdere blog: De werking en toepassing van standaarden voor beveiligd mailen.

5. Onderzoeksmethode

Voor dit onderzoek is een representatieve scan uitgevoerd van de 10.000 domeinen waar Zivver-klanten het meest naartoe mailen. Dit zijn niet willekeurige adressen, maar domeinen van zorginstellingen, gemeenten, ministeries, banken, onderwijsinstellingen en bedrijven – precies de partijen die samen een groot deel van het Nederlandse e-mailverkeer vertegenwoordigen.

We hebben per domein gecontroleerd of de volgende standaarden actief waren: DANE, MTA-STS en DNSSEC + certificaatvalidatie. Daarbij is onderscheid gemaakt tussen:

• Per domein: hoe vaak een standaard voorkomt.
• Gewogen naar volume: hoeveel verkeer daadwerkelijk via die standaarden wordt afgeleverd.

De scan is uitgevoerd op 1 juli en 1 september 2025, zodat we niet alleen een momentopname hebben, maar ook zicht op veranderingen. Zo werd duidelijk welke domeinen zijn opgewaardeerd naar DANE of MTA-STS, en welke juist zijn teruggevallen.

Beperkingen: alleen domeinen waarnaar echt gemaild is zijn meegenomen, en de resultaten zeggen iets over de ontvangende kant, niet over uitgaande mailservers.

6. Resultaten (1 september 2025)

Voor dit onderzoek hebben we de 10.000 domeinen geanalyseerd waar Zivver-klanten het meest naartoe mailen. Het gaat dus niet om een willekeurige steekproef, maar om de domeinen die in de praktijk een groot deel van het Nederlandse e-mailverkeer afhandelen: van ziekenhuizen en gemeenten tot ministeries, banken en toeleveranciers. Daarmee ontstaat een realistisch beeld van hoe goed Nederland er werkelijk voorstaat op het gebied van transportbeveiliging.

6.1 Per domein: veel DNSSEC, weinig DANE, nog minder MTA-STS

Wanneer we puur kijken naar het aantal domeinen, ontstaat het volgende beeld:

Wat opvalt: bijna de helft van de domeinen heeft DNSSEC geactiveerd, maar slechts een klein deel gaat een stap verder naar DANE of MTA-STS. Slechts 14% van de domeinen ondersteunt DANE, de standaard die in Nederland verplicht is voor overheden. Nog zorgwekkender: één op de drie domeinen (32,5%) heeft helemaal geen enkele standaard actief en valt dus terug op STARTTLS zonder afdwinging of zelfs onversleutelde verbindingen.

6.2 Gewogen naar e-mailvolume

Omdat niet elk domein even zwaar meeweegt in de dagelijkse mailstroom, hebben we ook gekeken naar het e-mailvolume. Grote partijen zoals banken, ministeries en zorginstellingen genereren immers veel meer verkeer dan kleine leveranciers of lokale bedrijven, alsook populaire domeinen zoals @gmail.com en @hotmail.com die alleen MTA-STS ondersteunen.

Hieruit blijkt dat DANE in volume veel belangrijker is dan per domein: een kwart van alle e-mails kan ermee beveiligd worden. Ook MTA-STS wordt door grote partijen vaker toegepast, vooral door weging van berichten naar @gmail.com en @hotmail.com, waardoor het aandeel stijgt naar 19,1%. Toch blijft ook hier een harde conclusie overeind: 14% van alle mails gaat nog steeds naar domeinen zonder een goede beveiligingsstandaard.

6.3 Ontwikkeling juli – september 2025

Door de cijfers van 1 juli 2025 te vergelijken met die van 1 september 2025, zien we hoe domeinen zich ontwikkelen.

Het goede nieuws: 47 domeinen maakten de stap van DNSSEC naar DANE, en meer dan 50 domeinen gingen van “geen standaard” naar ten minste DNSSEC. Er is dus een positieve beweging.

Het slechte nieuws: er is ook terugval. 33 domeinen die in juli nog DNSSEC hadden, verloren die configuratie in september. Tien domeinen zakten zelfs terug van DANE naar enkel DNSSEC. Dat laat zien dat implementatie vaak niet structureel geborgd is. Een verlopen certificaat of foutieve DNS-wijziging kan er zomaar toe leiden dat een domein ineens niet langer veilig bereikbaar is.

6.4 Samenvatting: een fragiele vooruitgang

De resultaten laten een gemengd beeld zien:

• Grote organisaties lopen voorop: in volume is een kwart van de e-mails afgedekt met DANE en nog eens bijna 20% met MTA-STS.
• De lange staart blijft kwetsbaar: één op de drie domeinen heeft helemaal niets geregeld.
• Implementatie is broos: tientallen domeinen vielen binnen twee maanden terug van een goede standaard naar geen goede standaard.

Conclusie: Nederland zet kleine stapjes vooruit, maar het fundament is fragiel. Zolang een derde van de domeinen niets heeft ingericht, blijft een groot deel van het e-mailverkeer afhankelijk van verzendende systemen die slim genoeg zijn om per e-mail te bepalen welke standaard mogelijk is, en die een veilige fallback bieden wanneer er geen enkele standaard actief is.

7. Juridisch en normatief kader

De cijfers laten zien dat de adoptie van transportbeveiligingsstandaarden in Nederland achterblijft. Dat is niet alleen een technisch probleem, maar ook een kwestie van compliance: verschillende wettelijke en normatieve kaders verplichten organisaties om transportbeveiliging aantoonbaar goed in te richten.

• BIO (overheden): De Baseline Informatiebeveiliging Overheid schrijft voor dat overheden de standaarden van het Forum Standaardisatie moeten volgen. Voor e-mail betekent dit concreet: DANE is verplicht. Het feit dat slechts 14% van de domeinen DANE ondersteunt, toont aan dat een groot deel van de overheden niet compliant is met hun eigen normenkader.
• NEN 7510 (zorg): Deze norm verplicht zorginstellingen om communicatie met persoonsgegevens te versleutelen, zowel in opslag als transport. Transportbeveiliging via afdwingbare standaarden is hier een basismaatregel. Instellingen die nog vertrouwen op STARTTLS voldoen niet.
• NTA 7516 (veilig mailen in de zorg): Deze richtlijn specificeert hoe e-mail met gevoelige gegevens veilig moet verlopen. Bijlage C schrijft expliciet voor dat transportbeveiliging moet worden afgedwongen via DANE of – als alternatief – DNSSEC met certificaatvalidatie.
• NIS2 (vitale sectoren): De Europese richtlijn verplicht vitale en essentiële sectoren (o.a. gemeenten, ziekenhuizen, energiebedrijven, banken) tot het nemen van basismaatregelen. Transportbeveiliging is hier een kernonderdeel. Belangrijk: onder NIS2 geldt ook aantoonbaarheid – organisaties moeten kunnen bewijzen dat transportbeveiliging structureel en blijvend is ingericht.

Kortom: organisaties die DANE, MTA-STS en DNSSEC niet hebben geïmplementeerd, lopen niet alleen technische risico’s, maar overtreden ook wettelijke verplichtingen en riskeren boetes en reputatieschade.

8. Het belang van een verzendende e-mailserver met fallback

Zelfs als jouw organisatie alles perfect op orde heeft—DANE geïmplementeerd, DNSSEC actief, certificaten netjes ingericht—kan een e-mail nog steeds onveilig worden afgeleverd. De reden is simpel: je hebt geen invloed op de ontvangende kant. Als de ontvanger geen enkele standaard ondersteunt, val je alsnog terug op onbeveiligd transport.

Daarom is de rol van de verzendende e-mailserver cruciaal. Die moet namelijk niet alleen controleren of de ontvanger bepaalde standaarden ondersteunt, maar ook automatisch de juiste keuze maken. Een moderne verzendende mailserver hoort het volgende te doen:

• Alle drie de standaarden ondersteunen: DANE, MTA-STS en certificaatvalidatie met DNSSEC.
• Realtime detecteren welke standaard de ontvanger beschikbaar stelt.
• Altijd de sterkste route kiezen: eerst DANE, zo mogelijk MTA-STS, en pas daarna certificaatvalidatie met DNSSEC.
• Veilig uitwijken naar een alternatief (bijvoorbeeld een beveiligd berichtenportaal of vertrouwelijke mail) als er helemaal geen standaard beschikbaar is.

Dit laatste noemen we de fallback. Zonder een betrouwbare fallback loop je het risico dat gevoelige informatie alsnog in onversleuteld over het internet wordt verstuurd. Dat is niet alleen technisch onveilig, maar ook strijdig met normen zoals de BIO, NTA 7516 en NIS2.

Kortom: transportbeveiliging moet niet alleen aan de ontvangende kant goed geregeld zijn, maar ook aan de verzendende kant. Alleen dan is er de garantie dat gevoelige informatie altijd veilig én compliant wordt afgeleverd, ook als de ontvanger nog achterloopt in de adoptie van standaarden.

9. Aanbevelingen

De cijfers zijn confronterend: te weinig domeinen ondersteunen DANE, MTA-STS is nog marginaal aanwezig en één op de drie domeinen heeft helemaal niets geregeld. Dat vraagt om actie. Hieronder de belangrijkste aanbevelingen voor organisaties die hun e-mailverkeer veilig en compliant willen maken:

• Implementeer DANE zonder uitstel: DANE is niet alleen technisch de meest robuuste standaard, maar ook juridisch verplicht voor overheden via de BIO en aanbevolen door het Forum Standaardisatie. Voor elke organisatie die persoonsgegevens verwerkt of onderdeel is van een vitale sector, zou DANE de eerste prioriteit moeten zijn.
• Vul DANE aan met MTA-STS en DNSSEC: Omdat niet iedere ontvanger DANE ondersteunt, is het essentieel om ook MTA-STS en DNSSEC in te richten. Daarmee vergroot je de kans dat er altijd een veilige route beschikbaar is, ook richting internationale partijen zoals Google.
• Kies voor een verzendsysteem met verschillende afleveropties en fallback: Geen enkele standaard heeft 100% adoptie. Daarom moet de verzendende e-mailserver zo veel mogelijk standaarden kunnen ondersteunen en afdwingen en automatisch kunnen uitwijken naar een veilige fallback, zoals een vertrouwelijk berichtenportaal. Zonder fallback blijft er altijd een kans bestaan dat gevoelige informatie alsnog onversleuteld wordt verstuurd.
• Monitor de ketenpartners actief: Transportbeveiliging is tweezijdig. Het is dus niet genoeg om je eigen omgeving goed in te richten: je moet weten welke standaarden jouw partners, leveranciers en ketenorganisaties ondersteunen. Monitoring geeft inzicht, helpt risico’s te managen en maakt het makkelijker om partners aan te spreken op hun verantwoordelijkheden.
• Borg en rapporteer structureel: Het inrichten van standaarden is geen eenmalig project, maar een doorlopend proces. Certificaten verlopen, DNS-records worden aangepast en standaarden ontwikkelen door. Richt daarom procedures in om dit structureel te controleren, en rapporteer daarover in je compliance- en risicomanagementprocessen.