Wat is TLS-rapportage? Hoe SMTP TLS-rapporten fouten bij de bezorging van e-mails opsporen
door
Laatst bijgewerkt:
6 leestijd: 6 minuten
De meeste SMTP-TLS-storingen vinden plaats zonder dat iemand het merkt. Een certificaat verloopt, een server biedt geen ondersteuning meer voor STARTTLS of een aanvaller dwingt een downgrade af, waardoor de e-mail ofwel onversleuteld wordt verzonden ofwel nooit aankomt, zonder dat er een melding wordt gegeven waarin wordt uitgelegd waarom. TLS-rapportage is bedoeld om die leemte op te vullen.
SMTP TLS Reporting (TLS-RPT), zoals gedefinieerd in RFC 8460, biedt domeineigenaren een gestandaardiseerde manier om te achterhalen wanneer TLS-versleuteling tussen mailservers mislukt, en waarom. In dit artikel wordt uitgelegd hoe SMTP TLS werkt, waarom het kan mislukken, hoe een echt TLS-RPT-rapport er veld voor veld uitziet, en welke specifieke soorten fouten je tegenkomt zodra je ze gaat lezen.
Wat is SMTP TLS en waarom werkt het niet?
Om te begrijpen waarom TLS-rapportage belangrijk is, is het nuttig om te weten waarom SMTP dit überhaupt nodig had.
SMTP is niet ontworpen met het oog op versleuteling
SMTP dateert uit 1982. In die tijd was e-mail nog een klein, vertrouwd netwerk en werd het protocol ontworpen zonder versleutelingslaag. Berichten werden standaard in leesbare tekst tussen servers verzonden.
Die leemte bleef decennialang bestaan. Versleuteling werd pas later toegevoegd, als optie in plaats van als vereiste, en daar begint het volgende probleem.
STARTTLS maakte versleuteling optioneel, niet gegarandeerd
Met STARTTLS kan een verzendende server een ontvangende server vragen om een verbinding in leesbare tekst om te zetten naar een versleutelde verbinding. Als beide partijen dit ondersteunen, wordt het bericht versleuteld verzonden. Als een van beide partijen dit niet ondersteunt, of als er iets de handshake verstoort, schakelt de verbinding stilzwijgend terug naar leesbare tekst en wordt de e-mail toch verzonden.
Die terugvaloptie is het kernprobleem dat TLS-RPT juist aan het licht moest brengen. Niets in de SMTP-standaard geeft aan wanneer een bericht onversleuteld is verzonden, of dat nu het gevolg was van een verkeerde configuratie of omdat iemand het STARTTLS-commando tijdens de overdracht bewust heeft verwijderd.
Wat is TLS-rapportage (TLS-RPT)?
TLS-RPT is een rapportagestandaard, gedefinieerd in RFC 8460, waarmee domeineigenaren regelmatig gestructureerde rapporten kunnen ontvangen over mislukte TLS-verbindingen bij e-mails die naar hun domein worden verzonden. Het voorkomt niet dat er storingen optreden. Het laat je wel weten wanneer ze zich hebben voorgedaan, hoe vaak en waarom, zodat je het onderliggende probleem kunt verhelpen.
Raadpleeg onze uitgebreide handleiding over TLS-RPT voor een volledig overzicht van de rapportvelden van RFC 8460 en voor informatie over het publiceren van een TLS-RPT-DNS-record.
Hoe TLS-RPT zich verhoudt tot MTA-STS
TLS-RPT en MTA-STS werken als een duo. MTA-STS is het handhavingsmechanisme: het geeft verzendende servers door dat e-mail naar jouw domein via een versleutelde, geauthenticeerde verbinding moet verlopen, of helemaal niet. TLS-RPT is het rapportagemechanisme: het rapporteert wat er is gebeurd wanneer die versleutelde verbinding niet tot stand kon worden gebracht. Het ene stelt de regel vast, het andere laat je weten wanneer de regel in werking treedt.
Voor gedetailleerde instructies over het configureren van MTA-STS voor uw domein kunt u onze implementatiehandleiding voor MTA-STS raadplegen.
Hoe SMTP TLS-rapportage werkt, stap voor stap
- De domeineigenaar publiceert een TLS-RPT-DNS-record, waarmee aan verzendende mailservers wordt aangegeven waar ze foutmeldingen naartoe moeten sturen.
- Een verzendende server probeert e-mail te bezorgen via TLS, meestal via STARTTLS.
- Als die poging mislukt, registreert de verzendende server de reden voor de mislukking.
- Ongeveer eens per 24 uur bundelt de verzendende server deze resultaten in een JSON-rapport en verstuurt dit, meestal via e-mail of een HTTPS POST-verzoek, naar het adres dat is opgegeven in het TLS-RPT-record van het domein.
- De domeineigenaar opent het rapport en zoekt naar patronen: welke servers vertonen storingen, hoe vaak en waarom.
Een kijkje in een echt TLS-RPT-rapport
TLS-RPT-rapporten worden in JSON-formaat geleverd, wat niet bepaald voor mensen leesbaar is. Hieronder volgt een ingekort, realistisch voorbeeld op basis van het RFC 8460-formaat, met een overzicht van een geslaagde en een mislukte sessie, gevolgd door een uitleg in gewoon Engels van elk veld.
JSON
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2026-07-01T00:00:00Z",
"end-datetime": "2026-07-01T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "[email protected]",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: enforce",
"mx: mail.yourdomain.com",
"max_age: 604800"
],
"policy-domain": "yourdomain.com"
},
"summary": {
"total-successful-session-count": 4821,
"total-failure-session-count": 3
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail.yourdomain.com",
"receiving-mx-helo": "mail.yourdomain.com",
"receiving-ip": "203.0.113.45",
"failed-session-count": 2,
"additional-information": "https://support.google.com/mail/answer/tls-rpt-cert-expired"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail2.yourdomain.com",
"receiving-ip": "203.0.113.46",
"failed-session-count": 1
}
}
}
]
}
Wat elk veld precies betekent
- naam-van-de-organisatie: Wie heeft het rapport verzonden? Meestal een grote e-mailprovider zoals Google, Microsoft of Yahoo.
- periode: De periode waarop het rapport betrekking heeft. De meeste verzenders brengen op basis van een voortschrijdend 24-uursinterval verslag uit.
- contactgegevens / rapport-id: Hoe u de afzender kunt bereiken, en een uniek ID voor dit specifieke rapport. Handig als u in een supportticket naar het rapport moet verwijzen.
- policy-type / policy-string: Het MTA-STS- (of DANE-)beleid dat de verzendende server op dat moment voor uw domein heeft waargenomen, precies weergegeven zoals het is opgehaald. Zo kunt u controleren of uw gepubliceerde beleid overeenkomt met wat afzenders daadwerkelijk ontvangen.
- aantal-succesvolle-sessies / aantal-mislukte-sessies: Het belangrijkste cijfer. In dit voorbeeld waren 4.821 van de 4.824 bezorgpogingen succesvol en mislukten er 3.
- failure-details: Eén vermelding per type fout, met een aantal. Dit is het deel waarop actie moet worden ondernomen:
– certificate-expired: Het TLS-certificaat was bij 2 van de mislukte sessies verlopen. Oplossing: het certificaat vernieuwen en opnieuw installeren.
– starttls-not-supported: De ontvangende server (mail2.yourdomain.com) reageerde bij 1 sessie helemaal niet op STARTTLS. Oplossing: controleer de TLS-configuratie van de server, aangezien deze mogelijk ontbreekt of verkeerd is geconfigureerd.
Veelvoorkomende soorten TLS-fouten die je in rapporten tegenkomt
TLS-RPT-rapporten maken gebruik van een vaste reeks waarden voor het resultaattype. Hieronder staan de waarden die het vaakst voorkomen, wat ze betekenen en wat u ermee kunt doen.
Certificaat is verlopen
Het TLS-certificaat van de ontvangende server was verlopen. Vernieuw het certificaat voordat het verloopt en stel ruim voor de volgende vervaldatum een herinnering in.
Naam van het certificaat komt niet overeen
Het getoonde certificaat komt niet overeen met de hostnaam die de verzendende server verwachtte. Dit duidt meestal op een verkeerd geconfigureerd certificaat of een DNS-record dat naar de verkeerde host verwijst.
STARTTLS wordt niet ondersteund
De ontvangende server reageerde helemaal niet op het STARTTLS-commando. Controleer of TLS correct is ingeschakeld op die mailserver en ga na of de serversoftware dit ook daadwerkelijk ondersteunt.
Fout bij het ophalen van het MTA-STS-beleid
De verzendende server kon uw MTA-STS-beleidsbestand niet via HTTPS ophalen. Controleer of het beleidsbestand bereikbaar is, de juiste indeling heeft en wordt aangeboden met een geldig certificaat.
TLS-versie te oud
Er is geprobeerd een TLS-versie af te spreken die door de verzendende server als verouderd of onveilig wordt beschouwd. Pas de TLS-configuratie van uw mailserver aan om verouderde protocolversies uit te schakelen. Raadpleeg voor specifieke validatieproblemen met certificaten onze handleiding over DANE.
Waarom rapportage over SMTP TLS belangrijk is
SMTP TLS-rapportage biedt tal van voordelen. Hieronder volgen enkele daarvan:
Beveiliging: Downgrade-aanvallen detecteren
TLS-RPT brengt gevallen aan het licht waarin een verbinding gedwongen werd om via een onversleuteld kanaal te lopen, wat precies het patroon is dat ten grondslag ligt aan een MITM-downgrade-aanval. Zonder melding kan dat soort onderschepping eindeloos doorgaan zonder dat iemand het doorheeft.
Zichtbaarheid: blinde vlekken elimineren
Zonder TLS-RPT is er geen betrouwbare manier om te achterhalen waarom e-mails naar uw domein zijn mislukt, of dat ze zonder versleuteling zijn afgeleverd. De rapporten laten precies zien waar en waarom een TLS-verbinding is verbroken, zodat u niet in het duister hoeft te tasten.
Efficiëntie: sneller problemen oplossen
Het doorlezen van serverlogs om een leveringsprobleem op te sporen kost tijd. TLS-RPT-rapporten wijzen direct op de defecte server, het type storing en hoe vaak deze zich heeft voorgedaan, waardoor het oplossen van het probleem van dagen tot minuten wordt teruggebracht.
Afsluitende opmerkingen: Hoe PowerDMARC de TLS-rapportage vereenvoudigt
TLS-RPT-rapporten worden geleverd als onbewerkte JSON-bestanden, en het handmatig doorlezen ervan voor meerdere verzendbronnen wordt al snel vervelend. PowerDMARC zet deze rapporten automatisch om in overzichtelijke dashboards, gegroepeerd per resultaattype en per verzendbron, zodat je kunt zien wat er misgaat en waar, zonder ook maar één JSON-bestand te hoeven openen.
Wij helpen domeineigenaren:
- Zet onbewerkte JSON automatisch om in overzichtelijke dashboards, zonder dat handmatige decodering van TLS-RPT-rapportbestanden nodig is.
- Filter op basis van twee rapportweergaven: per verzendbron (beleidsmodus, aantal sessies, totale bezorgcijfers) en per resultaat (succesvolle sessies bovenaan, mislukkingen onderaan).
- Drilldown-fouten om een mislukte sessie uit te vouwen en de hostnaam, het IP-adres, het aantal fouten en de oorzaak van de ontvangende server te bekijken, zodat de oplossing in één oogopslag duidelijk is.
- Upload JSON-, ZIP- of GZ-bestanden met een uploadgeschiedenis, zodat eerdere rapporten op elk moment opnieuw kunnen worden bekeken.
- Genereer en valideer automatisch de CNAME-records die nodig zijn om rapporten te ontvangen via DNS-configuratie met één muisklik, plus een instelbaar adres waarnaar de samengevoegde rapporten worden verzonden.
- Exporteer onbewerkte JSON-bestanden wanneer je het originele bestand nodig hebt voor een ticket of om het verder uit te zoeken, waarbij gedetailleerde machtigingen bepalen wie binnen het account rapporten mag uploaden.
Start een gratis proefperiode of boek een demo om het te bekijken aan de hand van de gegevens van uw eigen domein.
Veelgestelde Vragen
1. Waarvoor wordt TLS-rapportage gebruikt?
TLS-rapporten worden gebruikt om storingen bij de bezorging van versleutelde e-mail op te sporen en te analyseren, waaronder verlopen certificaten, verkeerd geconfigureerde servers en downgrade-aanvallen, door regelmatig rapporten te genereren over wat er mis is gegaan en waarom.
2. Is SMTP TLS-rapportage hetzelfde als TLS-RPT?
Ja. „SMTP TLS-rapportage” en „TLS-RPT” verwijzen naar dezelfde RFC 8460-standaard. TLS-RPT is de afkorting voor het protocol.
3. Hoe stel ik TLS-rapportage in voor mijn domein?
Om dit voor uw domein in te stellen, hoeft u alleen maar een TLS-RPT-DNS-record te publiceren waarin u aangeeft waar de rapporten naartoe moeten worden gestuurd. U kunt er een genereren met onze TLS-RPT-recordgenerator en controleren of het actief is met onze TLS-RPT-checker.
4. Wat gebeurt er als ik TLS-RPT niet inschakel?
Als u TLS-RPT niet inschakelt, zullen mailservers nog steeds zelfstandig proberen TLS-versleuteling toe te passen, maar krijgt u geen inzicht in eventuele storingen. Downgrade-aanvallen, verlopen certificaten en verkeerd geconfigureerde servers kunnen daardoor voor onbepaalde tijd onopgemerkt blijven.
5. Werkt TLS-RPT zonder MTA-STS?
Ja, TLS-RPT kan zelfstandig melding maken van TLS-storingen. Maar het is het nuttigst in combinatie met MTA-STS, aangezien MTA-STS versleutelde verzending afdwingt en TLS-RPT rapporteert wat er gebeurde toen die afdwinging in werking trad.
6. Hoe vaak worden SMTP TLS-rapporten verzonden?
De meeste verzenders genereren en versturen rapporten ongeveer eens per 24 uur, hoewel het exacte interval per aanbieder kan verschillen.
Expert domein- en e-mailbeveiliging bij PowerDMARC
Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.
Laatste berichten van Ahona Rudra (Bekijk alle berichten)
- Wat is TLS-rapportage? Hoe SMTP TLS-rapporten fouten bij de bezorging van e-mails opsporen - 9 juli 2026
- De beste DMARC MCP-servers in 2026: koppel AI aan uw e-mailauthenticatiegegevens - 9 juli 2026
- DMARC MSP-casestudy: The Great Geek breidt e-mailbeveiligingsdiensten voor het MKB uit met PowerDMARC - 25 juni 2026
