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 les 11 codes d'échec définis par la RFC 8460, plus la variante starttls-not-offered émise par certains expéditeurs. 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 |
starttls-not-offered | Critique | Variante de starttls-not-supported utilisée par certains expéditeurs | 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 de validation TLS
| Code | Sévérité | Cause | Action |
|---|---|---|---|
validation-failure | Moyenne | Échec TLS générique, non couvert par les autres codes | Lire failure-reason-code et vérifier la configuration TLS du MX |
É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 | Enregistrement 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 enregistrements 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 enregistrements DANE |
| Audit domaine email | Audit complet SPF, DKIM, DMARC, MTA-STS, TLS-RPT |
| Monitoring TLS-RPT | Surveiller et analyser automatiquement les rapports 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