De werking en toepassing van standaarden voor ‘beveiligd mailen’

E-mail is nog altijd het meest gebruikte digitale communicatiekanaal van organisaties, maar is van oorsprong nooit ontworpen als veilig medium. De risico’s van onbeveiligde e-mail zijn groot: onderschepping, menselijke fouten, ongeautoriseerde toegang en phishing vormen samen de belangrijkste oorzaken van datalekken en incidenten. Daarom verplicht wet- en regelgeving zoals de BIO2, NEN 7510 en ISO 27001 organisaties om e-mailverkeer structureel en aantoonbaar te beveiligen.

Beveiligd mailen – het zorgen dat e-mail onderweg altijd versleuteld én bij de juiste server wordt afgeleverd – vormt de minimale basismaatregel. Dit wordt gerealiseerd via standaarden als SPF, DKIM, DMARC, STARTTLS, DANE, MTA-STS en DNSSEC. De ontvanger moet zijn infrastructuur zó inrichten dat anderen veilig kunnen mailen (denk aan DNSSEC, DANE en MTA-STS). De verzender is wettelijk verantwoordelijk voor veilige aflevering: bij elk bericht moet worden gecontroleerd of het ontvangende domein deze standaarden ondersteunt. Ontbreekt veilige afleverroute, dan mag het bericht niet worden verstuurd of moet het bericht via een beveiligd portaal worden aangeboden.

Het artikel maakt duidelijk:

• Alleen het combineren en goed toepassen van moderne e-mailstandaarden biedt échte bescherming tegen afluisteren en misbruik.
• Veel organisaties zijn (nog) niet compliant doordat standaarden niet of onvolledig zijn geïmplementeerd aan de ontvangende en/of verzendende kant.
• De verantwoordelijkheid voor veilige aflevering ligt primair bij de verzender, maar de (mailserver van de) ontvanger moet wel de juiste veilige e-mailstandaarden ondersteunen.
• Is veilige aflevering via standaarden niet mogelijk, dan is een beveiligd portaal de enige praktische en wettelijk acceptabele oplossing.
• Organisaties die deze aanpak volgen, voldoen aantoonbaar aan de eisen uit de BIO2, NEN 7510 en ISO 27001 en minimaliseren hun juridische risico’s en reputatieschade.

Conclusie:

Echt veilig mailen vereist voortdurende aandacht, technische investeringen en heldere processen. Alleen door als verzender én ontvanger je verantwoordelijkheid te nemen en maximaal in te zetten op de geldende standaarden, voorkom je datalekken, incidenten en non-compliance. Wie geen gebruik maakt van structureel beveiligd mailen, loopt onnodig risico en voldoet niet aan de actuele wettelijke eisen.

E-mailbeveiliging: Meer dan alleen technologie, een wettelijke plicht

E-mail is het meest gebruikte digitale communicatiekanaal van organisaties, maar e-mail is nooit als veilig kanaal ontworpen. E-mail is ouder dan het internet en het lijkt qua beveiliging nog altijd op een digitale ansichtkaart: iedereen die het onderweg onderschept, kan alles lezen. In de loop der jaren zijn daarom diverse standaarden toegevoegd om e-mail beter te beveiligen. Deze standaarden zijn onmisbaar om risico’s rond vertrouwelijkheid en integriteit te beheersen, mits ze correct worden toegepast.

Voor organisaties die onder wet- en regelgeving als ISO 27001, BIO2 (Baseline Informatiebeveiliging Overheid) en NEN 7510 (zorgsector) vallen, is het correct toepassen van deze e-mailstandaarden niet vrijblijvend, maar verplicht. Desondanks is de kennis over en implementatie van deze standaarden vaak gebrekkig. Hierdoor ontstaan onnodige risico’s en voldoet een groot deel van de organisaties niet aan wet- en regelgeving.

In dit artikel wordt beschreven:

• Welke risico’s e-mailgebruik precies met zich meebrengt.
• Wat de BIO2 (2025) en NEN 7510:2024 exact eisen op het gebied van e-mailbeveiliging, inclusief letterlijke quotes.
• Welke e-mailstandaarden verplicht zijn (SPF, DKIM, DMARC, STARTTLS, DANE) en waarom.
• Hoe DANE, MTA-STS en DNSSEC technisch werken.
• Waarom deze standaarden essentieel zijn voor zowel inkomende als uitgaande e-mail.
• Het verschil tussen beveiligd, vertrouwelijk en aangetekend mailen.
• Hoe je als organisatie praktisch voldoet aan de wettelijke basiseisen.

Risico’s van e-mailgebruik: de vier grootste problemen

Voor vrijwel elke organisatie geldt de, vaak wettelijke, verplichting tot informatiebeveiliging volgens ISO 27001, BIO2 of NEN 7510. Deze normen vereisen dat organisaties eerst een risicoanalyse uitvoeren om op basis daarvan passende beheersmaatregelen te nemen. E-mail is het meest gebruikte communicatiekanaal binnen organisaties, en via e-mail wordt ook de meeste gevoelige informatie gedeeld. Daarom is een risico-analyse op e-mail uitvoeren een van de zaken die organisaties als eerste (zouden) moeten doen.

Een goede risicoanalyse laat zien dat e-mail de grootste bron van risico’s vormt binnen vrijwel iedere organisatie. Uit elk (goed uitgevoerd) onderzoek komen deze vier hoofdrisico’s naar voren:

• Menselijke fouten: Zoals e-mails aan de verkeerde ontvanger, verkeerde bijlagen of vergeten beveiliging aan te zetten. Dit blijft veruit de belangrijkste oorzaak van datalekken.
• Onderschepping tijdens transport: E-mails die niet worden beveiligd met de juiste standaarden worden onveilig of zelfs onversleuteld verstuurd. Daardoor kan, zonder aanvullende maatregelen, gevoelige informatie onderweg eenvoudig worden onderschept.
• Ongeautoriseerde toegang tot mailboxen: Bijvoorbeeld via gestolen wachtwoorden, ontbreken van tweefactorauthenticatie of toegang door e-mailproviders/beheerders.
• Phishing, malware en ransomware: E-mail is nog altijd het favoriete startpunt voor cybercriminelen en digitale aanvallen.

Wat eisen de BIO2 en NEN 7510 nu écht voor e-mail?

De BIO2, die vanaf april 2025 geldt voor de gehele overheid en bij veel semipublieke organisaties, is ondubbelzinnig. In hoofdstuk 5.14 (“Overdragen van informatie”) staat:

“E-mail-berichtenverkeer moet blijvend voldoen aan de verplichte standaarden, zie hiervoor de website van het Forum Standaardisatie. Daarbij dienen alle onderdelen te worden ingesteld zodat een optimale beveiliging wordt bereikt zonder afbreuk te doen aan de functionaliteit van de geboden dienst.”

De kern van de BIO is daarmee dat voldoen aan standaarden is verplicht en daarbij moeten overheidsorganisaties de genoemde standaarden niet alleen toepassen, maar ze ook afdwingen.

De NEN 7510 verplicht zorgorganisaties om beheersmaatregelen te nemen tegen o.a. onderschepping, ongeautoriseerde toegang, wijziging, kopiëren en foutieve routering van gevoelige informatie. Letterlijk:

“Er behoort beleid te zijn ingesteld dat waarborgt dat persoonlijke gezondheidsinformatie en andere vertrouwelijke informatie die wordt uitgewisseld via e-mail, instant messaging of in een andere vorm beveiligd is of, indien voldoende beveiliging niet mogelijk is, helemaal niet via deze kanalen wordt uitgewisseld.”

De NEN 7510 noemt geen specifieke technieken, maar maakt helder dat gevoelige informatie alleen via goed beveiligde kanalen mag worden gedeeld. In de praktijk betekent dit: gebruik de standaarden van het Forum Standaardisatie, of wissel gevoelige info niet via e-mail uit.

Welke e-mailstandaarden zijn verplicht en waarom?

Het Forum Standaardisatie heeft vier e-mailstandaarden als verplicht aangemerkt:

• SPF (Sender Policy Framework): Controleert of een verzendende mailserver gemachtigd is voor het domein.
• DKIM (DomainKeys Identified Mail): Plaatst een digitale handtekening onder uitgaande e-mails. Ontvangers kunnen zo controleren of de e-mail onderweg is aangepast.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Bepaalt wat te doen met e-mails die niet slagen voor SPF/DKIM (bijv. blokkeren), en biedt rapportages.
• STARTTLS & DANE: STARTTLS zorgt voor versleuteling van e-mail tussen mailservers. DANE waarborgt de authenticiteit van die verbindingen. Oftewel het zorgt dat de informatie ook daadwerkelijk aankomt bij de juiste server van de ontvanger en niet bij een derde die zich voordoet als de server van de ontvanger.

SPF, DKIM en DMARC richten zich op afzenderauthenticatie, integriteit en reputatie, essentieel voor bescherming tegen het risico ‘Phishing, malware en ransomware’.

STARTTLS en DANE zijn onmisbaar voor vertrouwelijkheid en integriteit tijdens e-mailtransport en dient tussen als bescherming tegen het risico ‘Onderschepping tijdens transport’.

In dit artikel richten wij ons op het risico ‘Onderschepping tijdens transport’ door middel van, wat vaak wordt aangeduid als, ‘beveiligd mailen’, wat de rol van DANE en STARTTLS daarin is en wat de werking is, alternatieven zijn etc.

Beveiligd mailen, vertrouwelijk mailen en aangetekend mailen: wat is het verschil?

Beveiligd mailen – e-mails versleuteld versturen met zekerheid over de ontvangende server

Dit artikel gaat over beveiligd mailen: het transporteren van e-mailberichten via een gegarandeerd versleutelde en geauthenticeerde verbinding van verzender naar mailserver van de ontvanger. Met andere woorden: je garandeert dat de mail onderweg niet leesbaar is én dat het daadwerkelijk bij de juiste mailserver wordt bezorgd. Dit is de basisbeveiliging zoals verplicht door de BIO2, NEN 7510 en ISO 27001.

Vertrouwelijk mailen – e-mails versleuteld versturen met zekerheid over de ontvangende persoon

Vertrouwelijk mailen gaat een stap verder dan beveiligd mailen. Terwijl beveiligd mailen zich richt op veilig en authentiek transport van server naar server, zorgt vertrouwelijk mailen er nadrukkelijk voor dat uitsluitend de bedoelde ontvanger toegang krijgt tot het bericht. Oftewel je wil voorkomen dat ‘derden die meelezen’, zoals een hacker die het wachtwoord heeft achterhaald, een gezinslid met toegang tot de mailbox, een beheerder van de mailserver of een commerciële e-mailprovider die mogelijk toegang heeft tot mailboxen de vertrouwelijk informatie zomaar kan lezen. Vertrouwelijk mailen garandeert, door middel van aanvullende authenticatie (bijvoorbeeld via een SMS-code), dat alleen de ontvanger zelf de inhoud kan lezen. Vertrouwelijk mailen is daarom noodzakelijk bij gevoelige berichten waarbij absolute zekerheid over de ontvanger cruciaal is, zoals medische gegevens, juridische documenten of financiële informatie.

Voorbeeld:

Een arts wil medische gegevens naar een patiënt sturen. Omdat de patiënt gebruik maakt van een publiek e-mailadres (bijvoorbeeld @gmail.com), waarvan niet gegarandeerd kan worden wie er toegang toe heeft, kiest de arts voor vertrouwelijk mailen via een beveiligd berichtenportaal met aanvullende authenticatie via SMS. De patiënt ontvangt eerst een notificatie-e-mail met een beveiligde link naar het berichtenportaal. Vervolgens ontvangt de patiënt een unieke SMS-code op zijn mobiele telefoon, die hij moet invoeren als extra authenticatiestap. Pas na het invoeren van de SMS-code kan de patiënt het bericht veilig openen, lezen, beantwoorden, downloaden of doorsturen. Zo is de vertrouwelijkheid van de medische informatie volledig gewaarborgd.

Aangetekend mailen – e-mails versleuteld versturen met juridisch bewijs

Aangetekend mailen gaat nog een stap verder dan vertrouwelijk mailen. Naast het garanderen dat alleen de bedoelde ontvanger toegang heeft tot het bericht, biedt aangetekend mailen de verzender bovendien juridisch bewijs omtrent het exacte moment van verzending, het moment waarop het bericht is ontvangen, en – afhankelijk van de gebruikte oplossing – ook bewijs van het openen en lezen door de ontvanger. Aangetekend mailen is vergelijkbaar met aangetekende post, en wordt vooral ingezet bij communicatie waarbij juridische zekerheid en aantoonbaarheid cruciaal zijn, zoals bij officiële beschikkingen, juridische correspondentie, contracten en financiële transacties.

Voorbeeld:

Een advocaat wil een belangrijke juridische brief naar een cliënt sturen. Omdat het essentieel is om achteraf juridisch aan te kunnen tonen dat het bericht op een bepaald moment verzonden, ontvangen en daadwerkelijk gelezen is, kiest de advocaat voor het versturen van een mail met de mogelijkheid tot het inzien van een juridisch afleverbewijs. De cliënt ontvangt een notificatie via e-mail, authenticeert zichzelf via een extra beveiligingsstap, en opent vervolgens het bericht in een beveiligd portaal. De advocaat vraagt vervolgens een week later een digitaal bewijs op waarin nauwkeurig is vastgelegd wanneer het bericht werd verzonden, wanneer het werd geopend door de ontvanger, en wanneer eventuele bijlagen zijn gedownload. Dit bewijs kan in geval van geschillen dienen als onweerlegbaar juridisch document.

Dit artikel: focus op beveiligd mailen als verplichte basis

Dit artikel behandelt beveiligd mailen als de minimale basismaatregel, een die minimaal verplicht is voor organisaties die aan de BIO2 en NEN7510 moeten voldoen, maar eigenlijk voor elke organisatie die informatiebeveiliging serieus neemt. Vertrouwelijk en aangetekend mailen zijn relevant voor specifieke toepassingen met nog hogere eisen aan privacy, authenticatie en juridische bewijsvoering.

Diepgaand: Hoe e-mail, STARTTLS, DANE, MTA-STS en DNSSEC werken

Hoe werkt e-mail onder de motorkap?

Voordat we ingaan op beveiligingsstandaarden, is het belangrijk kort uit te leggen hoe het verzenden van e-mail eigenlijk werkt. Dit geeft direct context bij het nut van alle e-mailbeveiligingsstandaarden.

E-mail verzenden: hoe werkt het SMTP-proces onder de motorkap?

Wanneer je op "verzenden" drukt in je mailprogramma (zoals Outlook, Gmail of Apple Mail), lijkt het alsof je bericht direct bij de ontvanger terechtkomt. In werkelijkheid doorloopt je e-mail een aantal onzichtbare stappen, waarbij verschillende servers en internetstandaarden samenwerken om het bericht af te leveren. Hieronder zie je stap voor stap hoe het verzenden van e-mail in de praktijk werkt:

1. Je mailprogramma verstuurt het bericht naar je eigen mailserver (SMTP-server): Je mailclient (zoals Outlook of Gmail in de browser) maakt verbinding met de mailserver van jouw organisatie of e-mailprovider. Deze server wordt vaak de "uitgaande mailserver" genoemd en werkt via het protocol SMTP (Simple Mail Transfer Protocol).
2. De verzendende mailserver bepaalt waar het bericht naartoe moet: De mailserver kijkt naar het e-mailadres van de ontvanger (bijvoorbeeld piet@organisatie.nl). Hij wil nu weten welke mailserver verantwoordelijk is voor het ontvangen van e-mail voor het domein ‘organisatie.nl’.
3. DNS-opvraag: het vinden van de juiste ontvangende mailserver via het MX-record: Om dit uit te zoeken, vraagt de verzendende mailserver informatie op uit het Domain Name System (DNS) — het internet-‘adresboek’. Hij zoekt daarbij specifiek naar het zogenaamde “MX-record” (Mail Exchanger record) van het domein van de ontvanger. Het MX-record vertelt precies welke server (meestal genoemd met een hostnaam, bijvoorbeeld mail.organisatie.nl) de e-mail moet ontvangen en wat het bijbehorende IP-adres is. Soms zijn er meerdere MX-records, met een prioriteit, zodat de server weet welke mailserver als eerste moet worden geprobeerd.
4. Verbinding leggen met de ontvangende mailserver: Gewapend met het adres van de juiste ontvangende mailserver, probeert de verzendende mailserver via het internet contact te leggen met deze server.
5. De SMTP-handshake en aflevering: Zodra de verbinding tot stand is gebracht, volgt een digitale "handdruk" (de handshake):

   - De servers stellen zich aan elkaar voor.

   - Ze wisselen technische informatie uit, zoals hun capabilities (wat ze ondersteunen, bijvoorbeeld versleuteling via STARTTLS).

   - Ze spreken af hoe het bericht verzonden en verwerkt wordt.

   - Dit hele proces verloopt via het SMTP-protocol, de wereldwijde standaard voor het versturen van e-mail tussen servers.

6. Bericht afleveren en bevestigen: Als alle afspraken zijn gemaakt, stuurt de verzendende mailserver het e-mailbericht daadwerkelijk naar de ontvangende server. Die bevestigt de ontvangst (tenzij er een fout optreedt). Vervolgens zorgt de ontvangende server ervoor dat het bericht in de inbox van de juiste gebruiker terechtkomt.

De rol van DNS en MX-records in e-mail

DNS is als het telefoonboek van het internet: het vertaalt domeinnamen (zoals organisatie.nl) naar technische adressen (zoals mailservers en IP-adressen).

Het MX-record is speciaal bedoeld voor e-mail en bepaalt welke mailserver(s) namens een domein e-mail mogen ontvangen. Zonder een juist ingesteld MX-record weet niemand waar de mail voor jouw domein naartoe moet.

Belangrijk: Als het MX-record niet klopt of ontbreekt, kan geen enkele mailserver ter wereld een e-mail afleveren aan dat domein.

De kwetsbaarheid van standaard e-mail

Standaard is SMTP niet beveiligd: iedereen “onderweg” tussen de verzendende en ontvangende server kan mogelijk meekijken, data aanpassen, of zich zelfs voordoen als de ontvangende server. Je vertrouwt er dus op dat je echt met de juiste server praat, maar standaard is dat technisch niet gegarandeerd.

STARTTLS is een noodzakelijke, maar kwetsbare uitbreiding voor versleuteling

STARTTLS is een uitbreiding op SMTP waarmee mailservers versleuteld kunnen communiceren via TLS. Maar: STARTTLS is ‘opportunistisch’. Alleen als beide kanten het ondersteunen en dezelfde versies hanteren, wordt TLS gebruikt. Echter, zoals het Nationaal Cyber Security Center (NCSC) ook aangeeft, kan “een actieve aanvaller kan het gebruik van STARTTLS eenvoudig ongedaan maken” via een downgrade attack, waardoor e-mails alsnog onversleuteld verzonden worden.

Enforce TLS kan versleuteling afdwingen, maar validatie van de ontvangende server ontbreekt en processen worden verstoord

Bij de meeste mailservers, waaronder Microsoft 365, Exchange en Google, kun je het gebruik van STARTTLS afdwingen (Enforce TLS). Dit betekent dat e-mail alleen wordt verstuurd als de ontvangende partij TLS ondersteunt. Wanneer de ontvangende mailserver echter geen TLS accepteert, zal het bericht niet worden verzonden. De verzender ontvangt in dat geval een retourmail, ook wel bounce of DSN (Delivery Status Notification) genoemd, met de melding dat het bericht niet kon worden afgeleverd. Zulke situaties, waarbij e-mails niet kunnen worden bezorgd, leiden tot operationele problemen. Gebruikers gaan dan vaak op zoek naar alternatieve communicatiekanalen, die in de praktijk meestal nog onveiliger zijn.

Voor organisaties die wél kiezen voor Enforce TLS ontstaat bovendien een ander, fundamenteel probleem. Hoewel TLS zorgt voor versleuteling tussen mailservers, biedt het protocol op zichzelf geen garantie dat daadwerkelijk met de juiste ontvangende mailserver wordt verbonden. Kwaadwillenden kunnen zich voordoen als de server van de ontvanger in een zogenaamde man-in-the-middle-aanval, waardoor de e-mail – hoewel versleuteld verzonden – uiteindelijk bij een server van een kwaadwillende partij, bijvoorbeeld een buitenlandse overheid of hacker, terecht kan komen zonder dat de verzender of ontvanger dit doorheeft.

DANE is de enige echt veilige en geaccepteerde standaard voor mailtransport

DANE (DNS-based Authentication of Named Entities) is de enige standaard die zowel de authenticiteit als de versleuteling van e-mailtransport volledig waarborgt. DANE maakt gebruik van een speciaal record in het Domain Name System (DNS), het zogenaamde TLSA-record, waarin wordt gepubliceerd welk TLS-certificaat bij de mailserver van een domein hoort.

De rol van DNSSEC

Om zeker te weten dat deze informatie niet onderweg kan worden aangepast door kwaadwillenden, wordt DANE altijd gecombineerd met DNSSEC (Domain Name System Security Extensions). DNSSEC is een uitbreiding op het bestaande DNS die digitale handtekeningen toevoegt aan DNS-records. Hierdoor kan de verzendende mailserver controleren of de ontvangen DNS-informatie, zoals het TLSA-record, authentiek en niet gemanipuleerd is. Zonder DNSSEC zou een aanvaller immers kunnen proberen om valse DNS-informatie door te geven en zo een man-in-the-middle-aanval uit te voeren.

Wat maakt DANE uniek en veilig?

• DANE garandeert de authenticiteit van de ontvangende mailserver: je weet zeker dat je met de echte server van het domein praat en niet met een aanvaller.
• DANE dwingt het gebruik af van het juiste, vooraf bekende TLS-certificaat en verplicht het gebruik van TLS, waardoor versleuteling gegarandeerd is.
• DANE voorkomt daarmee effectief man-in-the-middle-aanvallen en onderschepping van e-mail onderweg.

DANE is door het Forum Standaardisatie verplicht gesteld voor Nederlandse overheden en organisaties, en wordt door de Europese Commissie aanbevolen als standaard voor heel Europa. Helaas ondersteunen grote partijen zoals Google op dit moment nog steeds geen DANE voor inkomende e-mail, waardoor universele adoptie in de praktijk beperkt blijft.

MTA-STS is een alternatief waar DANE niet werkt

MTA-STS (Mail Transfer Agent Strict Transport Security) is een beveiligingsstandaard die met name door Google is omarmd als alternatief voor DANE, vooral omdat Google voor inkomende e-mail nog geen DANE ondersteunt. MTA-STS maakt het mogelijk voor organisaties om expliciet aan te geven dat hun mailservers altijd een versleutelde TLS-verbinding vereisen, en om te specificeren welke mailservers en certificaten daarvoor gebruikt moeten worden.

Hoe werkt MTA-STS?

Organisaties publiceren hiervoor een speciaal tekstbestand, het zogeheten mta-sts.txt-bestand, op een goed vindbare, vaste locatie op hun eigen website; een zogenaamde well-known domain (https://mta-sts.organisatie.com/.well-known/mta-sts.txt). Daarnaast wordt in het DNS van het domein een speciaal record toegevoegd dat aangeeft dat het domein MTA-STS ondersteunt. Verzendende mailservers kunnen dit beleid (de policy) opvragen en lezen in het mta-sts.txt-bestand. Hierin staat welke servers e-mail mogen ontvangen voor het domein en welk type beveiligde verbinding vereist is. Alleen als aan deze eisen wordt voldaan, wordt de e-mail afgeleverd.

Voordelen en beperkingen:

• MTA-STS is eenvoudiger te implementeren dan DANE, omdat het geen gebruikmaakt van DNSSEC en geen TLSA-records vereist.
• De beveiliging is echter minder sterk dan bij DANE: omdat DNSSEC ontbreekt, bestaat het risico dat een actieve aanvaller het beleid kan blokkeren, onderscheppen of manipuleren voordat de verzendende server het kan inzien.
• Toch biedt MTA-STS aanzienlijk meer bescherming dan alleen opportunistische STARTTLS, zeker richting grote providers als Gmail en Google Workspace.
• In een optimale situatie zet een organisatie zowel DANE als MTA-STS in, zodat de grootste groep verzendende mailservers altijd een veilige afleverroute kan afdwingen.

DNSSEC met certificaatvalidatie is een praktische noodoplossing als DANE en MTA-STS ontbreken

Wanneer DANE of MTA-STS niet beschikbaar is op het ontvangende domein, blijft het toch mogelijk om de authenticiteit van de ontvangende mailserver te verhogen door een combinatie van DNSSEC en certificaatvalidatie toe te passen. Dit biedt aanzienlijk meer zekerheid dan STARTTLS of Enforce-TLS, maar niet zo veilig als DANE.

Hoe werkt deze methode in de praktijk?

1. Veilig ophalen van het MX-record via DNSSEC: De verzendende mailserver gebruikt DNSSEC (Domain Name System Security Extensions) om te garanderen dat het opgevraagde MX-record, het DNS-record dat aangeeft welke mailserver e-mail mag ontvangen voor het domein, authentiek is en niet onderweg is aangepast door een aanvaller.
2. Controleren van het servercertificaat: Nadat het juiste adres van de ontvangende mailserver is vastgesteld, wordt een versleutelde verbinding (via STARTTLS) opgezet. De verzendende mailserver controleert vervolgens of het TLS-certificaat dat de ontvangende server aanbiedt geldig is, bij het serveradres hoort en niet is verlopen of ingetrokken. Alleen als deze controles slagen, wordt het bericht afgeleverd.

Beperkingen en voordelen:

• Deze methode biedt meer bescherming dan reguliere, opportunistisch beveiligde e-mail, omdat je zeker weet dat het bericht naar de juiste server wordt gestuurd en de verbinding versleuteld is.
• Het mist echter de extra laag van zekerheid die DANE biedt, omdat niet via een TLSA-record gecontroleerd wordt welk certificaat daadwerkelijk hoort bij de ontvangende server.
• Desondanks is het een waardevol en praktisch alternatief zolang DANE of MTA-STS niet (breed) geïmplementeerd zijn op het ontvangende domein.

Kortom, DNSSEC met certificaatvalidatie vormt een belangrijke, pragmatische tussenstap richting veiliger e-mailtransport en helpt organisaties om ook bij beperkte adoptie van geavanceerdere standaarden toch een hoger beveiligingsniveau te bereiken.

Hoe werken de standaarden in de praktijk voor inkomende en uitgaande e-mail?

Bij alle vormen van communicatie, en dus ook bij e-mail, zijn er altijd twee hoofdrollen: de verzender en de ontvanger. Beide partijen hebben hun eigen verantwoordelijkheid in het veilig verzenden en ontvangen van berichten. E-mailstandaarden zijn erop gericht om beide rollen te ondersteunen, maar de praktische toepassing en de risico’s verschillen per rol.

Inkomende e-mail: de rol van de ontvanger van beveiligd mailen

Als ontvanger wil je het zo eenvoudig mogelijk maken voor andere organisaties om jou veilig te mailen. Jouw primaire taak is dus het beschikbaar stellen van een beveiligde en controleerbare infrastructuur. Dat betekent concreet:

• Activeer DNSSEC voor je domein: Hiermee beveilig je de DNS-informatie van je domein, zodat anderen er zeker van kunnen zijn dat ze de juiste mailserver bereiken.
• Publiceer een DANE/TLSA-record voor je mailserver(s): Dit stelt verzendende partijen in staat te verifiëren dat ze met jouw échte, geauthenticeerde mailserver praten.
• Implementeer MTA-STS: Vooral van belang als je veel mail ontvangt van partijen zoals Gmail/Google, die (nog) geen DANE ondersteunen.
• Controleer je STARTTLS-configuratie: Zorg dat je mailserver altijd versleutelde verbindingen accepteert en dat je certificaten up-to-date en geldig zijn.

Praktisch gezien betekent dit dat je als ontvanger de technische ‘handvatten’ biedt waarmee anderen veilig bij jou kunnen afleveren. Maar je kunt zelf niet afdwingen dat elke verzender die standaarden ook werkelijk controleert en toepast. Het is dus noodzakelijk om je domein zó in te richten dat het voor verzenders zo makkelijk mogelijk wordt om compliant en veilig bij jou te bezorgen.

Praktijkvoorbeeld:
Een ziekenhuis implementeert DNSSEC en publiceert een DANE/TLSA-record. Een zorgverzekeraar die gevoelige patiëntinformatie wil sturen, controleert het MX- en TLSA-record via DNSSEC. Alleen als alle controles slagen, wordt de e-mail daadwerkelijk en veilig afgeleverd bij het ziekenhuis.

Uitgaande e-mail: de rol van de verzender bij beveiligde e-mail

Voor uitgaande e-mail draait alles om verantwoordelijkheid. De verzender is degene die beslist hoe en of een e-mail veilig verstuurd wordt. De wet legt de verantwoordelijkheid voor het veilig afleveren van gevoelige informatie expliciet bij de verzender: als er iets misgaat onderweg, ligt het risico bij degene die het bericht heeft verzonden.

Stappen voor veilige uitgaande e-mail:

• Controleer of het ontvangende domein DNSSEC gebruikt: Zo weet je zeker dat je de juiste mailserver aanspreekt.
• Controleer op een DANE/TLSA-record: Hiermee check je of de server zich identificeert met het juiste certificaat.
• Controleer op MTA-STS: Als DANE niet beschikbaar is, kijk dan of het domein MTA-STS ondersteunt, vooral belangrijk richting partijen als Google/Gmail.
• Combineer DNSSEC met certificaatvalidatie: Als DANE en MTA-STS beide ontbreken, kun je alsnog de authenticiteit verhogen door DNSSEC te combineren met controle van het aangeboden TLS-certificaat.
• Alleen als alle controles slagen, wordt de e-mail verstuurd: Voldoet de ontvanger niet aan de minimumeisen, dan is het aan de verzender om het bericht te bouncen of via een beveiligd portaal aan te bieden.

Samenvattend:

• De ontvanger stelt een veilig kanaal beschikbaar, maar het is uiteindelijk de verzender die bepaalt of de e-mail veilig (en dus volgens de standaard) wordt verzonden.
• Daarom ligt de echte uitdaging, én de juridische aansprakelijkheid, bij de verzender.

Kortom:

• De ontvanger maakt veilig mailen mogelijk door zijn infrastructuur goed in te richten en de noodzakelijke standaarden te publiceren.
• De verzender is verantwoordelijk voor het daadwerkelijk toepassen van die standaarden bij het versturen van gevoelige informatie en moet zorgen dat alleen via een veilige route wordt bezorgd.

Zo ondersteunen en versterken de standaarden beide rollen — maar bepalen zij vooral wie waar op moet letten en waar de grootste risico’s en verantwoordelijkheden liggen.

Wat als de ontvanger niet aan de standaarden voldoet?

De realiteit is dat veel ontvangende mailservers niet voldoen aan de vereiste standaarden zoals DANE of MTA-STS. Minder dan 30% van de Nederlandse domeinen heeft DANE, wereldwijd is de adoptie van MTA-STS zelfs lager dan 1%, en grote partijen als Google ondersteunen DANE nog steeds niet voor inkomend e-mailverkeer. Waarschijnlijk heeft circa 40% van de organisaties in Nederland wel DNSSEC, maar geen DANE of MTA-STS. Dit betekent dat je als verzendende organisatie een oplossing gebruikt die alle 3 de standaarden ondersteunt en toepast op je uitgaande e-mail, je toch nog voor 20%-30% van je mails te maken hebt met een ontvanger die niet veilig (genoeg) mails kan ontvangen. Dit creëert een dilemma voor verzendende organisaties die compliant willen zijn met de BIO2, NEN 7510 en ISO 27001, en tegelijkertijd willen dat e-mailverkeer soepel blijft verlopen.

Als verzender heb je bij het ontbreken van deze standaarden feitelijk drie opties:

1. De e-mail toch afleveren, ondanks het risico: Je kiest ervoor om het bericht alsnog te versturen, zelfs als er geen veilige afleverroute beschikbaar is. Dit is echter niet compliant met de eisen uit de BIO2, NEN 7510 en ISO 27001, en brengt aanzienlijke juridische en privacy-risico’s met zich mee. Vooral binnen sectoren als zorg, overheid en financiële dienstverlening is het versturen van gevoelige informatie via een onbeveiligde route absoluut onacceptabel.
2. De e-mail weigeren te versturen (bouncen): Hierbij weigert je mailserver het bericht af te leveren en ontvangt de verzender een melding dat veilige aflevering niet mogelijk is. Hoewel dit technisch en juridisch een juiste keuze is, blijkt het in de praktijk onhandig: medewerkers moeten een andere manier vinden om hun bericht toch bij de ontvanger te krijgen. Dit leidt vaak tot gebruik van alternatieven als persoonlijke e-mailadressen, USB-sticks of zelfs WhatsApp — oplossingen die doorgaans juist nog onveiliger zijn. Bovendien zorgt het voor frustratie bij eindgebruikers en verhoogt het de kans op datalekken.
3. De e-mail afleveren via een beveiligd portaal (“secure mail portal”): In dit scenario wordt de e-mail niet direct naar de mailbox van de ontvanger verstuurd, maar geplaatst in een beveiligd portaal. De ontvanger ontvangt een notificatie — meestal per e-mail — met een link en kan, na sterke authenticatie, het bericht veilig lezen, beantwoorden, downloaden, doorsturen, etc.

Waarom is terugvallen op een beveiligd berichtenportaal het enige realistische alternatief?

• Gebruikerservaring: De workflow blijft eenvoudig; de verzender merkt niets van het verschil, de ontvanger krijgt duidelijke instructies.
• Compliance: De organisatie voldoet aan alle wettelijke eisen: gevoelige informatie wordt uitsluitend via een gecontroleerd en beveiligd kanaal aangeboden.
• Audit & Logging: Het is altijd inzichtelijk wie, wanneer en hoe toegang had tot welk bericht – essentieel voor audits en incidentonderzoek.
• Risicobeheersing: Door gevoelige informatie niet via onveilige e-mailroutes te versturen, wordt het risico op onderschepping tot een minimum beperkt.
• Adoptie: Secure mail portals zijn inmiddels standaard binnen overheden, zorg en financiële instellingen, waardoor ontvangers bekend zijn met deze manier van werken.
• Verlaagde druk op eindgebruikers: Eindgebruikers hoeven geen technische foutmeldingen te interpreteren of eigen alternatieven te zoeken.

Praktijkvoorbeeld:
Een ziekenhuis wil gevoelige patiëntinformatie mailen naar een patiënt. De mailserver van de patiënt ondersteunt geen DANE, geen MTA-STS en heeft geen DNSSEC. In plaats van risico te nemen of te bouncen, wordt het bericht automatisch via een beveiligd portaal aangeboden. De patiënt ontvangt een e-mail met een link naar het portaal en kan daar het bericht lezen of downloaden. Zo wordt gegarandeerd voldaan aan de wet- en regelgeving én wordt het risico op datalekken tot een minimum beperkt.

Praktische tips voor de implementatie van beveiligd mailen

Een goede inrichting van je e-mailomgeving vereist aandacht voor zowel inkomende als uitgaande e-mailstromen. Hieronder vind je de belangrijkste stappen en aandachtspunten per rol:

Voor inkomende e-mail (de rol van de ontvanger)

Wil je dat anderen jou veilig kunnen mailen, dan is het belangrijk om je infrastructuur zo volledig mogelijk te beveiligen. Idealiter implementeer je álle relevante standaarden:

• Activeer DNSSEC voor je domein: Bescherm je DNS-informatie tegen manipulatie. Dit is de fundamentele basis voor verdere beveiliging.
• Publiceer een DANE/TLSA-record: Hiermee stel je verzendende partijen in staat om te controleren of ze met jouw echte, geauthenticeerde mailserver communiceren.
• Implementeer MTA-STS: Zeker als je veel communiceert met organisaties die geen DANE ondersteunen (zoals Google/Gmail), is dit een belangrijke extra beveiligingslaag.
• Controleer of je mailserver STARTTLS ondersteunt en zorg altijd voor een geldig certificaat: Hiermee garandeer je dat e-mail altijd versleuteld wordt afgeleverd.

Lukt het (nu) niet om alle standaarden te implementeren?

• Doe dan in elk geval wat wél mogelijk is — bijvoorbeeld door alvast DNSSEC te activeren en/of MTA-STS toe te voegen als DANE niet wordt ondersteund door je huidige leverancier.
• Let op: sommige hosting- of e-mailproviders bieden (nog) geen volledige ondersteuning voor DANE, DNSSEC of MTA-STS. In dat geval is het verstandig om te onderzoeken of overstappen naar een leverancier die deze standaarden wél ondersteunt haalbaar is. Hiermee vergroot je niet alleen je eigen digitale weerbaarheid, maar help je ook andere organisaties om compliant en veilig e-mail te versturen naar jouw domein.

Voor uitgaande e-mail (de rol van de verzender)

Als verzender van gevoelige informatie rust de volledige verantwoordelijkheid bij jou om te waarborgen dat de e-mail alleen via een veilige route wordt afgeleverd. Ook als de ontvanger niet volledig compliant is, moet je als verzender alles doen wat binnen je mogelijkheden ligt om compliant en veilig te werken:

• Gebruik een mailgateway of oplossing die de standaarden ondersteunt: Kies voor een oplossing die DANE, MTA-STS én DNSSEC volledig ondersteunt en die bij iedere verzending automatisch controleert welke standaard(s) het ontvangende domein biedt. Dit zorgt ervoor dat je altijd de veiligste beschikbare route kiest.
• Lever uitsluitend veilig af of kies voor een beveiligd portaal als dat niet kan: Zorg dat je mailgateway alleen e-mail aflevert via een beveiligde verbinding (conform DANE, MTA-STS of DNSSEC met certificaatvalidatie). Is geen van deze standaarden beschikbaar bij de ontvanger, lever het bericht dan automatisch aan via een beveiligd portaal. Zo voorkom je dat gevoelige informatie via een onveilige route wordt verstuurd en blijf je voldoen aan de eisen van wet- en regelgeving.
• Implementeer logging en monitoring: Registreer en monitor alle afleverpogingen en -resultaten. Zo kun je aantonen dat je organisatie compliant handelt en kun je bij incidenten of audits verantwoording afleggen.
• Automatiseer veilige fallback-mechanismen: Laat je mailoplossing automatisch overschakelen naar een beveiligd portaal wanneer DANE, MTA-STS en/of DNSSEC ontbreken bij het ontvangende domein. Hierdoor is het proces voor eindgebruikers eenvoudig en voorkom je dat medewerkers zelf moeten inschatten wanneer een alternatieve (en vaak onveilige) verzendmethode nodig is.

Kun je een e-mail niet veilig genoeg versturen?

Neem dan verantwoordelijkheid: lever nooit gevoelige informatie af via een (te) veilige route, tenzij je een specifieke overeenkomst over informatie-uitwisseling met de ontvanger hebt afgesloten die toch voldoende waarborgen bieden rondom de beveiliging en privacybescherming, waarna je de organisatie op een ‘whitelist’ kunt plaatsen. Door je processen zo in te richten dat je altijd de maximaal mogelijke beveiliging toepast en in laatste instantie een beveiligd portaal gebruikt, zorg je ervoor dat jouw organisatie altijd compliant blijft en dat privacy en vertrouwelijkheid gewaarborgd zijn — ongeacht de beperkingen aan de kant van de ontvanger.

Conclusie: Veilig mailen vraagt om proactieve verantwoordelijkheid van verzender én ontvanger

De moderne standaarden voor e-mailbeveiliging – zoals DANE, MTA-STS, DNSSEC en STARTTLS – zijn geen theoretische luxe, maar een wettelijke en praktische noodzaak voor elke organisatie die vertrouwelijke informatie per e-mail uitwisselt. Het doel is helder: e-mail moet onderweg beschermd zijn tegen afluisteren, manipulatie en misbezorging, en alleen terechtkomen bij de bedoelde server van de ontvanger.

Daarnaast vereist de Algemene Verordening Gegevensbescherming (AVG) expliciet dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens veilig te verzenden. Dit betekent dat de verzender van persoonsgegevens juridisch verantwoordelijk is als er onderweg een datalek ontstaat door onvoldoende beveiliging. Het niet naleven van deze verplichting kan leiden tot aanzienlijke boetes vanuit de Autoriteit Persoonsgegevens (AP). Daarom is veilige aflevering via standaarden als DANE, MTA-STS en DNSSEC niet alleen een praktische noodzaak, maar ook een concrete juridische verplichting vanuit privacywetgeving (AVG).

Het gezamenlijke succes van veilig e-mailtransport staat of valt met de inzet van beide rollen:

• Als ontvanger moet je je infrastructuur optimaal inrichten en alle relevante standaarden implementeren, zodat anderen jou veilig kunnen mailen. Lukt dit (nog) niet volledig? Doe dan alles wat mogelijk is, en overweeg over te stappen naar een leverancier die wél volledige ondersteuning biedt.
• Als verzender draag je de ultieme verantwoordelijkheid. Je moet per verzending controleren of het ontvangende domein veilig te bereiken is, en alleen via een gecontroleerde, beveiligde route gevoelige informatie afleveren. Zijn de noodzakelijke standaarden niet beschikbaar bij de ontvanger, dan is afleveren via een beveiligd portaal geen keuze, maar een vereiste.

In de praktijk betekent dit:

• Alleen het combineren van standaarden als DANE, MTA-STS, DNSSEC en STARTTLS biedt optimale bescherming en compliance.
• Waar volledige adoptie nog niet mogelijk is, ligt de plicht bij elke organisatie om in ieder geval zoveel mogelijk maatregelen te treffen, altijd de meest veilige route te kiezen en – waar nodig – aanvullende oplossingen zoals een beveiligd portaal in te zetten.
• Door deze aanpak voorkom je niet alleen technische kwetsbaarheden, maar voldoe je ook aantoonbaar aan de eisen van de BIO2, NEN 7510 en ISO 27001.

Kortom:
Echt veilig mailen vraagt om voortdurende aandacht, eigenaarschap en samenwerking van zowel verzender als ontvanger. Door te investeren in de juiste standaarden en processen borg je niet alleen de privacy van je relaties, maar bescherm je ook de reputatie en continuïteit van je eigen organisatie. Wacht niet op verplichte handhaving of incidenten, maar neem vandaag nog de regie over veilig e-mailtransport.