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 enregistrez le domaine à surveiller. CaptainDNS génère un endpoint de collecte HTTPS unique et l'enregistrement DNS TLS-RPT correspondant.
Étape 2 : Vérifiez la propriété du domaine
Ajoutez l'enregistrement TXT de vérification à votre DNS. La validation est automatique une fois l'enregistrement détecté.
Étape 3 : Publiez l'enregistrement TLS-RPT
Ajoutez l'enregistrement TXT _smtp._tls fourni à votre DNS. Les serveurs émetteurs commenceront à envoyer des rapports d'échec TLS à votre endpoint CaptainDNS.
Qu'est-ce que TLS-RPT ?
TLS-RPT (SMTP TLS Reporting) est un standard défini par la RFC 8460 qui fait remonter les échecs de négociation TLS au domaine destinataire. Les serveurs émetteurs signalent chaque connexion chiffrée qui échoue. Un seul enregistrement DNS suffit à les déclencher.
Exemple d'enregistrement DNS :
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"
L'enregistrement _smtp._tls indique aux émetteurs où envoyer leurs rapports JSON. Toute erreur TLS vers votre domaine déclenche un rapport à l'URL spécifiée dans rua=.
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 |
Types d'échecs TLS-RPT (RFC 8460)
| 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 |
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 |
tlsa-invalid | L'enregistrement DANE TLSA est invalide ou ne correspond pas |
dane-required | DANE est requis mais n'a pas pu être validé |
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 grands fournisseurs de messagerie émettent des rapports TLS-RPT dès qu'ils tentent une connexion TLS vers votre domaine. À eux seuls, Google et Microsoft acheminent la majorité du courrier entrant d'un domaine professionnel typique. Recevez-vous du mail de l'un d'eux? Alors un enregistrement TLS-RPT publié vous donne déjà une couverture utile.
- Google (Gmail, Workspace) : Rapports agrégés quotidiens couvrant toutes les tentatives de connexion
- Microsoft (Outlook, Exchange Online) : Signale les échecs de négociation TLS pour les tenants Microsoft 365
- Yahoo : Transmet les données TLS-RPT pour l'infrastructure Yahoo Mail et AOL
- Apple (iCloud Mail) : Rapporte les échecs TLS pour la livraison iCloud Mail
- Comcast : L'un des premiers FAI à implémenter les rapports TLS-RPT
Publiez un enregistrement TLS-RPT et ces fournisseurs commencent à rapporter automatiquement. Aucune inscription auprès de chaque fournisseur n'est nécessaire.
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.
Dans les deux cas, le déclencheur est le même: un rapport TLS-RPT lu au bon moment. Ajoutez votre domaine à CaptainDNS, publiez l'enregistrement _smtp._tls, et ces signaux arrivent dans votre tableau de bord sans serveur à gérer.
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 : Oui, le service de surveillance TLS-RPT est entièrement gratuit. Nous pensons que chaque domaine devrait pouvoir surveiller sa sécurité TLS sans contrainte technique.
Q : Comment configurer mon domaine pour envoyer les rapports ici ?
R : Ajoutez un enregistrement TXT à _smtp._tls.votredomaine.com avec la valeur v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{votre-token}. L'enregistrement exact est fourni quand vous ajoutez votre domaine.
Q : Quels formats de rapports sont supportés ?
R : Nous acceptons les rapports TLS-RPT au format JSON tel que défini par la RFC 8460, compressés (gzip) ou non. Les rapports sont acceptés via HTTPS POST.
Q : Comment fonctionne la vérification de domaine ?
R : Vous ajoutez un enregistrement TXT de vérification fourni par CaptainDNS à votre DNS. Une fois détecté, la propriété du domaine est confirmée et la surveillance des rapports est activée.
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 rapports sont analysés et disponibles dans votre tableau de bord en quelques secondes après réception. La plupart des fournisseurs de messagerie envoient des rapports quotidiennement.
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 tous les types d'échec définis par la RFC 8460 : starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid et dane-required. 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 gratuitement votre politique MTA-STS |
| 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