Pourquoi analyser vos rapports TLS-RPT ?
Chaque jour, Google, Microsoft et Yahoo envoient des rapports TLS-RPT aux domaines configurés. Ces rapports révèlent si le chiffrement TLS fonctionne pour vos emails entrants.
Le problème : un rapport TLS-RPT est un fichier JSON technique, souvent compressé en gzip. Sans outil dédié, son contenu reste illisible.
Trois raisons d'agir maintenant :
- Détecter les certificats expirés - un certificat expiré sur un MX bloque le chiffrement et expose vos emails en clair
- Valider votre politique MTA-STS - une politique inaccessible ou invalide génère des échecs signalés dans chaque rapport
- Surveiller les tendances - un taux d'échec en hausse signale un problème de configuration à corriger avant qu'il n'impacte la délivrabilité
Uploadez votre premier rapport ci-dessus pour obtenir un diagnostic en 10 secondes.
Comment analyser un rapport TLS-RPT en 3 étapes
Étape 1 : Récupérez le rapport
Ouvrez l'email reçu de Google (noreply-smtp-tls-reporting@google.com), Microsoft ou Yahoo. Téléchargez la pièce jointe .json.gz ou .json.
Étape 2 : Uploadez le fichier
Glissez-déposez le fichier sur la zone d'upload ci-dessus. L'outil accepte le JSON brut et le JSON compressé gzip, jusqu'à 10 Mo.
Étape 3 : Lisez le diagnostic
CaptainDNS décompresse, parse et affiche en quelques secondes :
- Un score de santé sur 100 réparti en 4 niveaux : excellent, bon, attention, critique
- Le détail par politique MTA-STS et DANE avec taux de succès par serveur MX
- Chaque échec expliqué avec sa sévérité, sa cause et une recommandation actionnable
- Un lien direct vers l'outil CaptainDNS approprié pour corriger chaque problème
Structure d'un rapport TLS-RPT (RFC 8460)
Un rapport TLS-RPT suit le schéma défini par la RFC 8460. Chaque rapport contient trois blocs principaux :
- organization-name - l'expéditeur du rapport (ex : Google Inc., Microsoft Corporation)
- date-range - la période couverte, généralement 24 heures
- policies - une ou plusieurs politiques évaluées : MTA-STS, DANE, ou les deux
Pour chaque politique, le rapport fournit :
| Champ | Description |
|---|---|
policy-type | Type de politique (sts, tlsa ou no-policy-found) |
policy-domain | Domaine concerné |
total-successful-session-count | Connexions TLS réussies |
total-failure-session-count | Connexions TLS échouées |
failure-details | Détail de chaque type d'échec |
Les 12 types d'échecs TLS analysés
L'analyseur CaptainDNS couvre tous les codes d'échec définis par la RFC 8460. Chaque échec est classé par sévérité et accompagné d'une action corrective.
Échecs STARTTLS
| Code | Sévérité | Cause | Action |
|---|---|---|---|
starttls-not-supported | Critique | Le serveur MX ne propose pas STARTTLS | Activer STARTTLS sur le serveur |
Échecs de certificat
| Code | Sévérité | Cause | Action |
|---|---|---|---|
certificate-expired | Haute | Certificat TLS expiré | Renouveler avec Let's Encrypt ou votre CA |
certificate-host-mismatch | Haute | CN/SAN ne correspond pas au hostname MX | Émettre un certificat avec le bon hostname |
certificate-not-trusted | Haute | CA non reconnue ou certificat auto-signé | Utiliser un certificat d'une CA publique |
Échecs MTA-STS
| Code | Sévérité | Cause | Action |
|---|---|---|---|
sts-policy-fetch-error | Haute | Politique MTA-STS inaccessible | Vérifier https://mta-sts.domaine/.well-known/mta-sts.txt |
sts-policy-invalid | Haute | Contenu de la politique invalide | Valider avec le MTA-STS Syntax Checker |
sts-webpki-invalid | Haute | Certificat HTTPS du serveur MTA-STS invalide | Renouveler le certificat de mta-sts.domaine |
Échecs DANE
| Code | Sévérité | Cause | Action |
|---|---|---|---|
tlsa-invalid | Haute | Record TLSA obsolète | Mettre à jour avec le DANE/TLSA Checker |
dnssec-invalid | Critique | Chaîne DNSSEC cassée | Vérifier avec le DNSSEC Checker |
dane-required | Haute | DANE requis mais indisponible | Publier des records TLSA valides |
Cas d'usage concrets
Ces trois scénarios illustrent les problèmes les plus fréquents détectés par l'analyseur TLS-RPT.
Incident 1 : Certificat expiré sur un MX secondaire
Symptôme : le rapport Google signale 200 échecs certificate-expired sur mail2.exemple.com.
Diagnostic : le certificat Let's Encrypt du MX secondaire n'a pas été renouvelé. Le cron certbot est cassé.
Action : renouvelez le certificat, puis vérifiez l'automatisation du renouvellement.
Incident 2 : Politique MTA-STS inaccessible
Symptôme : le rapport Microsoft signale sts-policy-fetch-error avec « HTTP 503 ».
Diagnostic : le serveur hébergeant la politique MTA-STS est hors service.
Action : rétablissez le serveur ou adoptez l'hébergement MTA-STS de CaptainDNS pour une disponibilité garantie.
Incident 3 : Aucune politique TLS configurée
Symptôme : le rapport affiche no-policy-found pour un sous-domaine.
Diagnostic : aucune politique MTA-STS ni DANE n'est publiée pour ce sous-domaine.
Action : configurez MTA-STS avec le Générateur MTA-STS ou déployez DANE avec le Générateur DANE/TLSA.
FAQ
Q : Qu'est-ce qu'un rapport TLS-RPT et comment le lire ?
R : Un rapport TLS-RPT est un fichier JSON envoyé chaque jour par les serveurs mail qui livrent du courrier à votre domaine. Il comptabilise les connexions TLS réussies et échouées. Chaque échec est détaillé par type et par serveur MX. Ces fichiers sont souvent compressés en .json.gz - uploadez-les ici pour un diagnostic immédiat.
Q : Pourquoi est-ce que je reçois des emails de noreply-smtp-tls-reporting@google.com ?
R : Votre domaine a un enregistrement DNS TLS-RPT avec une adresse mailto:. Google envoie donc un rapport quotidien sur les connexions TLS vers votre domaine. C'est normal et souhaitable. Ces rapports sont votre meilleur outil de surveillance TLS.
Q : Quelle est la différence entre un TLS-RPT checker et un TLS-RPT report analyzer ?
R : Un TLS-RPT checker vérifie votre enregistrement DNS _smtp._tls.domaine - c'est la configuration. Un TLS-RPT report analyzer interprète les fichiers de rapport JSON - ce sont les résultats. Les deux sont complémentaires. Utilisez l'Inspecteur TLS-RPT pour vérifier la configuration, et cet outil pour analyser les rapports.
Outils complémentaires
| Outil | Utilité |
|---|---|
| Générateur TLS-RPT | Créer l'enregistrement DNS TLS-RPT |
| Inspecteur TLS-RPT | Vérifier la configuration DNS TLS-RPT |
| TLS-RPT Syntax Checker | Valider la syntaxe d'un enregistrement |
| Inspecteur MTA-STS | Vérifier le déploiement MTA-STS |
| DANE/TLSA Checker | Vérifier les records DANE |
| Audit domaine email | Audit complet SPF, DKIM, DMARC, MTA-STS, TLS-RPT |
Vous ne recevez pas encore de rapports TLS-RPT ? Créez votre enregistrement DNS en 2 minutes avec le Générateur TLS-RPT.
Ressources utiles
- RFC 8460 - SMTP TLS Reporting - spécification officielle TLS-RPT
- RFC 8461 - MTA Strict Transport Security - protocole compagnon MTA-STS
- RFC 7672 - SMTP Security via DANE - authentification DANE pour SMTP
- Google - Configurer TLS Reporting - guide officiel Google Workspace