Pourquoi surveiller les rapports TLS-RPT ?
La surveillance TLS-RPT rend visibles les échecs de chiffrement SMTP que votre serveur ne journalise jamais. C'est le seul canal défini par une norme (RFC 8460) où les émetteurs vous remontent ce qui a cassé côté transport. Sans elle, un email refusé pour cause de TLS ne laisse aucune trace chez le destinataire. Votre réputation glisse. Vos utilisateurs n'attendent rien parce qu'ils ignorent qu'un message existait.
Trois pannes reviennent dans presque tous les rapports.
Un certificat expiré sur le MX fait échouer la négociation chiffrée, et les émetteurs en mode strict rejettent le message au lieu de le livrer en clair. Une politique MTA-STS qui pointe vers un MX disparu produit le même résultat : connexion refusée, mail jamais arrivé. Et le pire reste le downgrade STARTTLS, quand un équipement réseau retire l'annonce STARTTLS du dialogue SMTP. Le courrier passe alors en clair. Personne ne le sait. Le rapport TLS-RPT, lui, le voit.
Comment configurer la surveillance TLS-RPT en 3 étapes
Étape 1 : Ajoutez votre domaine
Connectez-vous et ajoutez votre domaine. CaptainDNS fournit une adresse email de réception dédiée au moniteur, ainsi qu'une URL HTTPS alternative.
Étape 2 : Vérifiez la propriété du domaine
Ajoutez le TXT de vérification fourni par CaptainDNS pour prouver la propriété du domaine. La vérification du domaine et l'activation ne confirment pas la réception de rapports.
Étape 3 : Publiez l'enregistrement TLS-RPT
Consultez la configuration du moniteur pour publier le TXT _smtp._tls recommandé avec sa destination mailto. Vérifiez les destinataires conservés avant de remplacer un TXT existant. En cas d'erreur de lecture DNS, ajoutez seulement le fragment à rua= sans retirer les autres destinataires, ou réessayez pour obtenir la valeur complète.
Qu'est-ce que TLS-RPT ?
TLS-RPT (SMTP TLS Reporting), défini par la RFC 8460, permet aux émetteurs participants de signaler les résultats des connexions TLS. Le TXT indique la destination des rapports, sans garantir leur envoi.
Exemple d'enregistrement DNS :
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt-TOKEN@mailsrv1.captaindns.com"
Exemple illustratif uniquement : remplacez TOKEN par le jeton fourni dans la configuration de votre moniteur. Pour un TXT existant, utilisez la recommandation du moniteur afin de vérifier les destinataires à conserver. Le fragment mailto seul ne constitue pas un TXT complet.
Que contient un rapport TLS-RPT ?
Un rapport TLS-RPT est un document JSON qui agrège, sur une fenêtre de 24 heures, toutes les tentatives de connexion TLS d'un émetteur vers votre domaine. Il compte les sessions réussies et échouées, et détaille chaque échec par type. CaptainDNS décode ce JSON et l'affiche en clair.
| Champ | Description |
|---|---|
| Organisation émettrice | Le fournisseur de messagerie qui a envoyé le rapport |
| Période | Horodatages de début et fin de la fenêtre de rapport |
| Politiques appliquées | Politiques MTA-STS, DANE ou STARTTLS détectées |
| Sessions réussies | Nombre de connexions TLS établies avec succès |
| Sessions échouées | Nombre d'échecs de négociation TLS avec détails d'erreur |
Les 11 types d'échecs TLS-RPT (RFC 8460)
Le §4.3 de la RFC 8460 définit 11 valeurs de result-type, et la surveillance les remonte toutes. Certains expéditeurs émettent en plus starttls-not-offered, une variante hors RFC de starttls-not-supported : elle est traitée comme telle.
| Type d'échec | Description |
|---|---|
starttls-not-supported | Le serveur destinataire ne supporte pas STARTTLS |
certificate-expired | Le certificat TLS présenté par le MX est expiré |
certificate-host-mismatch | Le certificat ne correspond pas au nom d'hôte du MX |
certificate-not-trusted | La chaîne de certificats n'est pas approuvée par l'émetteur |
validation-failure | Échec de validation TLS générique |
tlsa-invalid | L'enregistrement DANE TLSA est invalide ou ne correspond pas |
dnssec-invalid | La chaîne DNSSEC nécessaire à DANE est cassée ou absente |
dane-required | DANE est requis mais n'a pas pu être validé |
sts-policy-fetch-error | Impossible de récupérer la politique MTA-STS (HTTPS ou DNS) |
sts-policy-invalid | La politique MTA-STS n'a pas pu être validée |
sts-webpki-invalid | L'hôte de la politique MTA-STS a un certificat Web PKI invalide |
TLS-RPT vs DMARC
| TLS-RPT | DMARC | |
|---|---|---|
| Protège | Le chiffrement du transport (SMTP TLS) | L'authentification de l'expéditeur (SPF/DKIM) |
| Rapporte | Les échecs de connexion TLS, les erreurs de certificat | Les échecs d'alignement d'authentification |
| RFC | RFC 8460 | RFC 7489 |
| Enregistrement DNS | _smtp._tls TXT | _dmarc TXT |
| Menaces détectées | Certificats expirés, suppression STARTTLS, erreurs DANE/MTA-STS | Usurpation, phishing, imitation de domaine |
Les deux protocoles sont complémentaires. Déployez le monitoring DMARC en parallèle de TLS-RPT pour une visibilité complète sur la sécurité email.
Qui envoie des rapports TLS-RPT ?
Les rapports proviennent des émetteurs qui prennent en charge TLS-RPT et tentent de livrer du courrier à votre domaine. Leur présence et leur fréquence dépendent du trafic et de la mise en œuvre de chaque émetteur. Publier le TXT ne garantit aucun rapport d'un fournisseur donné.
Cas d'usage concrets
La plupart des incidents TLS se résolvent en une heure quand on les voit, et durent des semaines quand on ne les voit pas. Voici deux pannes réelles que la surveillance TLS-RPT a mises au jour.
Incident 1 : Certificat expiré non détecté
Symptôme : Google et Microsoft signalent des échecs certificate-expired. Vos utilisateurs ne reçoivent plus d'emails de ces fournisseurs. Aucune erreur visible de leur côté.
Diagnostic : Le tableau de bord CaptainDNS affiche un pic d'échecs sur 24h. Tous pointent vers un certificat Let's Encrypt expiré sur le MX principal. Les émetteurs stricts ont rejeté les messages silencieusement.
Action : Renouvelez le certificat TLS sur le serveur mail. Les rapports suivants confirment la reprise des connexions chiffrées.
Incident 2 : Politique MTA-STS désynchronisée
Symptôme : Les rapports signalent des échecs sts-policy-invalid. La politique MTA-STS est publiée. Les emails sont quand même rejetés.
Diagnostic : La politique MTA-STS référence un serveur MX supprimé lors d'une migration. Les émetteurs en mode enforce rejettent la connexion. L'email n'arrive jamais. Aucun bounce ne parvient à l'expéditeur.
Action : Mettez à jour la politique MTA-STS avec les MX actuels. Incrémentez le id de version. Les rapports suivants valident la correction.
CaptainDNS analyse les rapports reçus sans serveur à gérer ni JSON à décoder. Leur envoi dépend des émetteurs et du trafic vers votre domaine.
FAQ - Questions fréquentes
Q : Qu'est-ce qu'un enregistrement TLS-RPT ?
R : Un enregistrement TLS-RPT est un enregistrement DNS TXT placé à _smtp._tls.votredomaine.com. Il contient une directive rua= qui indique aux serveurs émetteurs où envoyer les rapports d'échec TLS (RFC 8460). Sans cet enregistrement, aucun serveur ne vous signale ses erreurs de connexion vers votre domaine.
Q : La surveillance TLS-RPT de CaptainDNS est-elle gratuite ?
R : Le premier outil du compte est gratuit. Chaque domaine TLS-RPT compte pour un outil : 3 €/mois hors taxes ensuite. Pas de frais cachés, pas de période d'essai.
Q : Comment configurer mon domaine pour envoyer les rapports ici ?
R : Consultez la configuration du moniteur pour publier le TXT _smtp._tls recommandé avec sa destination mailto. Vérifiez les destinataires conservés avant de remplacer un TXT existant. En cas d'erreur de lecture DNS, ajoutez seulement le fragment à rua= sans retirer les autres destinataires, ou réessayez pour obtenir la valeur complète.
Q : Quels formats de rapports sont supportés ?
R : Nous acceptons les rapports TLS-RPT JSON définis par la RFC 8460, compressés avec gzip ou non, par email et par HTTPS POST. L'email est la destination recommandée ; HTTPS reste pris en charge.
Q : Comment fonctionne la vérification de domaine ?
R : Ajoutez le TXT de vérification fourni par CaptainDNS pour prouver la propriété du domaine. La vérification du domaine et l'activation ne confirment pas la réception de rapports.
Q : Ai-je besoin de MTA-STS pour utiliser TLS-RPT ?
R : Non, TLS-RPT fonctionne indépendamment. Cependant, combiner MTA-STS avec TLS-RPT est recommandé : MTA-STS impose le chiffrement, TLS-RPT vous informe quand les émetteurs ne peuvent pas s'y conformer.
Q : À quelle fréquence les rapports arrivent-ils ?
R : Les émetteurs qui prennent en charge TLS-RPT envoient généralement des rapports par période de 24 heures. La réception dépend de ces émetteurs et du trafic. Aucun délai de premier rapport n'est garanti ; les rapports reçus sont ensuite analysés dans le tableau de bord.
Q : Quels sont les risques sans TLS-RPT ?
R : Sans TLS-RPT, vous êtes aveugle. Les échecs TLS se produisent silencieusement : aucun bounce, aucune notification, aucun log accessible. Des jours ou des semaines peuvent passer avant que vous réalisiez que des emails de Google, Microsoft ou d'autres fournisseurs majeurs sont rejetés ou transmis en clair.
Q : Quels types d'échecs TLS-RPT signale-t-il ?
R : TLS-RPT couvre les 11 types d'échec définis par la RFC 8460 : starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid et sts-webpki-invalid. Chaque type indique un problème spécifique dans la chaîne de négociation TLS ou de validation de politique.
Q : Quelle est la différence entre TLS-RPT et DMARC ?
R : TLS-RPT et DMARC protègent des couches différentes. DMARC (RFC 7489) vérifie l'authentification de l'expéditeur via l'alignement SPF et DKIM, il combat l'usurpation et le phishing. TLS-RPT (RFC 8460) surveille le chiffrement du transport et signale les échecs de connexion TLS, les certificats expirés et les rétrogradations STARTTLS. Les deux sont essentiels.
Outils complémentaires
| Outil | Utilité |
|---|---|
| Vérification de syntaxe TLS-RPT | Valider la syntaxe d'un enregistrement TLS-RPT |
| Vérification d'enregistrement TLS-RPT | Vérifier l'enregistrement TLS-RPT DNS de votre domaine |
| Générateur TLS-RPT | Générer un enregistrement DNS TLS-RPT |
| Lecteur de rapports TLS-RPT | Analyser manuellement un rapport JSON TLS-RPT |
| Hébergement MTA-STS | Héberger votre politique MTA-STS (1er outil gratuit, puis 3 €/mois hors taxes) |
| Monitoring DMARC | Surveiller et analyser les rapports agrégés DMARC |
Ressources utiles
- RFC 8460 - SMTP TLS Reporting : Spécification officielle TLS-RPT
- RFC 8461 - MTA-STS : Standard complémentaire pour imposer le chiffrement SMTP
- Google : Configurer les rapports TLS : Guide Google Workspace pour TLS-RPT