De TLS-RPT-recordchecker
Gratis TLS-RPT-controletool – controleer direct het SMTP TLS Reporting DNS-record van je domein, toets het aan RFC 8460, kijk of het overeenkomt met je MTA-STS-beleid en controleer of je rapportageadressen daadwerkelijk rapporten kunnen ontvangen.
Google
  • Google
  • Cloudflare
  • OpenDNS
  • Quad9
Voer een hoofddomein in – we halen automatisch het TXT-record op bij _smtp._tls, valideren dit en controleren je MTA-STS-koppeling.

Waarom moet je je TLS-RPT-record controleren?

Zelfs een correct geconfigureerde e-mailserver kan er onopgemerkt niet in slagen om berichten via TLS af te leveren. Een TLS-RPT-record is de enige manier om erachter te komen wanneer dat gebeurt.

TLS-fouten vroegtijdig opsporen
Zie precies wanneer verzendende mailservers geen versleutelde verbinding met uw domein tot stand kunnen brengen, voordat dit tot een bezorgingsprobleem leidt.
Controleer of je MTA-STS-configuratie correct is
TLS-RPT signaleert eventuele beleids- of verbindingsfouten die worden veroorzaakt door de afdwinging van MTA-STS – deze tool leest je actuele MTA-STS-beleid, zodat je de koppeling kunt zien.
Bevestig dat er rapporten kunnen binnenkomen
Een rapportageadres heeft geen zin als de post er niet kan worden bezorgd. We controleren of elke RUA-bestemming daadwerkelijk een adres heeft waar rapporten kunnen worden bezorgd.

Hoe gebruik je de TLS-RPT-checker?

Het uitvoeren van een TLS-RPT-opzoeking duurt slechts enkele seconden. Volg deze drie stappen om te controleren of uw SMTP TLS-rapportage correct is ingesteld.

1
Voer uw domeinnaam in. Voer je hoofddomein in (bijv. example.com) - het is niet nodig om de _smtp._tls voorvoegsel; dat regelen we automatisch.
2
Kies een resolver en controleer deze. Kies Google, Cloudflare, OpenDNS of Quad9 en druk vervolgens op Enter of klik op ‘Record controleren’ om de DNS-gegevens live vanaf onze server op te vragen.
3
Bekijk de resultaten. We controleren of de version- en rua-tags voldoen aan RFC 8460, inspecteren uw bijbehorende MTA-STS-beleid en verifiëren of elke rapportagedestination bereikbaar is.

Wat is een TLS-RPT-record?

SMTP TLS Reporting (TLS-RPT) is een e-mailstandaard die is vastgelegd in RFC 8460 en waarmee domeineigenaren rapporten kunnen ontvangen over fouten bij het bezorgen van e-mail via een versleutelde TLS-verbinding. Het werkt samen met MTA-STS om problemen aan het licht te brengen – zoals mislukte certificaatvalidatie, downgrade-aanvallen en niet-ondersteunde STARTTLS – die anders onopgemerkt zouden blijven.

Eén TXT-record
Gepubliceerd op _smtp._tls.yourdomain.com, hiermee wordt aan ontvangende mailservers aangegeven waar ze de geaggregeerde rapporten over TLS-verbindingspogingen naartoe moeten sturen.
Verslaglegging, geen handhaving
TLS-RPT blokkeert of dwingt zelf niets af. Het is puur een feedbackkanaal – de zichtbaarheidslaag die samenwerkt met MTA-STS.
Gratis en zonder veel moeite
Twee tags zijn voldoende. Het is niet verplicht, maar het is een aanbevolen werkwijze die niets kost en een echte blinde vlek wegneemt.
_smtp._tls.uwdomein.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
; v -> geeft aan dat het record een TLS-RPT is (RFC 8460)
; rua -> waar de geaggregeerde TLS-rapporten naartoe worden gestuurd

TLS-RPT versus MTA-STS: wat is het verschil?

MTA-STS (Mail Transfer Agent Strict Transport Security) is een handhavingsmechanisme: het geeft verzendende mailservers door dat uw domein een geldige, met TLS versleutelde verbinding vereist, en blokkeert de bezorging via onversleutelde of verkeerd geconfigureerde verbindingen. TLS-RPT is een rapportagemechanisme – het dwingt zelf niets af, maar geeft verzendende servers door waar ze zowel succesvolle als mislukte TLS-verbindingspogingen moeten rapporteren, inclusief pogingen die worden veroorzaakt door uw MTA-STS-beleid.

Deze twee zijn ontworpen om samen te werken: MTA-STS dwingt versleuteling af, en TLS-RPT biedt je de feedbackloop om te weten of die afdwinging tot bezorgingsproblemen leidt. Daarom controleert deze checker ook je MTA-STS-beleid – zo kun je nagaan of beide kanten op één lijn liggen. Je kunt de afdwingingskant nader onderzoeken met onze MTA-STS-recordchecker.

Uitleg over TLS-RPT-tags

Elk TLS-RPT-record bestaat uit een klein aantal tags. Hieronder wordt uitgelegd wat ze betekenen.

v=
Versie (verplicht)

Geeft aan dat het record een TLS-RPT-record is. Dit moet de eerste tag zijn en moet altijd zijn ingesteld op TLSRPTv1.

rua=
URI van het geaggregeerde rapport (verplicht)

Waar de samengevoegde TLS-rapporten naartoe worden gestuurd. Ondersteunt een mailto: adres, een https:// eindpunt, of een door komma’s gescheiden lijst van beide.

Veelvoorkomende problemen met TLS-RPT en hoe je deze kunt oplossen

Hieronder volgt een overzicht van de meest voorkomende problemen bij een TLS-RPT-configuratie en wat de gevolgen daarvan zijn voor uw domein.

Geen record gevonden
Niets bij _smtp._tls
Er is geen TXT-record aanwezig bij de juiste host, waardoor je helemaal geen meldingen ontvangt over mislukte TLS-bezorgingen.
Plaats een TXT-record op _smtp._tls.jouwdomein.com met een geldige v= en rua= tag.
Onjuist geformatteerde v= tag
Niet herkend als TLS-RPT
Het record begint niet met v=TLSRPTv1, dus e-mailservers zullen het niet als een TLS-RPT-record behandelen.
Stel v=TLSRPTv1 in als de exacte, eerste tag in het record.
Ontbrekende of ongeldige rua=
De rapporten kunnen nergens heen
Er is geen bestemming voor rapporten gedefinieerd, of de mailto/https-URI is onjuist opgegeven, waardoor rapporten niet kunnen worden verzonden.
Voeg ten minste één geldige mailto: of https: URI toe en controleer of de ontvanger deze kan ontvangen.
Meerdere records
Meer dan één TLS-RPT-record
Twee of meer TLS-RPT-records op dezelfde host zijn volgens RFC 8460 niet toegestaan en kunnen validatiefouten veroorzaken.
Consolideer tot precies één TLS-RPT-record, waarbij alle bestemmingen in één rua-tag worden opgenomen.

Hoe u uw TLS-RPT-rapporten kunt lezen

Zodra je record live is, zullen de ontvangende mailservers periodieke geaggregeerde rapporten naar je RUA-bestemming gaan sturen. Dit is wat erin staat.

Details van het beleid
Het type beleid dat van kracht is (bijv. sts, no-policy-found) voor het verzendende domein waarop het rapport betrekking heeft.
Overzicht van aantallen
Het totale aantal geslaagde en mislukte pogingen tot het tot stand brengen van een TLS-verbinding tijdens de rapportageperiode, doorgaans een periode van 24 uur.
Details van de storing
Gecategoriseerde fouttypes – certificaat verlopen, hostnaam komt niet overeen, STARTTLS wordt niet ondersteund – met voorbeelden van bron-IP-adressen.

Ruwe JSON-rapporten zijn moeilijk te doorgronden wanneer het om grote hoeveelheden gaat, vooral als je ze van tientallen verschillende e-mailproviders ontvangt. Het platform van PowerDMARC zet TLS-RPT-rapporten automatisch om in een overzichtelijk dashboard, samen met je DMARC-, SPF- en MTA-STS-gegevens.

Hoe publiceer je een TLS-RPT-record?

Log in bij je DNS-provider en voeg een nieuw TXT-record toe met deze waarden.

Host / naam
_smtp._tls
Type
TXT
TTL
3600 (standaard)
Voortplanting
Tot 48 uur
Een waarde
v=TLSRPTv1; rua=mailto:[email protected]

Het kan tot 48 uur duren voordat DNS-wijzigingen volledig zijn doorgevoerd, hoewel de meeste providers de wijzigingen binnen enkele uren bijwerken. Zodra de wijzigingen van kracht zijn, kun je de bovenstaande controlefunctie gebruiken om te controleren of alles correct is gepubliceerd.

Veelgestelde Vragen

Is TLS-RPT hetzelfde als DMARC?
Nee. DMARC rapporteert over mislukte authenticatiepogingen (SPF/DKIM) bij berichten die vanaf uw domein worden verzonden. TLS-RPT rapporteert specifiek over mislukte pogingen om een versleutelde TLS-verbinding tot stand te brengen wanneer e-mail aan uw domein wordt afgeleverd. Het zijn complementaire, maar onafhankelijke standaarden.
Worden mijn domengegevens naar jullie servers verzonden?
Het domein dat je invoert, wordt naar onze server verzonden, die voor jou de DNS-opzoeking uitvoert via de openbare resolver die je kiest – dezelfde zoekopdracht die iedereen zou kunnen uitvoeren met een dig opdracht. We registreren of bewaren de domeinen die je controleert noch de weergegeven records niet.
Heb ik MTA-STS nodig om TLS-RPT te kunnen gebruiken?
Nee, TLS-RPT kan op zichzelf worden geïmplementeerd. Het is echter het meest waardevol in combinatie met MTA-STS, aangezien het eventuele verbindings- of beleidsfouten rapporteert die worden veroorzaakt door de handhaving van MTA-STS. Deze checker controleert ook uw MTA-STS-beleid, zodat u kunt zien in hoeverre de twee op elkaar aansluiten.
Is TLS-RPT verplicht?
Nee, TLS-RPT is optioneel en wordt door geen enkele grote e-mailprovider verplicht gesteld. Het is een gratis en eenvoudige manier om inzicht te krijgen in TLS-bezorgingsproblemen die anders onzichtbaar zouden blijven, en het wordt beschouwd als een best practice, net als DMARC, SPF, DKIM en MTA-STS.
Kan ik meerdere RUA-adressen gebruiken?
Ja. Je kunt meerdere bestemmingen opgeven, gescheiden door komma’s, waarbij je mailto:- en https:--URI’s kunt combineren – bijvoorbeeld rua=mailto:[email protected],https://reports.example.com/tlsrpt. Deze tool controleert elk adres en gaat na of de e-mailadressen daadwerkelijk e-mail kunnen ontvangen.
Kunnen rapporten naar een ander domein dan het mijne worden verzonden?
Ja. In tegenstelling tot DMARC definieert RFC 8460 geen autorisatierecord voor externe bestemmingen voor TLS-RPT, dus je kunt rua zonder extra DNS-configuratie naar een externe verwerker (zoals PowerDMARC) laten verwijzen. Deze tool markeert externe bestemmingen ter wille van de duidelijkheid, maar ze zijn volkomen geldig.
Waarom wordt mijn TLS-RPT-record weergegeven als 'niet gevonden'?
Ofwel is het record nog niet gepubliceerd, zijn de DNS-wijzigingen nog niet volledig doorgevoerd, of is het record bij de verkeerde host toegevoegd – het moet precies _smtp._tls.yourdomain.com, niet alleen yourdomain.com.
Kan ik voor rapporten een https-eindpunt gebruiken in plaats van e-mail?
Ja. RFC 8460 ondersteunt zowel „mailto:”- als „https:”-rapportage-URI’s. Een „https”-eindpunt moet HTTP POST-verzoeken accepteren waarin het rapport is opgenomen als een gzip-gecomprimeerde JSON-payload – dit wordt doorgaans gebruikt door grotere organisaties of platforms zoals PowerDMARC die rapporten automatisch verwerken.

Automatiseer uw e-mailverificatie

PowerDMARC houdt uw DMARC-, SPF-, DKIM-, BIMI-, MTA-STS- en TLS-RPT-records bij in één dashboard – en stuurt direct een melding zodra er iets misgaat.