TLS-RPT : la visibilité sur les problèmes TLS des e-mails
TLS-RPT (SMTP TLS Reporting, RFC 8460) est un mécanisme qui permet aux serveurs de messagerie expéditeurs d'envoyer des rapports au domaine destinataire lorsqu'ils rencontrent des problèmes avec les connexions TLS. Ces problèmes peuvent être : des certificats expirés ou non valides, l'absence de prise en charge de STARTTLS, un échec de la négociation TLS, ou des violations de la politique MTA-STS ou DANE. Sans TLS-RPT, ces problèmes passent totalement inaperçus car les serveurs expéditeurs se rabattent généralement en silence sur des connexions non chiffrées.
La valeur de TLS-RPT réside dans la visibilité : il vous indique combien d'e-mails arrivent sur votre serveur via des connexions non chiffrées et pourquoi. C'est crucial pour la conformité réglementaire (le RGPD exige des mesures de sécurité adéquates pour les données personnelles) et pour la sécurité des communications d'entreprise. Un certificat expiré sur votre serveur de messagerie pourrait provoquer des centaines de connexions non chiffrées par jour sans que vous le sachiez.
Configuration de TLS-RPT
La configuration est simple : un unique enregistrement TXT sur _smtp._tls.votredomaine.com avec la version (v=TLSRPTv1) et l'adresse pour les rapports (rua=). Les rapports peuvent être reçus par e-mail (mailto:) ou sur un endpoint HTTPS (https://). Pour la plupart des organisations, l'option e-mail est plus simple à mettre en place. L'endpoint HTTPS est préférable pour les volumes élevés ou pour l'intégration avec des systèmes de surveillance automatisés.
Interpréter les rapports TLS-RPT
Les rapports TLS-RPT sont au format JSON et sont envoyés généralement toutes les 24 heures. Chaque rapport contient : le domaine expéditeur, la période couverte, le type de politique appliquée (MTA-STS, DANE ou aucune), et pour chaque politique un décompte des sessions réussies et échouées avec le type d'erreur. Les types d'erreur les plus courants sont : certificate-expired, certificate-not-trusted, starttls-not-supported et sts-policy-invalid.
Utilisez notre TLS-RPT Lookup pour vérifier que l'enregistrement est correctement configuré. Si le rapport affiche des erreurs de type certificate-expired, vérifiez le certificat de votre serveur de messagerie avec SSL Check. Pour les erreurs starttls-not-supported, vérifiez la configuration SMTP du serveur avec SMTP Diagnostics pour vous assurer que STARTTLS est activé et fonctionnel.
TLS-RPT dans le contexte de la sécurité e-mail
TLS-RPT est le complément naturel de MTA-STS : tandis que MTA-STS définit la politique de sécurité TLS, TLS-RPT fournit la surveillance. Mettre en œuvre MTA-STS sans TLS-RPT, c'est comme installer un système de sécurité sans notifications : cela fonctionne, mais vous ne savez pas quand il bloque quelque chose ni quand des problèmes surviennent. La combinaison des deux protocoles offre à la fois la protection et la visibilité nécessaires pour garantir que les e-mails en transit sont toujours chiffrés.
Pour un domaine doté d'une configuration e-mail complète et sécurisée, la liste de contrôle inclut : des enregistrements MX fonctionnels, un SPF valide, un DKIM actif, DMARC avec politique d'application, MTA-STS en mode enforce, et TLS-RPT pour la surveillance continue. Chaque protocole ajoute une couche de sécurité et de visibilité, et l'absence de l'un d'entre eux laisse une brèche dans la protection. TLS-RPT, bien qu'étant le dernier arrivé, est le protocole qui boucle la boucle en fournissant la télémétrie nécessaire pour maintenir tout le reste en bonne santé.
La mise en œuvre de TLS-RPT est l'une des plus simples de toute la pile de sécurité e-mail : un seul enregistrement DNS et une adresse e-mail dédiée. Il n'y a aucune raison de ne pas le configurer. Les rapports que vous recevrez pourront révéler des problèmes de sécurité dans la chaîne de livraison des e-mails dont vous n'aviez pas connaissance, vous permettant d'agir de manière proactive avant qu'ils ne deviennent critiques.