E-mailversleuteling: TLS, end-to-end en de AVG

E-mails worden vaak vergeleken met ansichtkaarten: wie onderweg meeleest, ziet alles. E-mailversleuteling bepaalt of dat klopt. Dit bericht beschrijft wat transportversleuteling en end-to-end-versleuteling bereiken, wat rechters en toezichthouders erover hebben gezegd en welke techniek in de praktijk het verschil maakt.

Het bericht houdt rekening met rechtspraak, techniek en de eisen van grote mailproviders tot eind oktober 2026.

De opbouw volgt de route van een e-mail. Eerst komen de juridische norm en de begrippen, daarna de rechtspraak en het standpunt van de toezichthouders. Vervolgens gaat het over de techniek: transportversleuteling, het controleren van de mailheader, bescherming tegen vervalste afzenders en end-to-end-methoden zoals S/MIME en OpenPGP. Aan het eind staat een beslishulp die laat zien welke versleuteling bij welk soort e-mail past.

E-mailversleuteling en de AVG: wat de norm is

Persoonsgegevens moeten zo worden verwerkt dat ze tegen onbevoegde toegang beschermd zijn. Dat staat in art. 5, lid 1, onder f AVG. Op grond van lid 2 moet de verwerkingsverantwoordelijke dit bovendien kunnen aantonen. Hoe die bescherming er concreet uitziet, regelt art. 32 AVG: maatregelen moeten de stand van de techniek weerspiegelen en passen bij het risico. De bepaling schrijft geen specifieke methode voor. Versleuteling wordt daar slechts als mogelijke maatregel genoemd.

Bijzondere categorieën van gegevens, zoals gezondheidsgegevens, vallen onder art. 9 AVG. Daar is de beschermingsbehoefte vanaf het begin hoger. Maar ook ogenschijnlijk onschuldige e-mails bevatten persoonsgegevens: een afzenderadres met een echte naam is al genoeg.

In 2026 laat de rechtstoestand zich als volgt samenvatten: er is geen algemene plicht om elke e-mail end-to-end te versleutelen. Er is ook geen algemeen groen licht voor onversleutelde e-mails. Wat telt, is het risico voor de betrokkenen en de vraag wat volgens de stand van de techniek redelijk is. Wie persoonsgegevens per e-mail verstuurt, heeft dus een gemotiveerde beslissing nodig die bij twijfel kan worden overgelegd.

Transportversleuteling, end-to-end-versleuteling en handtekeningen duidelijk onderscheiden

In het dagelijks gebruik worden drie dingen door elkaar gehaald die verschillende taken hebben.

Transportversleuteling beveiligt de verbinding tussen twee stations. Ze gebruikt TLS (Transport Layer Security), de opvolger van SSL. Op elk traject wordt de inhoud versleuteld verzonden. Op de mailserver zelf staat de inhoud echter in leesbare tekst, omdat de server de e-mail moet verwerken en opslaan.

End-to-end-versleuteling (E2E) versleutelt de inhoud in het mailprogramma van de afzender. Alleen de ontvanger kan haar ontsleutelen. Tussenliggende servers zien alleen gegevens waar ze niets mee kunnen. Hiervoor zijn S/MIME en OpenPGP gangbaar geworden.

Een handtekening is iets anders: ze versleutelt niets, maar bewijst van wie een e-mail komt en dat hij onderweg niet is gewijzigd. Ze speelt een belangrijke rol bij de uitwisseling van sleutels, omdat openbare sleutels meestal via ondertekende e-mails worden doorgegeven.

Beide methoden hebben één beperking gemeen: onderwerp, afzender en ontvanger blijven meestal leesbaar. De richtsnoeren van de Duitse Datenschutzkonferenz wijzen erop dat ook deze omstandigheden van de communicatie bescherming kunnen vereisen.

Rechtspraak over e-mailversleuteling: wanneer transportversleuteling volstaat

Duitse rechters hebben zich de afgelopen jaren meermaals over de vraag uitgesproken, met schijnbaar tegenstrijdige uitkomsten. Bij nader inzien volgen de uitspraken één lijn: hoe groter de mogelijke schade, hoe hoger de eisen.

De oudste zaak uit de reeks dateert van 2020. Op 17 december 2020 besliste het Verwaltungsgericht Mainz (zaaknr. 1 K 778/19.MZ) of een advocaat e-mails aan cliënten alleen met transportversleuteling mag versturen. De beslissing is ingedeeld onder art. 32 en art. 5 AVG. Volgens de samenvatting volstaat transportversleuteling voor de e-mailcommunicatie van advocaten. End-to-end-versleuteling is dus alleen in individuele gevallen met verhoogd risico nodig.

Ook vaak aangehaald, maar slechts beperkt relevant, is de beslissing van de Bundesgerichtshof van 22 maart 2021 (AnwZ (Brfg) 2/20). Ze betreft de bijzondere elektronische advocatenpostbus (beA). De beveiligingsarchitectuur daarvan is gebaseerd op speciale hardwarebeveiligingsmodules. Er bestaat daar geen aanspraak op end-to-end-versleuteling. De beslissing is nauwelijks toepasbaar op gewone e-mails.

De zaak voor het Oberlandesgericht Karlsruhe toont de lijn in het zakelijke verkeer. Een hacker had het e-mailaccount van een autodealer overgenomen en de koper een gemanipuleerde factuur met een ander rekeningnummer gestuurd. De koper betaalde op de verkeerde rekening. Op 27 juli 2023 oordeelde de rechter (zaaknr. 19 U 83/22) dat de noodzakelijke beschermingsmaatregelen afhangen van de gerechtvaardigde beveiligingsverwachtingen van de zakenpartners. De betaling aan de fraudeur bevrijdde de koper niet, die voor de tweede keer moest betalen. Het Landgericht Mosbach had in eerste aanleg anders beslist.

Het Oberlandesgericht Schleswig kwam in december 2024 tot een ander resultaat. Ook hier ging het om een gemanipuleerde factuur, ditmaal aan een consument en voor ongeveer 15.000 euro. Volgens het persbericht van de rechter had de factuur end-to-end-versleuteld moeten worden verzonden, omdat een hackeraanval een voorzienbaar risico is. De klant kon een schadevordering verrekenen met de betalingsvordering en hoefde niet opnieuw te betalen. De rechter had cassatie toegelaten, maar volgens het persbericht is het arrest toch onherroepelijk. Een analyse van deze beslissingen, inclusief een uitspraak van het Verwaltungsgericht Düsseldorf van 2 april 2026 (29 K 7351/23), vindt u in het bericht E-mailbeveiliging: berichten beschermen tegen gevaren.

Hoe past dat samen? Kennelijk zijn de beschermingsbehoefte en de mogelijke schade doorslaggevend. Tussen bedrijven hebben de rechters tot nu toe eerder standaardmaatregelen aanvaard. Waar een consument een groot bedrag overmaakt naar een rekening die alleen in een onbeveiligde e-mail is genoemd, is meer nodig. De naam van de methode is bijzaak. Wat telt, is dat de maatregel het concrete risico daadwerkelijk verkleint. Het blijft bijvoorbeeld open of de toestemming van de ontvanger voor zwakkere versleuteling volstaat. Daarover bestaat nog geen betrouwbare beslissing.

DSK-richtsnoeren en BSI: de maatstaf van de toezichthouders

Op 27 mei 2021 nam de Conferentie van de onafhankelijke toezichthouders voor gegevensbescherming van Duitsland (DSK) de richtsnoeren "Maatregelen ter bescherming van persoonsgegevens bij verzending per e-mail" aan, stand 16 juni 2021. Beieren stemde tegen. Het document is openbaar beschikbaar (in het Duits) en maakt een duidelijk onderscheid.

Bij normaal risico eisen de richtsnoeren verplichte transportversleuteling op basis van de technische richtlijn BSI TR-03108-1. Bij hoog risico moeten verwerkingsverantwoordelijken in de regel end-to-end-versleuteling gebruiken, samen met gekwalificeerde transportversleuteling, bijvoorbeeld met DANE of DNSSEC. Het beroepsgeheim geldt als aanwijzing voor een hoog risico, dat per geval moet worden beoordeeld.

Boetes voor onversleutelde e-mails zijn zeldzaam; de toezichthouders werken minder met sancties dan met stukken als dit. Toch heeft het document gewicht als maatstaf: in de geschillen over gemanipuleerde facturen werd besproken of de richtsnoeren van de autoriteiten kunnen worden toegepast. Het Oberlandesgericht Karlsruhe achtte ze in zijn zaak niet relevant. De richtsnoeren zijn niet bindend. Wie ervan afwijkt, moet dat echter kunnen motiveren.

In TR-03108 beschrijft het Duitse Bundesamt für Sicherheit in der Informationstechnik (BSI) veilig e-mailtransport voor providers, inclusief certificering. Voor beheerders van mailservers is dat de technische maatstaf. Daarnaast bevat TR-03182 een aanbeveling over e-mailauthenticatie.

Transportversleuteling goed inrichten: TLS 1.3, poort 465, MTA-STS en DANE

Mailprogramma's en servers spreken meerdere protocollen. SMTP (Simple Mail Transfer Protocol) wordt sinds 1982 gebruikt en verzendt e-mails. ESMTP is de uitgebreide variant. De afkortingen in de mailheader laten zien wat er op elk traject is gebeurd: ESMTPS betekent dat TLS is onderhandeld. ESMTPSA betekent bovendien dat de afzender met gebruikersnaam en wachtwoord is ingelogd.

Er zijn twee manieren om te onderhandelen. Bij impliciete TLS is de verbinding vanaf het begin versleuteld. Voor het verzenden vanuit het mailprogramma voorziet RFC 8314 hiervoor in poort 465, en voor het ophalen in IMAP op poort 993 of POP3 op poort 995. Bij STARTTLS begint de verbinding onversleuteld en spreken beide kanten pas daarna de overstap af. Aanvallers kunnen deze stap verstoren. De studie "Why TLS is better without STARTTLS" (USENIX Security 2021) beschrijft downgrade- en injectieaanvallen. Impliciete TLS geldt daarom als de betere keuze, ook al wordt poort 587 met STARTTLS op veel plaatsen nog parallel aangeboden.

Wat de versies betreft: TLS 1.0 en 1.1 zijn sinds RFC 8996 (maart 2021) officieel verouderd. TLS 1.2 is het minimum, TLS 1.3 het doel, zoals ook in de technische richtlijn BSI TR-02102-2 staat.

Tussen de servers blijft één probleem bestaan. Daar verloopt de versleuteling meestal via STARTTLS en is ze vaak slechts opportunistisch: als ze mislukt, valt de verbinding terug op onversleuteld. Veel mailservers bieden een modus die de aflevering weigert als er geen TLS-verbinding tot stand komt. Ook die verloopt meestal via STARTTLS en is geen impliciete TLS.

Twee methoden dichten de kloof:

• MTA-STS (RFC 8461): Het domein van de ontvanger publiceert een beleid waarin staat dat TLS met een geldig certificaat verplicht is. Verzendende servers houden zich eraan. DNSSEC is niet nodig. Er zijn de modi testing en enforce. Meldingen over problemen levert TLS-RPT.
• DANE: Een TLSA-record in de DNS legt vast welk certificaat de server van de ontvanger gebruikt. Hiervoor is DNSSEC nodig. DANE waarborgt de authenticiteit van de server van de ontvanger tegen downgrade- en man-in-the-middle-aanvallen.

Volgens Microsoft is inkomende SMTP met DANE sinds 22 oktober 2024 algemeen beschikbaar voor Exchange Online, maar standaard uitgeschakeld. MTA-STS wordt volgens de documentatie van Microsoft ondersteund. Met online tools kunt u controleren of uw eigen domein zulke beleidsregels publiceert; meer daarover in de volgende paragraaf.

E-mailversleuteling controleren: de mailheader lezen en de server van de ontvanger testen

Of een e-mail daadwerkelijk versleuteld is aangekomen, blijkt uit de mailheader. Dubbelklik in klassieke Outlook-versies op de e-mail, kies daarna Bestand, Eigenschappen en kijk bij het veld Internetkoppen. In de nieuwe Outlook en in webmail is de weg anders. De menu's veranderen per versie, dus het loont om de help van het betreffende programma te raadplegen.

In de headers zijn de Received-regels interessant. Elke server die de e-mail doorgeeft, voegt er een toe. Moderne servers vermelden daar de protocolversie en het cijfer, zoals TLSv1.3 en TLS_AES_256_GCM_SHA384. Het onderstaande fragment is nagebouwd, met plaatsaanduidingen in plaats van echte adressen.

De header is echter geen volledig bewijs in de zin van art. 5, lid 2. Hij dekt alleen de trajecten waarop een server de regel heeft toegevoegd. Waar doorsturen of gateways in het spel zijn, blijft een lacune bestaan. Als element van de documentatie is hij toch nuttig.

Voor het verzenden kunt u testen wat een server van de ontvanger ondersteunt. CheckTLS bevraagt de mogelijkheden zonder een e-mail te versturen en laat onder meer zien of TLS wordt aangeboden en of er een TLSA-record voor DANE bestaat. Het resultaat "no TLSA" komt bij veel domeinen voor. De dienst internet.nl controleert STARTTLS, DANE en ook SPF, DKIM en DMARC. MTA-STS maakt volgens de documentatie geen deel uit van de beoordeling.

Is het TLS-resultaat negatief, dan helpt het de ontvanger te informeren. Als alternatief kan een portaal of een versleutelde bijlage worden gebruikt; daarover verderop meer. Voor uw eigen website en de beschermingsmaatregelen biedt de AVG-websitecheck een eerste richtlijn. Beveiligingschecks voor domeinen, inclusief e-mailauthenticatie, vindt u in de Web Security Checks.

SPF, DKIM en DMARC: bescherming tegen vervalste afzenders

Versleuteling beschermt tegen meelezen, niet tegen vervalsing. Daar ging het in de factuurzaken juist om: een aanvaller verstuurt een e-mail die lijkt te komen van de echte afzender, of gebruikt een gekaapte mailbox. Tegen vervalste afzenders helpen drie methoden die samenwerken.

Recent komt de druk om ze in te voeren van de grote providers. Sinds 1 februari 2024 eisen Google en Yahoo van alle afzenders onder meer SPF of DKIM, TLS en een laag spampercentage. Wie meer dan 5.000 e-mails per dag naar Gmail-adressen stuurt, heeft SPF, DKIM en minstens een DMARC-beleid nodig. Microsoft voerde vanaf 5 mei 2025 vergelijkbare eisen in voor afzenders met grote volumes naar Outlook.com, Hotmail en Live. De regels in detail vindt u in de documentatie van Google.

De DSK-richtsnoeren bepalen dat DKIM en DMARC bij ontvangst worden gecontroleerd. Hier tekent zich een trend af die verwerkingsverantwoordelijken beter niet kunnen negeren. Meer achtergrond over vervalste berichten vindt u in het bericht E-mails, phishing en de echtheid van elektronische berichten (in het Duits). Over de omgang met onbekende afzenders en bijlagen is er een apart bericht (in het Duits).

End-to-end-versleuteling met S/MIME en OpenPGP: de stand van zaken in 2026

Wie verder wil of moet gaan dan transportversleuteling, heeft twee gevestigde methoden. Beide versleutelen de inhoud in het mailprogramma. Bij beide moeten vooraf sleutels worden uitgewisseld. De DSK-richtsnoeren noemen end-to-end-versleuteling de "meest grondige bescherming", omdat ze ook gegevens in rust beschermt.

S/MIME

S/MIME werkt met certificaten die een certificeringsinstantie uitgeeft. Ze zijn rechtstreeks bruikbaar in Outlook, Apple Mail en veel andere programma's. De afzender haalt de openbare sleutel van de ontvanger meestal uit een ondertekende e-mail, waaruit het certificaat kan worden geïmporteerd.

Sinds 2021 is er veel veranderd rond certificaten. De vroeger gangbare klassen 1 tot 4 zijn verouderd. Sinds 1 september 2023 gelden de Baseline Requirements van het CA/Browser Forum, met vier typen die verschillen in de omvang van de validatie: mailbox-, organization-, sponsor- en individual-validated. Het forum publiceert zelf de actuele versie van de eisen.

OpenPGP

OpenPGP werkt zonder centrale certificeringsinstantie. Iedereen genereert zijn eigen sleutelpaar. De authenticiteit wordt gecontroleerd aan de hand van vingerafdrukken of certificering door derden. De DSK wijst er uitdrukkelijk op dat het louter publiceren van een sleutel op een sleutelserver geen aanwijzing is voor de authenticiteit ervan. Praktisch is de Web Key Directory, waarmee een domein zelf zijn sleutels kan aanbieden. Een inleiding over ondertekenen vindt u in het bericht E-mails ondertekenen en versturen met PGP.

De standaard is veranderd: RFC 9580 (juli 2024) vervangt RFC 4880. Ze brengt nieuwe sleutelformaten, moderne algoritmen zoals X25519 en Ed25519 en geauthenticeerde versleuteling. Parallel onderhoudt het GnuPG-project een afwijkende lijn onder de naam LibrePGP. Dat maakt zaken ingewikkeld. Thunderbird gebruikt in plaats van GnuPG een eigen bibliotheek, RNP, en Mozilla documenteert problemen met sleutels die kenmerken hebben die RNP niet ondersteunt. Sleutels verhuizen dus niet altijd probleemloos tussen programma's.

In de praktijk met Outlook en Thunderbird

In de praktijk maakt het vaak verschil of u één account gebruikt of meerdere. De plug-in GpgOL uit het pakket Gpg4win is in Outlook in te stellen en werkt met één account. Bij meerdere accounts verschijnt echter bij elke verzending een melding en kan de toewijzing van sleutels door elkaar raken. Voor omgevingen met veel accounts is dat een obstakel.

Gpg4win is momenteel beschikbaar in versie 5.1.1 (uitgebracht op 23 september 2026), zoals de projectpagina laat zien. GpgOL draait in klassieke Outlook. Of en wanneer de nieuwe Outlook wordt ondersteund, is volgens een bericht op het GnuPG-forum nog open. OpenPGP is sinds versie 78 in Thunderbird ingebouwd, dus een add-on is niet nodig. Het wordt ingesteld in de accountinstellingen onder end-to-end-versleuteling. Wie slechts één account gebruikt, is er snel.

In december 2025 onderzocht het BSI twaalf gratis e-mailprogramma's. Volgens het persbericht (in het Duits) verschillen de programma's in hun ondersteuning van end-to-end-versleuteling. Beveiligingsfuncties zijn vaak niet standaard ingeschakeld.

Een zijpad is de Efail-aanval uit 2018. Die maakte misbruik van actieve HTML-inhoud in e-mails om ontsleutelde teksten te laten weglekken. Tegenmaatregelen zijn actuele programma's en het uitschakelen van HTML-weergave voor versleutelde e-mails. De website efail.de geeft uitleg. Paniek is niet nodig, maar het voorbeeld toont dat ook goede cryptografie kan falen door de implementatie.

Portalen, gateways en Microsoft-versleuteling als alternatief

Het grootste obstakel voor end-to-end-versleuteling is het uitwisselen van sleutels met elke correspondent. Daarom kiezen veel organisaties voor oplossingen waarbij de inspanning bij de afzender ligt.

• Gatewayversleuteling: Een server binnen het bedrijf verzorgt S/MIME of PGP. De bescherming reikt dan tot de gateway van de ontvanger. Afhankelijk van de inrichting wordt de e-mail ontsleuteld in de mailbox opgeslagen. De vertrouwensvraag verschuift naar de beheerder van de gateway.
• Portaal: De e-mail bevat alleen een melding. Het bericht wordt na inloggen in de browser opgehaald. Ook de DSK-richtsnoeren noemen een webportaal als communicatiekanaal met betrokkenen.
• Microsoft Purview Message Encryption: Bruikbaar in de nieuwe Outlook met een passende licentie. Ontvangers buiten Microsoft krijgen instructies om het bericht te openen. Het kan niet worden gecombineerd met S/MIME op hetzelfde bericht.
• Met wachtwoord beveiligde bijlage: Een archief met AES-256, bijvoorbeeld gemaakt met 7-Zip, dient als envelop. Het wachtwoord gaat via een ander kanaal, bijvoorbeeld telefonisch (kanaalscheiding). Sms is als kanaal omstreden en moet alleen met voorbehoud worden gebruikt.

Wie een gateway of portaal via een dienstverlener exploiteert, sluit doorgaans een verwerkersovereenkomst op grond van art. 28 AVG. Risico's voor het account zelf bij Microsoft 365 worden beschreven in het bericht over token spraying (in het Duits).

De afweging is nuchter: wie opziet tegen sleutelbeheer, heeft met een portaal of gateway een praktische middenweg. Vergeleken met echte end-to-end-versleuteling zijn er compromissen, maar het is aanzienlijk beter dan een e-mail in leesbare tekst met gevoelige inhoud.

Post-quantumcryptografie voor e-mail: wat nu al telt

End-to-end-versleuteling heeft een eigenschap die vaak over het hoofd wordt gezien: ze biedt van nature geen perfect forward secrecy. De DSK schrijft dat onderschepte e-mails kunnen worden opgeslagen en later ontsleuteld als de privésleutel bekend wordt. Met toekomstige quantumcomputers kan dit scenario ook optreden zonder dat een sleutel verloren gaat.

De standaardisatie is in volle gang. Met RFC 9936 (maart 2026) bestaat er een standaard voor ML-KEM in CMS, de basis van S/MIME. Voor TLS 1.3 voorziet BSI TR-02102-2 in hybride methoden die klassieke en post-quantumalgoritmen combineren. Voor dagelijks gebruik ontstaat daardoor geen actiebehoefte. Wie inhoud verstuurt die over 15 jaar nog vertrouwelijk moet zijn, moet het onderwerp echter in de gaten houden.

Verkeerd geadresseerde e-mails, datalekken en fax: de grenzen van versleuteling

Een nadeel van transportversleuteling geldt nog steeds: ze helpt niet als het adres van de ontvanger verkeerd is. De e-mail komt versleuteld aan op de verkeerde server en wordt daar in leesbare tekst opgeslagen. Bij end-to-end-versleuteling is dat anders, mits ze op de beoogde ontvanger is gericht. De DSK noemt individuele adressering uitdrukkelijk als maatregel.

Daarom is de organisatorische kant belangrijk. Daartoe behoren het uitschakelen van automatisch aanvullen voor gevoelige ontvangers, een vierogenprincipe bij delicate inhoud en het controleren van het adres voor het verzenden. Of een verkeerd geadresseerde e-mail als datalek moet worden gemeld, hangt af van het risico en hoort in een aparte procedure.

Ook fax komt in dit debat ter sprake. De Landesbeauftragte für Datenschutz und Informationsfreiheit van Bremen vergeleek fax met onversleutelde e-mails op een pagina met richtsnoeren (in het Duits). In een beslissing uit 2020 (11 LA 104/19) achtte het Oberverwaltungsgericht Lüneburg voor bijzonder gevoelige gegevens een individuele beoordeling nodig.

Welke versleuteling voor welke e-mail: een beslishulp

Uit de uitspraken en richtsnoeren valt een vuistregel af te leiden. Hoe hoger de mogelijke schade en de behoefte aan vertrouwelijkheid, hoe eerder end-to-end-versleuteling of een portaal in aanmerking komt. Voor facturen geldt een extra regel: een wijziging van bankgegevens wordt via een tweede kanaal bevestigd, bijvoorbeeld telefonisch.

De tabel is bedoeld als richtlijn en is geen juridisch advies. Het beoordelen van het risico is de verantwoordelijkheid van de verwerkingsverantwoordelijke en moet worden gedocumenteerd. Een korte check helpt: wat zou de ergste realistische schade voor de betrokkenen zijn? Hoe waarschijnlijk is die? Welke maatregel verkleint haar merkbaar?

Conclusie

Transportversleuteling is verplicht en volstaat volgens de DSK en de rechtspraak meestal bij normaal risico, mits ze consequent en volgens de stand van de techniek is ingericht. Daartoe behoren TLS 1.2 of, beter, 1.3, impliciete TLS in het mailprogramma en MTA-STS of DANE aan de serverkant. Bij hoog risico wordt end-to-end-versleuteling of een gelijkwaardige oplossing verwacht.

E-mailversleuteling blijft een onderwerp van afwegingen. Sleutelbeheer is omslachtig, portalen zijn een pragmatische middenweg, en tegen fraude helpen SPF, DKIM, DMARC en een tweede kanaal voor betaalgegevens minstens zo veel als cryptografie.