# TLS-rapportage instellen voor e-mailinzicht [[TOC]] Je hebt MTA-STS ingesteld om versleutelde aflevering af te dwingen, maar hoe weet je of het werkt? En hoe weet je of er problemen zijn voordat je naar enforce gaat? TLS-rapportage geeft het antwoord. Verzendende servers sturen je dagelijks een rapport over hun versleutelpogingen naar jouw domein. Het is het venster waardoor je je e-mailversleuteling in de praktijk ziet. ## Wat TLS-rapportage doet TLS-rapportage, afgekort TLS-RPT en vastgelegd in RFC 8460, is een standaard waarmee verzendende servers je dagelijks rapporteren over de TLS-verbindingen die ze naar jouw mailservers opzetten. Lukte de versleuteling, of mislukte die, en zo ja waarom? Je publiceert een klein DNS-record met een adres waar de rapporten heen moeten. Vanaf dan ontvang je geaggregeerde rapporten van providers zoals Gmail die jouw domein mail sturen. Google is doorgaans de eerste provider die rapporteert en verstuurt zijn rapporten vanaf `noreply-smtp-tls-reporting@google.com`, meestal binnen 24 tot 48 uur na publicatie van je record. :::info title="TLS-RPT en MTA-STS horen bij elkaar" MTA-STS dwingt versleuteling af, TLS-rapportage vertelt je of dat lukt. Je stelt ze het beste samen in. Zonder rapportage stel je MTA-STS blind in en merk je problemen pas als mail bounct. Met rapportage zie je problemen aankomen. ::: ## Het record publiceren Het instellen is eenvoudig: een enkel TXT-record op een specifiek subdomein dat naar je rapportadres verwijst. Het record komt op `_smtp._tls.jouwdomein.nl` en bevat de versie `v=TLSRPTv1` plus een `rua`-adres. Dat adres mag een mailbox zijn (`mailto:`) of een HTTPS-endpoint (`https:`) van een verwerkingsdienst. Een typisch record ziet er zo uit: ``` _smtp._tls.jouwdomein.nl. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@jouwdomein.nl" ``` Wil je rapporten naar zowel een mailbox als een dienst sturen, scheid de adressen dan met een komma: ``` "v=TLSRPTv1; rua=mailto:tlsrpt@jouwdomein.nl,https://tlsrpt.dienst.nl/v1" ``` :::howto title="Zo publiceer je het record" 1. Bepaal waar de rapporten heen moeten: een mailbox of een TLS-RPT-verwerkingsdienst. 2. Maak een TXT-record aan op de hostnaam `_smtp._tls` binnen je domein. 3. Zet als waarde `v=TLSRPTv1; rua=` gevolgd door je `mailto:`- of `https:`-adres. 4. Publiceer het record in je DNS-zone (TLS-RPT stel je niet in de Admin-console in, maar bij je DNS-provider). 5. Wacht 24 tot 48 uur tot verzendende servers het oppikken en de eerste rapporten sturen. 6. Verwerk de rapporten met een tool, want ze komen in een machineleesbaar formaat. ::: ## De rapporten lezen De rapporten komen in een gestructureerd JSON-formaat, gecomprimeerd met gzip, dat lastig met het blote oog te lezen is. Een verwerkingsdienst zet ze om in begrijpelijke overzichten. Je ziet hoeveel verbindingen succesvol versleuteld waren en hoeveel mislukten, met de reden. | Categorie | Wat het betekent | |-----------|------------------| | Succesvol | Verbindingen die correct over TLS verliepen. Dit wil je zo hoog mogelijk hebben, idealiter honderd procent. | | Mislukt | Verbindingen waar versleuteling faalde. Elke mislukking is een potentieel afgeluisterd of in enforce geblokkeerd bericht. | | Oorzaak | De rapporten vermelden waarom het mislukte, zoals een certificaatprobleem of een policy-mismatch. | ## Het nut bij MTA-STS-uitrol Het grootste nut van TLS-rapportage is tijdens de uitrol van MTA-STS. In testmodus blokkeert MTA-STS nog niets, maar de rapporten tonen wel welke verbindingen in enforce-modus zouden falen. Zo zie je precies welke problemen je moet oplossen voordat je de knop omzet. :::warn title="Ga niet te vroeg naar enforce" Stap niet over op MTA-STS enforce zolang je TLS-rapporten nog mislukkingen tonen. Elke mislukking in de rapporten is een verbinding die in enforce-modus geweigerd zou worden, en dat betekent verloren inkomende mail. Wacht tot de rapporten consistent schoon zijn, of los anders eerst de gerapporteerde oorzaken op. ::: ## Doorlopend monitoren Ook na een succesvolle MTA-STS-uitrol blijft TLS-rapportage waardevol. Het signaleert nieuwe problemen, zoals een verlopen certificaat of een verzendende provider die plots faalt. Een wekelijkse blik op je rapporten houdt je e-mailversleuteling gezond. :::tip title="Gebruik een verwerkingsdienst, geen postvak" Gebruik een gespecialiseerde TLS-RPT-verwerkingsdienst in plaats van de ruwe JSON-rapporten in een postvak te laten oplopen. Zo'n dienst aggregeert de rapporten, signaleert trends en waarschuwt bij een plotselinge stijging van mislukkingen. Handmatig JSON ontleden is foutgevoelig en je mist subtiele patronen. ::: :::faq ### Heb ik TLS-rapportage nodig zonder MTA-STS? Het kan los, maar het meeste nut komt in combinatie met MTA-STS. Zonder MTA-STS krijg je nog steeds inzicht in mislukte versleutelde verbindingen, maar je hebt geen beleid dat erop afdwingt. ### In welk formaat komen de rapporten? In gestructureerde JSON volgens RFC 8460, gecomprimeerd met gzip. Verwerk ze met een tool of dienst in plaats van met de hand. ### Stuurt Gmail TLS-rapporten? Ja. Google verstuurt rapporten naar domeinen met een geldig TLS-RPT-record, vanaf `noreply-smtp-tls-reporting@google.com`, en is meestal de eerste provider die rapporteert. ### Hoe vaak komen de rapporten? Doorgaans eenmaal per dag, geaggregeerd per verzendende provider. ### Stel ik TLS-RPT in de Google Admin-console in? Nee. Het is een DNS-record dat je bij je DNS-provider plaatst op `_smtp._tls.jouwdomein.nl`. De Admin-console heeft het niet nodig. ### Hoelang duurt het voor ik mijn eerste rapport zie? Reken op 24 tot 48 uur na publicatie van het record, omdat verzendende servers het DNS-record eerst moeten oppikken. ::: TLS-rapportage is het meetinstrument voor je e-mailversleuteling. Het kost weinig moeite om in te stellen, maar geeft onmisbaar inzicht, vooral tijdens een MTA-STS-uitrol. Publiceer het record, verwerk de rapporten met een goede tool en stap pas over op enforce als de rapporten schoon zijn. Dan stel je versleuteling in met je ogen open in plaats van blind.