Pourquoi surveiller les rapports TLS-RPT ?
TLS-RPT (SMTP TLS Reporting, RFC 8460) est le seul standard qui rend visibles les échecs TLS sur votre courrier entrant. Sans lui, les emails refusés ou dégradés en 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 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 n'existent plus. Les émetteurs stricts rejettent la connexion.
- Rétrogradation STARTTLS : Des intermédiaires réseau suppriment l'extension STARTTLS. Le courrier transite en clair. Ni vous ni vos utilisateurs n'en êtes informés.
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 émetteurs de signaler les échecs de négociation TLS au domaine destinataire. Un seul enregistrement DNS suffit.
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 ?
| 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 |
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 principaux fournisseurs de messagerie envoient des rapports TLS-RPT lorsqu'ils détectent des échecs TLS vers votre domaine. Si vous recevez du courrier de l'un d'eux, vous êtes déjà couvert :
- 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 le reporting 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
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.
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