E-mailencryptie ontleed: TLS, S/MIME en PGP in de praktijk

E-mail is een ansichtkaart — tenzij je het versleutelt

Als je een e-mail verstuurt, reist die boodschap via meerdere servers van verzender naar ontvanger. Zonder encryptie is elke tussenstop een potentieel afluisterpunt. Vergelijk het met een ansichtkaart: iedereen die hem vasthoudt kan meelezen.

In 2026 is dat onacceptabel. Klantgegevens, contracten, medische informatie, financiële data — het gaat allemaal via e-mail. Toch begrijpen verrassend weinig bedrijven hoe e-mailencryptie écht werkt, en welke laag wat beschermt.

In dit artikel ontleden we de drie belangrijkste encryptietechnologieën: TLS (transport), S/MIME (certificaat-gebaseerd) en PGP (sleutel-gebaseerd). We leggen uit wanneer je welke nodig hebt, hoe je ze instelt, en waar de valkuilen liggen.

De drie lagen van e-mailencryptie

Laten we ze één voor één doorlopen.

TLS: de basis die iedereen moet hebben

Wat is TLS?

Transport Layer Security (TLS) versleutelt de verbinding tussen twee mailservers. Het is het equivalent van HTTPS voor websites, maar dan voor SMTP-verkeer. Wanneer jouw mailserver verbinding maakt met de server van de ontvanger, onderhandelen ze een versleutelde tunnel via het STARTTLS-commando.

Hoe werkt het technisch?

Client: EHLO mail.jouwdomein.nl
Server: 250-STARTTLS
Client: STARTTLS
[TLS handshake — certificaatverificatie + sleuteluitwisseling]
Client: EHLO mail.jouwdomein.nl (nu versleuteld)
Client: MAIL FROM:<info@jouwdomein.nl>

Na de TLS-handshake is al het verkeer tussen de twee servers versleuteld. Maar — en dit is cruciaal — alleen tussen die twee servers. Als de e-mail via meerdere relays gaat, moet élke hop TLS ondersteunen. En zelfs dan is de e-mail in rust (op de server opgeslagen) niet versleuteld.

TLS-versies en cipher suites

Niet alle TLS is gelijk. In 2026 zou je minimaal TLS 1.2 moeten eisen, en bij voorkeur TLS 1.3:

MTA-STS: TLS afdwingen

Het probleem met STARTTLS is dat het opportunistisch is. Als de ontvangende server geen TLS aanbiedt, valt de verzending terug naar platte tekst. Een aanvaller kan de STARTTLS-advertentie zelfs strippen (een zogenaamde downgrade-aanval).

De oplossing: MTA-STS (Mail Transfer Agent Strict Transport Security). Met een MTA-STS-policy vertel je de wereld: "Stuur alleen e-mail naar mij via TLS. Geen uitzonderingen."

Je publiceert een policy op https://mta-sts.jouwdomein.nl/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.jouwdomein.nl
max_age: 604800

Combineer dit met een TLS-RPT DNS-record om rapporten te ontvangen over TLS-fouten:

_smtp._tls.jouwdomein.nl IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@jouwdomein.nl"

DANE: certificaatpinning via DNS

Een stap verder: DANE (DNS-based Authentication of Named Entities) bindt het TLS-certificaat van je mailserver aan een TLSA-record in DNS (vereist DNSSEC). Hiermee elimineer je het risico van frauduleuze certificaten.

_25._tcp.mail.jouwdomein.nl IN TLSA 3 1 1 [SHA-256 hash van certificaat]

DANE is complexer om in te richten, maar biedt de sterkste garantie dat de TLS-verbinding authentiek is.

S/MIME: encryptie met digitale certificaten

Wat is S/MIME?

S/MIME (Secure/Multipurpose Internet Mail Extensions) is een standaard voor end-to-end encryptie en digitale handtekeningen van e-mail. In tegenstelling tot TLS beschermt S/MIME de inhoud van de e-mail, niet alleen het transport. De e-mail is versleuteld vóór verzending en wordt pas ontsleuteld door de ontvanger.

Hoe werkt het?

S/MIME gebruikt asymmetrische cryptografie met certificaten uitgegeven door een Certificate Authority (CA):

1. Verzender versleutelt de e-mail met het publieke certificaat van de ontvanger
2. Ontvanger ontsleutelt met zijn privésleutel
3. Optioneel: de verzender ondertekent de e-mail met zijn eigen privésleutel

[Origineel bericht]
    ↓
[Versleuteld met publieke sleutel ontvanger]
    ↓
[Ondertekend met privésleutel verzender]
    ↓
[Verzonden via SMTP (+ TLS)]
    ↓
[Ontvanger verifieert handtekening met publiek cert verzender]
    ↓
[Ontvanger ontsleutelt met eigen privésleutel]
    ↓
[Origineel bericht]

Voordelen van S/MIME

• Breed ondersteund: Outlook, Apple Mail, Thunderbird — allemaal ingebouwde S/MIME-support
• Identiteitsverificatie: Certificaten zijn gekoppeld aan een geverifieerd e-mailadres
• Juridisch erkend: Digitale handtekeningen via S/MIME zijn in veel jurisdicties juridisch geldig
• Compatibel met bedrijfsinfrastructuur: Past naadloos in Active Directory / Microsoft 365 omgevingen

Nadelen en valkuilen

• Certificaatbeheer: Elk e-mailadres heeft een eigen certificaat nodig. Bij 50 medewerkers beheer je 50 certificaten met verloopdatums.
• Kosten: Commerciële S/MIME-certificaten kosten €10-€50 per jaar per adres
• Sleuteluitwisseling: Je hebt het publieke certificaat van de ontvanger nodig vóórdat je een versleutelde e-mail kunt sturen
• EFAIL-kwetsbaarheid: In 2018 werd aangetoond dat sommige S/MIME-implementaties kwetsbaar waren voor het lekken van platte tekst via HTML-rendering. Moderne clients zijn gepatcht, maar het illustreert het risico van complexe standaarden.

S/MIME instellen in de praktijk

1. Koop een S/MIME-certificaat bij een CA (DigiCert, Sectigo, Actalis biedt gratis certificaten)
2. Installeer het certificaat in je mailclient
3. Publiceer je publieke certificaat via je DNS (SMIMEA-record) of stuur een ondertekende e-mail
4. Configureer je organisatie: In Microsoft 365 kun je S/MIME centraal beheren via Exchange admin

PGP/GPG: encryptie voor de onafhankelijke geest

Wat is PGP?

Pretty Good Privacy (PGP) — en de open-source variant GPG (GNU Privacy Guard) — biedt end-to-end encryptie zonder afhankelijkheid van een centrale autoriteit. In plaats van certificaten van een CA gebruik je zelf gegenereerde sleutelparen en een "Web of Trust" voor verificatie.

Het verschil met S/MIME

PGP in de praktijk

bash
# Sleutelpaar genereren
gpg --full-generate-key

# Publieke sleutel exporteren
gpg --armor --export info@jouwdomein.nl > publickey.asc

# E-mail versleutelen
gpg --encrypt --recipient ontvanger@example.com bericht.txt

# E-mail ontsleutelen
gpg --decrypt bericht.txt.gpg

WKD: sleuteldistributie via je domein

Het traditionele probleem van PGP — "hoe vind ik iemands publieke sleutel?" — is grotendeels opgelost met Web Key Directory (WKD). Je publiceert je publieke sleutel op een vaste URL onder je domein:

https://openpgpkey.jouwdomein.nl/.well-known/openpgpkey/hu/[hash]

Moderne mailclients (Thunderbird, K-9 Mail) zoeken automatisch via WKD naar sleutels.

Waarom PGP minder populair is geworden

Ondanks zijn kracht wordt PGP steeds minder gebruikt voor e-mail:

• UX-nachtmerrie: Sleutelbeheer is te complex voor de gemiddelde gebruiker
• Geen forward secrecy: Als je privésleutel lekt, zijn alle historische berichten te ontsleutelen
• Metadatalekkage: PGP versleutelt de inhoud, maar niet de headers (onderwerp, afzender, ontvanger)
• Geen asynchrone rotatie: In tegenstelling tot moderne protocollen (Signal) is sleutelrotatie handmatig

Desondanks blijft PGP relevant voor specifieke use cases: journalisten, beveiligingsonderzoekers, en situaties waar je expliciet geen vertrouwen in een CA wilt leggen.

Welke encryptie heb je nodig?

Beslisschema

Vraag 1: Moet de e-mail versleuteld zijn tijdens transport?

→ Ja → TLS (+ MTA-STS) — dit is het absolute minimum

Vraag 2: Moet de inhoud versleuteld zijn, ook op de server?

→ Ja → S/MIME of PGP

Vraag 3: Werk je in een bedrijfsomgeving met Microsoft/Google?

→ Ja → S/MIME (betere integratie)

→ Nee → PGP/GPG (geen CA-afhankelijkheid)

Vraag 4: Heb je juridisch geldige digitale handtekeningen nodig?

→ Ja → S/MIME (eIDAS-compatibel in de EU)

Praktische aanbeveling per scenario

De toekomst: post-quantum encryptie

Een onderwerp dat steeds urgenter wordt: quantumcomputers. De huidige asymmetrische encryptie (RSA, ECC) die zowel S/MIME als PGP gebruiken, is theoretisch kwetsbaar voor een voldoende krachtige quantumcomputer.

NIST heeft in 2024 de eerste post-quantum standaarden gepubliceerd (ML-KEM, ML-DSA). Google en Apple experimenteren al met hybride encryptie die klassieke en post-quantum algoritmen combineert. Voor e-mail is de transitie nog ver weg, maar het is verstandig om:

1. Inventariseer welke e-mails langdurig vertrouwelijk moeten blijven (>10 jaar)
2. Monitor de adoptie van post-quantum TLS (PQ-TLS)
3. Overweeg hybride encryptie voor zeer gevoelige communicatie

Hoe MailBelly hiermee omgaat

Bij MailBelly nemen we encryptie serieus op elke laag:

• TLS 1.3 is standaard voor alle SMTP-verbindingen, met automatische MTA-STS-configuratie
• DANE-ondersteuning voor domeinen met DNSSEC
• S/MIME-integratie is beschikbaar voor zakelijke accounts — we beheren certificaten centraal zodat je team geen individueel certificaatbeheer hoeft te doen
• Zero-access encryption voor opgeslagen e-mails: zelfs wij kunnen je berichten niet lezen
• TLS-RPT monitoring: we waarschuwen je automatisch als er TLS-problemen zijn met je uitgaande mail

E-mailbeveiliging is geen optie meer — het is een vereiste. Met de juiste configuratie hoeft het geen hoofdpijn te zijn.