Analyser et exploiter vos rapports TLS-RPT : détecter les problèmes avant qu'ils n'impactent vos emails

Par CaptainDNS
Publié le 14 février 2026

Analyser un rapport TLS-RPT : structure JSON et types d'erreurs TLS email

TL;DR

Un rapport TLS-RPT est un fichier JSON compressé (gzip) envoyé quotidiennement par les serveurs émetteurs : il détaille chaque échec de négociation TLS sur votre domaine
Les 3 erreurs les plus fréquentes sont certificate-host-mismatch, starttls-not-supported et sts-policy-fetch-error, chacune avec une cause et une correction spécifique
Analysez le champ failure-details pour identifier le serveur MX concerné, l'IP de l'expéditeur et le type exact de l'échec
Utilisez le validateur de syntaxe TLS-RPT pour vérifier votre configuration avant et après correction

Vous avez configuré TLS-RPT sur votre domaine et les rapports commencent à arriver. Des fichiers JSON compressés, envoyés par Google, Microsoft, Yahoo et d'autres fournisseurs. Vous les ouvrez et vous trouvez des blocs de données structurées avec des champs comme policy-type, result-type, failed-session-count. Que signifient ces données ? Comment les transformer en actions concrètes ?

C'est la partie la plus sous-documentée du SMTP TLS Reporting. La RFC 8460 définit le format, mais pas l'interprétation opérationnelle. Ce guide comble ce vide. Vous apprendrez à lire la structure JSON d'un rapport, identifier chaque type d'erreur, et suivre un workflow de diagnostic concret pour renforcer la sécurité TLS de vos emails.

Pas encore configuré TLS-RPT ? Commencez par le guide complet (voir Guides connexes en fin d'article). Pour une configuration spécifique Microsoft 365, Google Workspace ou OVHcloud, le guide par fournisseur est aussi disponible en bas de page.

Anatomie d'un rapport TLS-RPT

Un rapport TLS-RPT est un fichier JSON envoyé en pièce jointe compressée (.json.gz). Chaque fournisseur qui vous envoie des emails produit son propre rapport, une fois par jour. Voici la structure complète d'un rapport typique :

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-12T00:00:00Z_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.captaindns.com",
          "max_age: 604800"
        ],
        "policy-domain": "captaindns.com",
        "mx-host": ["mail.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.captaindns.com",
          "receiving-ip": "203.0.113.10",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

Les 4 blocs du rapport

Chaque rapport contient exactement 4 niveaux d'information :

1. En-tête du rapport : qui l'envoie et quand :

organization-name : le fournisseur émetteur (Google, Microsoft, Yahoo)
date-range : la période couverte (toujours 24 heures)
report-id : identifiant unique du rapport

2. Bloc policy : quelle politique TLS a été évaluée :

policy-type : le type de politique (sts pour MTA-STS, tlsa pour DANE, no-policy-found si aucune)
policy-string : le contenu de la politique MTA-STS ou DANE appliquée
policy-domain : votre domaine
mx-host : les serveurs MX concernés

3. Bloc summary : le bilan chiffré :

total-successful-session-count : connexions TLS réussies
total-failure-session-count : connexions TLS échouées

4. Bloc failure-details : le détail de chaque échec (le plus important) :

result-type : le type exact de l'erreur
sending-mta-ip : l'IP du serveur qui a tenté de vous envoyer l'email
receiving-mx-hostname : votre serveur MX concerné
receiving-ip : l'IP de votre serveur MX
failed-session-count : nombre d'échecs de ce type

Anatomie d'un rapport TLS-RPT : les 4 blocs de données JSON (en-tête, politique, bilan, détails des échecs)

Comment recevoir et décompresser les rapports ?

Les rapports arrivent par email depuis des adresses comme noreply-smtp-tls-reporting@google.com. Le fichier joint porte un nom au format :

google.com!captaindns.com!2026-02-12T00:00:00Z!2026-02-13T00:00:00Z.json.gz

Pour le décompresser :

# Linux / macOS
gunzip google.com\!captaindns.com\!2026-02-12T00:00:00Z\!2026-02-13T00:00:00Z.json.gz

# Ou afficher directement sans extraire
zcat rapport.json.gz | python3 -m json.tool

Si vous recevez les rapports via HTTPS (endpoint https://), le serveur reçoit directement le JSON compressé en POST avec le Content-Type application/tlsrpt+gzip.

Les types d'échecs TLS-RPT (result-type)

Le champ result-type dans failure-details identifie précisément ce qui a échoué. La RFC 8460 définit 11 types d'échecs, répartis en 3 catégories :

Échecs liés au certificat TLS

result-type	Cause	Action corrective
`certificate-host-mismatch`	Le certificat TLS du serveur MX ne correspond pas au hostname	Renouvelez le certificat avec le bon CN/SAN pour votre MX
`certificate-expired`	Le certificat TLS a expiré	Renouvelez immédiatement le certificat
`certificate-not-trusted`	Le certificat n'est pas signé par une CA reconnue	Utilisez un certificat signé par une CA publique (Let's Encrypt, DigiCert)

Échecs liés à STARTTLS

result-type	Cause	Action corrective
`starttls-not-supported`	Le serveur MX ne propose pas STARTTLS	Activez STARTTLS dans la configuration de votre serveur mail
`validation-failure`	Échec générique de validation TLS	Vérifiez la chaîne de certificats complète et la configuration TLS

Échecs liés aux politiques MTA-STS et DANE

result-type	Cause	Action corrective
`sts-policy-fetch-error`	Impossible de récupérer la politique MTA-STS	Vérifiez que `https://mta-sts.captaindns.com/.well-known/mta-sts.txt` est accessible
`sts-policy-invalid`	La politique MTA-STS est mal formatée	Corrigez la syntaxe du fichier `mta-sts.txt`
`sts-webpki-invalid`	Le certificat HTTPS du serveur MTA-STS est invalide	Renouvelez le certificat du sous-domaine `mta-sts.captaindns.com`
`tlsa-invalid`	L'enregistrement DANE TLSA est invalide	Corrigez l'enregistrement TLSA dans votre zone DNS
`dnssec-invalid`	La validation DNSSEC a échoué	Corrigez votre chaîne DNSSEC
`dane-required`	DANE est requis mais le serveur ne le supporte pas	Déployez DANE ou supprimez les enregistrements TLSA

Les 3 erreurs les plus fréquentes en détail

certificate-host-mismatch

C'est l'erreur la plus courante. Elle apparaît quand le certificat TLS présenté par votre serveur MX ne contient pas le hostname attendu dans son champ CN (Common Name) ou SAN (Subject Alternative Name).

Scénario typique : votre MX est mail.captaindns.com mais le certificat est émis pour *.autredomaine.com (hébergement mutualisé) ou pour captaindns.com sans le sous-domaine mail.

Diagnostic :

# Vérifier le certificat de votre MX
openssl s_client -connect mail.captaindns.com:25 -starttls smtp \
  -servername mail.captaindns.com 2>/dev/null | \
  openssl x509 -noout -subject -ext subjectAltName

Correction : obtenez un certificat qui inclut le FQDN exact de votre MX dans le SAN. Avec Let's Encrypt :

certbot certonly --standalone -d mail.captaindns.com

starttls-not-supported

Le serveur MX ne propose pas la commande STARTTLS dans sa bannière SMTP. Les emails arrivent en clair.

Diagnostic :

# Tester si STARTTLS est annoncé
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>&1 | head -5
# Si "CONNECTED" apparaît, STARTTLS fonctionne
# Si erreur, STARTTLS n'est pas supporté

Correction : activez STARTTLS dans votre serveur mail. Pour Postfix :

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

sts-policy-fetch-error

Le serveur émetteur n'a pas pu récupérer votre politique MTA-STS à l'URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Causes fréquentes :

Le sous-domaine mta-sts.captaindns.com n'a pas d'enregistrement DNS A/AAAA
Le serveur HTTPS ne répond pas ou retourne une erreur 404/500
Le certificat HTTPS du sous-domaine mta-sts est expiré

Diagnostic :

# Tester l'accès à la politique
curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Pour un diagnostic complet de vos problèmes MTA-STS, consultez notre guide de troubleshooting MTA-STS.

Diagnostic pas à pas : de l'erreur à la correction

Quand vous recevez un rapport avec des échecs, suivez ce workflow en 5 étapes :

Étape 1 : Identifiez la gravité

Regardez le ratio échecs/succès dans le bloc summary :

total-successful-session-count: 1842
total-failure-session-count: 3

Un ratio inférieur à 1 % d'échecs est normal : il peut s'agir de tentatives depuis des serveurs mal configurés côté expéditeur. Au-delà de 5 %, il y a un problème à investiguer.

Étape 2 : Identifiez le result-type

Le champ result-type dans failure-details vous dit exactement ce qui a échoué. Reportez-vous au tableau des 11 types ci-dessus.

Étape 3 : Identifiez le serveur MX concerné

Le champ receiving-mx-hostname vous indique quel serveur est impacté. Si vous avez plusieurs MX (primaire + backup), un seul peut être mal configuré.

Étape 4 : Vérifiez avec les outils CaptainDNS

Utilisez le vérificateur TLS-RPT de CaptainDNS pour confirmer que votre enregistrement DNS est correct et que les politiques associées (MTA-STS, DANE) sont bien détectées.

Étape 5 : Corrigez et surveillez

Appliquez la correction correspondant au result-type, puis surveillez les rapports des 48 à 72 heures suivantes pour confirmer que l'erreur disparaît.

Workflow de diagnostic TLS-RPT : de la réception du rapport à la correction de l'erreur

Cas pratiques : analyser un rapport réel

Cas 1 : rapport propre (aucun échec)

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "report-id": "2026-02-12_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 2156,
        "total-failure-session-count": 0
      },
      "failure-details": []
    }
  ]
}

Interprétation : 2 156 connexions TLS réussies, zéro échec. Votre configuration fonctionne parfaitement. Ce rapport confirme que :

Votre certificat TLS est valide et correspond au hostname MX
STARTTLS est actif sur votre serveur
Votre politique MTA-STS est accessible et respectée

Cas 2 : échec certificat sur un MX secondaire

{
  "organization-name": "Microsoft Corporation",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com",
        "mx-host": ["mail.captaindns.com", "mail2.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 890,
        "total-failure-session-count": 47
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "40.107.22.89",
          "receiving-mx-hostname": "mail2.captaindns.com",
          "receiving-ip": "198.51.100.20",
          "failed-session-count": 47
        }
      ]
    }
  ]
}

Interprétation : 47 échecs sur mail2.captaindns.com (MX secondaire) avec une erreur certificate-host-mismatch. Le MX primaire (mail.captaindns.com) fonctionne correctement. Le certificat du MX secondaire ne contient pas mail2.captaindns.com dans son SAN.

Action : renouvelez le certificat de mail2.captaindns.com en incluant ce hostname dans le SAN.

Cas 3 : politique MTA-STS inaccessible

{
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 0,
        "total-failure-session-count": 156
      },
      "failure-details": [
        {
          "result-type": "sts-policy-fetch-error",
          "failed-session-count": 156
        }
      ]
    }
  ]
}

Interprétation : 156 échecs, tous du type sts-policy-fetch-error. Le serveur émetteur a détecté votre enregistrement MTA-STS (_mta-sts.captaindns.com) mais n'a pas pu télécharger la politique à https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Action : vérifiez que le sous-domaine mta-sts.captaindns.com pointe vers un serveur HTTPS fonctionnel avec un certificat valide.

Automatiser l'analyse de vos rapports

Volume faible : boîte mail dédiée

Pour un domaine recevant moins de 1 000 emails par jour, une adresse dédiée suffit :

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Créez un filtre dans votre client mail pour classer les rapports automatiquement. Consultez-les une fois par semaine en cherchant des total-failure-session-count supérieurs à zéro.

Volume élevé : endpoint HTTPS

Pour les domaines à fort trafic, configurez un endpoint HTTPS qui reçoit les rapports en POST :

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://reports.captaindns.com/tls-rpt"

L'endpoint reçoit le JSON compressé en gzip avec le Content-Type application/tlsrpt+gzip. Vous pouvez parser les rapports automatiquement et déclencher des alertes quand total-failure-session-count dépasse un seuil.

Vérifier votre configuration avec CaptainDNS

Avant de modifier votre configuration TLS ou MTA-STS, utilisez le générateur TLS-RPT pour créer un enregistrement correct. Après correction, vérifiez avec le vérificateur TLS-RPT que tout est en place.

🎯 Plan d'action recommandé

Décompressez et lisez votre premier rapport : ouvrez un fichier .json.gz reçu de Google ou Microsoft et identifiez les 4 blocs (en-tête, policy, summary, failure-details)
Vérifiez le ratio échecs/succès : un taux d'échec supérieur à 5 % nécessite une investigation
Identifiez le result-type : utilisez le tableau des 11 types d'échecs pour comprendre la cause exacte
Corrigez le problème sur le serveur concerné : certificat, STARTTLS, ou politique MTA-STS selon le type d'erreur
Surveillez les rapports suivants : confirmez la disparition de l'erreur dans les 48 à 72 heures après correction

FAQ

Qu'est-ce qu'un rapport TLS-RPT et que contient-il ?

Un rapport TLS-RPT est un fichier JSON compressé (gzip) envoyé quotidiennement par les serveurs de messagerie qui vous envoient des emails. Il contient le nom de l'organisation émettrice, la période couverte (24 heures), la politique TLS évaluée (MTA-STS ou DANE), le nombre de connexions TLS réussies et échouées, et le détail de chaque type d'échec avec les IP et hostnames concernés.

Comment lire la structure JSON d'un rapport TLS-RPT ?

Le rapport JSON comporte 4 niveaux : l'en-tête (organization-name, date-range), le bloc policy (policy-type, policy-string), le bloc summary (compteurs succès/échecs), et le bloc failure-details (result-type, sending-mta-ip, receiving-mx-hostname). Décompressez le fichier .json.gz avec gunzip ou zcat, puis formatez avec python3 -m json.tool pour une lecture lisible.

Quels sont les types d'erreurs (result-type) dans un rapport TLS-RPT ?

La RFC 8460 définit 11 types d'échecs répartis en 3 catégories : erreurs de certificat (certificate-host-mismatch, certificate-expired, certificate-not-trusted), erreurs STARTTLS (starttls-not-supported, validation-failure), et erreurs de politique (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, dnssec-invalid, dane-required). Chaque type indique précisément ce qui a échoué lors de la négociation TLS.

Que signifie certificate-host-mismatch dans un rapport TLS-RPT ?

L'erreur certificate-host-mismatch signifie que le certificat TLS présenté par votre serveur MX ne correspond pas au hostname attendu. Par exemple, si votre MX est mail.captaindns.com mais que le certificat est émis pour un autre domaine. Corrigez en obtenant un certificat dont le SAN (Subject Alternative Name) inclut le FQDN exact de votre MX.

Comment corriger une erreur starttls-not-supported ?

L'erreur starttls-not-supported signifie que votre serveur MX n'annonce pas la commande STARTTLS, donc les emails transitent en clair. Activez STARTTLS dans la configuration de votre serveur : pour Postfix, ajoutez smtpd_tls_security_level = may avec les chemins vers votre certificat et clé privée dans main.cf. Vérifiez ensuite avec openssl s_client -connect mail.captaindns.com:25 -starttls smtp.

À quelle fréquence les rapports TLS-RPT sont-ils envoyés ?

Les rapports TLS-RPT sont envoyés une fois par jour (période de 24 heures). Chaque fournisseur qui vous envoie des emails (Google, Microsoft, Yahoo, etc.) produit son propre rapport indépendamment. Vous recevez donc potentiellement plusieurs rapports par jour, un par fournisseur émetteur. Les premiers rapports arrivent 24 à 48 heures après la publication de votre enregistrement TLS-RPT.

Quelle différence entre les rapports TLS-RPT et DMARC ?

Les rapports DMARC surveillent l'authentification des emails (SPF, DKIM, alignement du domaine), tandis que les rapports TLS-RPT surveillent le chiffrement du transport (négociation TLS entre serveurs). DMARC vérifie qui envoie l'email, TLS-RPT vérifie comment il est transporté. Les rapports DMARC sont au format XML, les rapports TLS-RPT au format JSON. Les deux sont complémentaires pour sécuriser votre domaine.

📖 Glossaire

TLS-RPT : SMTP TLS Reporting (RFC 8460), mécanisme de rapports quotidiens sur les échecs de négociation TLS lors de la livraison d'emails.
result-type : champ JSON dans failure-details qui identifie le type exact d'échec TLS (certificate-host-mismatch, starttls-not-supported, etc.).
MTA-STS : Mail Transfer Agent Strict Transport Security (RFC 8461), politique qui impose le chiffrement TLS pour la réception d'emails.
DANE : DNS-Based Authentication of Named Entities (RFC 7672), mécanisme alternatif à MTA-STS qui utilise DNSSEC et les records TLSA.
STARTTLS : extension SMTP qui permet de chiffrer une connexion initialement en clair. Opportuniste par défaut.
SAN : Subject Alternative Name, champ du certificat TLS qui liste les hostnames valides.
policy-type : champ JSON qui indique le type de politique évaluée (sts, tlsa, ou no-policy-found).

Vérifiez votre configuration maintenant : Utilisez notre vérificateur TLS-RPT pour contrôler que votre enregistrement _smtp._tls est correct et que les politiques associées sont bien détectées.

Analyser et exploiter vos rapports TLS-RPT : détecter les problèmes avant qu'ils n'impactent vos emails

Anatomie d'un rapport TLS-RPT

Les 4 blocs du rapport

Comment recevoir et décompresser les rapports ?

Les types d'échecs TLS-RPT (result-type)

Échecs liés au certificat TLS

Échecs liés à STARTTLS

Échecs liés aux politiques MTA-STS et DANE

Les 3 erreurs les plus fréquentes en détail

certificate-host-mismatch

starttls-not-supported

sts-policy-fetch-error

Diagnostic pas à pas : de l'erreur à la correction

Cas pratiques : analyser un rapport réel

Cas 1 : rapport propre (aucun échec)

Cas 2 : échec certificat sur un MX secondaire

Cas 3 : politique MTA-STS inaccessible

Automatiser l'analyse de vos rapports

Volume faible : boîte mail dédiée

Volume élevé : endpoint HTTPS

Vérifier votre configuration avec CaptainDNS

🎯 Plan d'action recommandé

FAQ

Qu'est-ce qu'un rapport TLS-RPT et que contient-il ?

Comment lire la structure JSON d'un rapport TLS-RPT ?

Quels sont les types d'erreurs (result-type) dans un rapport TLS-RPT ?

Que signifie certificate-host-mismatch dans un rapport TLS-RPT ?

Comment corriger une erreur starttls-not-supported ?

À quelle fréquence les rapports TLS-RPT sont-ils envoyés ?

Quelle différence entre les rapports TLS-RPT et DMARC ?

📖 Glossaire

📚 Guides TLS-RPT connexes

Sources

Articles similaires

TLS-RPT : le guide complet pour monitorer la sécurité TLS de vos emails

MTA-STS ne fonctionne pas ? Guide de dépannage complet

MTA-STS : le guide complet pour sécuriser le transport de vos emails