Pourquoi surveiller les rapports TLS-RPT ?
TLS-RPT (SMTP TLS Reporting, RFC 8460) est votre seule source de vérité sur les échecs TLS affectant votre courrier entrant. Sans TLS-RPT, les emails refusés ou dégradés vers du clair ne laissent aucune trace côté destinataire. Votre réputation de domaine se dégrade. Vos utilisateurs ne reçoivent rien. Vous ne voyez rien.
Trois problèmes courants détectés via TLS-RPT :
- Certificats expirés : Votre serveur MX présente un certificat TLS invalide ou expiré. Les connexions chiffrées échouent. Les emails n'arrivent pas.
- MTA-STS mal configuré : Votre politique MTA-STS référence des serveurs MX qui ne correspondent plus à votre infrastructure réelle. Les émetteurs stricts rejettent la connexion.
- Rétrogradation STARTTLS : Des intermédiaires réseau suppriment l'extension STARTTLS. Le courrier transite en clair à votre insu.
Comment configurer le monitoring TLS-RPT en 3 étapes
Étape 1 : Ajoutez votre domaine
Connectez-vous et enregistrez le domaine à surveiller. CaptainDNS génère un endpoint de reporting 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. Il permet aux serveurs de messagerie émetteurs de signaler les échecs de négociation TLS au domaine destinataire.
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 serveurs émetteurs où envoyer leurs rapports JSON lorsqu'une connexion TLS échoue vers votre domaine.
Que contient un rapport TLS-RPT ?
| 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 reporting |
| 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 |
Cas d'usage concrets
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.
Diagnostic : Le tableau de bord affiche un pic d'échecs sur 24h. Tous pointent vers un certificat Let's Encrypt expiré sur le MX principal.
Action : Renouvelez le certificat TLS immédiatement. Les rapports TLS-RPT 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. Votre 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.
Action : Mettez à jour la politique MTA-STS. Incrémentez le id de version. Les rapports suivants valident la correction.
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 : Quels risques si je n'ai pas de TLS-RPT ?
R : Sans TLS-RPT, vous êtes aveugle. Un certificat expiré bloque des emails pendant des jours avant que quelqu'un s'en aperçoive. Une politique MTA-STS mal configurée fait rejeter des connexions silencieusement. Vous découvrez le problème quand un utilisateur se plaint, trop tard.
Q : TLS-RPT et MTA-STS sont-ils liés ?
R : Complémentaires, pas interchangeables. MTA-STS impose le chiffrement SMTP. TLS-RPT vous informe quand des émetteurs ne peuvent pas respecter cette contrainte. Sans TLS-RPT, une politique MTA-STS en mode enforce peut bloquer des emails sans que vous le sachiez. Déployez les deux.
Q : Combien de domaines puis-je surveiller ?
R : Jusqu'à 10 domaines depuis un seul compte. Chaque domaine dispose de son propre endpoint HTTPS vérifié et de son tableau de bord dédié.
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 |
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