Wat TLS doet en wanneer het ontbreekt
TLS (Transport Layer Security) versleutelt de verbinding tussen twee mailservers tijdens de overdracht. Zonder TLS reist e-mail als plaintext over het internet: iedereen die het netwerkverkeer onderschept, kan de inhoud lezen.
Google Workspace gebruikt standaard opportunistic TLS. Dat betekent: biedt de ontvangende server TLS aan, dan gebruikt Google het. Accepteert de server alleen plaintext, dan stuurt Google het bericht toch, maar onversleuteld.
Opportunistic TLS is onvoldoende voor gevoelige communicatie. Via een zogenoemde downgrade attack kan een aanvaller de TLS-handshake verstoren zodat beide servers terugvallen op plaintext. Voor gegarandeerde versleuteling configureer je een expliciet TLS-beleid dat verbindingen zonder TLS weigert.
TLS afdwingen in de Admin-console
In de Admin-console regel je verplichte TLS per domein of e-mailadres. Google noemt deze instelling Beveiligd transport (TLS).
TLS-verplichting instellen per domein
- Ga naar Admin-console > Apps > Google Workspace > Gmail > Naleving.
- Ga naar Beveiligd transport (TLS) en klik op Configureren. Bestaat er al een instelling, klik dan op Nog een toevoegen.
- Geef de instelling een herkenbare naam, bijvoorbeeld
TLS verplicht partner.nl. - Bij E-mailberichten die moeten worden beïnvloed kies je de richting: Inkomend, Uitgaand of beide.
- Voeg een Afzender/ontvanger-voorwaarde toe en vul het domein in waarvoor TLS verplicht is, bijvoorbeeld
partner.nl. - Vink Een veilige verbinding (TLS) vereisen aan.
- Optioneel: vink ook Een door een CA ondertekend certificaat vereisen en De hostnaam van het certificaat valideren aan om het certificaat van de externe server te controleren.
- Klik op Opslaan. Wijzigingen zijn meestal binnen enkele minuten actief, maar Google rekent tot 24 uur.
Voor een organisatiebrede TLS-verplichting laat je de domeinvoorwaarde leeg of stel je een voorwaarde in die op alle ontvangers matcht. Wees daar voorzichtig mee: zie de waarschuwing hieronder.
Niet meteen organisatiebreed afdwingen
Begin met een TLS-verplichting voor domeinen waarmee je gevoelige gegevens uitwisselt, zoals juridische partners, accountants of zorgpartners. Een directe organisatiebrede verplichting kan ertoe leiden dat berichten naar kleine bedrijven worden gebounced omdat hun mailserver geen of een verkeerd geconfigureerde TLS heeft. Breid de scope pas uit nadat je via de logs hebt gezien dat het verkeer schoon verloopt.
MTA-STS als bescherming voor inkomend verkeer
TLS-afdwinging via de Admin-console regelt vooral hoe Google jouw uitgaande post behandelt. Maar hoe zorg je dat externe afzenders post naar jouw domein ook altijd via TLS aanleveren? Daarvoor gebruik je MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461).
MTA-STS publiceert een beleidsbestand via HTTPS plus een DNS-record. Samen vertellen ze externe servers: berichten voor dit domein moeten via een geverifieerde TLS-verbinding bezorgd worden. Lukt dat niet, dan weigert de verzendende server de bezorging.
Start altijd in testmodus
Zet het beleid eerst op mode: testing en houd dat minimaal twee weken aan. In testmodus blokkeert MTA-STS niets, maar je ontvangt wel TLS-rapporten waarmee je problemen opspoort. Zet pas daarna mode: enforce. Schakel je te vroeg over op enforce met een fout in je MX-lijst, dan blokkeer je in één klap alle inkomende e-mail.
MTA-STS opzetten in drie stappen
- Maak het beleidsbestand
mta-sts.txtaan en host het exact ophttps://mta-sts.joudomein.nl/.well-known/mta-sts.txt(HTTPS met een geldig certificaat is verplicht). - Voeg het MTA-STS DNS-record toe als TXT-record op
_mta-sts.joudomein.nl. - Voeg optioneel een TLS-RPT-record toe zodat externe servers rapporteren over mislukte TLS-verbindingen.
Voorbeeld van een beleidsbestand voor Google Workspace. Gebruik de wildcard-patronen die alle Google-MX-servers dekken:
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.google.com
mx: *.googlemail.com
max_age: 86400
Het bijbehorende DNS-TXT-record:
_mta-sts.joudomein.nl TXT "v=STSv1; id=20260601000000"
Het id-veld is een versie-identifier. Verhoog het elke keer dat je het beleidsbestand wijzigt, zodat externe servers hun gecachte beleid vernieuwen. Een tijdstempel als waarde werkt prettig.
Het optionele TLS-RPT-record voor rapportage:
_smtp._tls.joudomein.nl TXT "v=TLSRPTv1; rua=mailto:tls-rpt@joudomein.nl"
Wil je rapporten zien zonder zelf een mailbox te beheren, dan kun je MTA-STS en TLS-rapportage ook centraal aanzetten in de Admin-console onder dezelfde Naleving-instellingen.
TLS-status controleren
Na het instellen controleer je of TLS daadwerkelijk gebruikt wordt.
- Postmaster Tools: open
postmaster.google.com, kies je domein en bekijk het TLS-dashboard. Je ziet welk percentage inkomende en uitgaande berichten via TLS verliep. - E-maillogboek: zoek in de Admin-console onder Rapporten > E-maillogboek op een bericht en bekijk de details. Bij verzonden en ontvangen post staat of de verbinding versleuteld was.
- TLS-rapporten (TLS-RPT): de aggregaatrapporten die je via het TLS-RPT-record ontvangt, tonen of externe servers TLS naar jouw domein konden opzetten.
Toets je MTA-STS-beleid extern
Voordat je naar enforce schakelt, controleer je het beleidsbestand en de DNS-records met een onafhankelijke MTA-STS-validator. Zo weet je zeker dat het bestand bereikbaar is, het certificaat klopt en je MX-lijst volledig is. Pas als de validatie schoon is en de testrapporten geen fouten tonen, zet je mode op enforce.
Wat als een partnerdomein geen TLS ondersteunt
Stel je TLS verplicht voor een domein en de ontvangende server ondersteunt geen geschikte TLS, dan bounced het bericht met een NDR (non-delivery report). De afzender krijgt een foutmelding terug.
Je hebt dan deze opties:
- Informeer de partner en vraag hen TLS in te schakelen op hun mailserver. Vrijwel elke moderne mailserver ondersteunt TLS; het is doorgaans een configuratiekwestie.
- Zet de TLS-verplichting voor dat specifieke domein tijdelijk uit terwijl de partner het oplost.
- Gebruik een beveiligd portaal als blijvend alternatief voor partners die TLS structureel niet aankunnen.
Welke TLS-versies gebruikt Google Workspace?
Voor uitgaand verkeer gebruikt Google bij voorkeur TLS 1.2 en 1.3. Voor inkomende interoperabiliteit accepteert Google ook nog oudere versies (TLS 1.0 en 1.1), maar die gelden als verouderd en onveilig. Met enforced TLS en certificaatvalidatie dwing je in de praktijk een moderne, veilige verbinding af.
Beschermt TLS de inhoud van mijn e-mail?
Nee, TLS beschermt alleen de overdracht tussen mailservers. Het versleutelt niet de opslag van het bericht op de server van de ontvanger en biedt geen end-to-end versleuteling. Wil je dat wel, dan gebruik je S/MIME of Google Workspace Client-side Encryption.
Moet ik zowel MTA-STS als TLS-afdwinging instellen?
Ze vullen elkaar aan. De Naleving-instelling Beveiligd transport stuurt vooral hoe Google jouw uitgaande post behandelt. MTA-STS dwingt externe afzenders die jouw domein mailen om TLS te gebruiken. Voor een volledig beleid zet je beide in.
Wat is het verschil tussen testmodus en enforce bij MTA-STS?
In testing blokkeert MTA-STS geen enkel bericht, maar verzamel je via TLS-rapporten inzicht in mislukte TLS-verbindingen. In enforce weigeren externe servers de bezorging als ze geen geverifieerde TLS kunnen opzetten. Draai eerst minimaal twee weken in testmodus.
Kan een verkeerd MTA-STS-beleid mijn e-mail blokkeren?
Ja. Staat je beleid op enforce en mist een geldige MX-server in de lijst, of is je certificaat verlopen, dan weigeren afzenders alle post naar jouw domein. Daarom test je eerst, valideer je het beleid extern en houd je het id bij elke wijziging actueel.