Qu'est-ce que le rapport TLS ? Comment les rapports SMTP TLS permettent-ils de détecter les échecs de livraison des e-mails ?
par
Dernière mise à jour :
6 Temps de lecture : 2 min
La plupart des défaillances SMTP TLS se produisent sans que personne ne s'en aperçoive. Un certificat arrive à expiration, un serveur cesse de prendre en charge STARTTLS ou un pirate impose un retour à une version antérieure : dans ces cas-là, l'e-mail est soit envoyé sans être chiffré, soit n'arrive jamais à destination, sans qu'aucune alerte n'explique pourquoi. Les rapports TLS ont pour but de combler cette lacune.
Défini dans la RFC 8460, le protocole SMTP TLS Reporting (TLS-RPT) offre aux propriétaires de domaines un moyen standardisé de savoir quand le chiffrement TLS échoue entre les serveurs de messagerie, et pour quelle raison. Cet article explique le fonctionnement du protocole SMTP TLS, les causes possibles de ses défaillances, la structure d'un rapport TLS-RPT réel champ par champ, ainsi que les types d'erreurs spécifiques que vous rencontrerez lorsque vous commencerez à les analyser.
Qu'est-ce que le protocole SMTP TLS, et pourquoi rencontre-t-il des problèmes ?
Pour comprendre pourquoi les rapports TLS sont importants, il est utile de savoir pourquoi le protocole SMTP en avait besoin au départ.
Le protocole SMTP n'a pas été conçu pour prendre en charge le chiffrement
Le protocole SMTP remonte à 1982. À l'époque, le courrier électronique constituait un petit réseau sécurisé, et le protocole avait été conçu sans couche de chiffrement. Par défaut, les messages circulaient entre les serveurs en texte clair.
Cette faille est restée ouverte pendant des décennies. Le chiffrement a été ajouté par la suite, à titre d'option plutôt que d'exigence, et c'est là que le problème suivant commence.
STARTTLS a rendu le chiffrement facultatif, et non garanti
STARTTLS permet à un serveur émetteur de demander à un serveur récepteur de faire passer une connexion en texte clair à une connexion chiffrée. Si les deux parties prennent en charge ce protocole, le message est transmis sous forme chiffrée. Si l’une des deux parties ne le prend pas en charge, ou si un problème vient perturber la procédure d’établissement de la connexion, celle-ci revient discrètement au texte clair et l’e-mail est tout de même transmis.
Ce mécanisme de repli constitue le problème central que le protocole TLS-RPT a été conçu pour mettre en évidence. Aucune disposition de la norme SMTP ne permet de savoir quand un message a été envoyé en clair, que ce soit en raison d'une erreur de configuration ou parce que quelqu'un a délibérément supprimé la commande STARTTLS en cours de transmission.
Qu'est-ce que le reporting TLS (TLS-RPT) ?
TLS-RPT est une norme de reporting, définie dans la RFC 8460, qui permet aux propriétaires de domaines de recevoir régulièrement des rapports structurés sur les échecs de connexion TLS liés aux e-mails envoyés vers leur domaine. Elle n'empêche pas ces échecs de se produire. Elle vous indique quand ils se sont produits, à quelle fréquence et pourquoi, afin que vous puissiez résoudre le problème sous-jacent.
Pour obtenir une description complète des champs du rapport RFC 8460 et savoir comment publier un enregistrement DNS TLS-RPT, consultez notre guide détaillé sur le TLS-RPT.
Le lien entre TLS-RPT et MTA-STS
TLS-RPT et MTA-STS fonctionnent en tandem. MTA-STS est le mécanisme d'application : il indique aux serveurs expéditeurs que les e-mails destinés à votre domaine doivent transiter par une connexion chiffrée et authentifiée, sous peine d'être rejetés. TLS-RPT est le mécanisme de notification : il signale ce qui s'est passé chaque fois que cette connexion chiffrée n'a pas pu être établie. L'un définit la règle, l'autre vous informe lorsque celle-ci est déclenchée.
Pour connaître les étapes détaillées de configuration de MTA-STS pour votre domaine, vous pouvez consulter notre guide de mise en œuvre de MTA-STS.
Fonctionnement du rapport SMTP TLS, étape par étape
- Le propriétaire du domaine publie un enregistrement DNS de type TLS-RPT, qui indique aux serveurs de messagerie expéditeurs où envoyer les rapports d'échec.
- Un serveur émetteur tente de transmettre le courrier en utilisant le protocole TLS, généralement via STARTTLS.
- Si cette tentative échoue, le serveur émetteur consigne la raison de l'échec dans son journal.
- Environ une fois toutes les 24 heures, le serveur émetteur compile ces résultats dans un rapport au format JSON et l'envoie, généralement par e-mail ou via une requête POST HTTPS, à l'adresse indiquée dans l'enregistrement TLS-RPT du domaine.
- Le propriétaire du domaine ouvre le rapport et recherche des tendances : quels serveurs présentent des défaillances, à quelle fréquence et pour quelle raison.
Contenu d'un véritable rapport TLS-RPT
Les rapports TLS-RPT sont fournis au format JSON, qui n'est pas vraiment lisible par l'utilisateur. Vous trouverez ci-dessous un exemple abrégé et réaliste, basé sur le format RFC 8460, comprenant le résumé d'une session réussie et celui d'une session ayant échoué, suivi d'une explication en langage clair de chaque champ.
JSON
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2026-07-01T00:00:00Z",
"end-datetime": "2026-07-01T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "[email protected]",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: enforce",
"mx: mail.yourdomain.com",
"max_age: 604800"
],
"policy-domain": "yourdomain.com"
},
"summary": {
"total-successful-session-count": 4821,
"total-failure-session-count": 3
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail.yourdomain.com",
"receiving-mx-helo": "mail.yourdomain.com",
"receiving-ip": "203.0.113.45",
"failed-session-count": 2,
"additional-information": "https://support.google.com/mail/answer/tls-rpt-cert-expired"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail2.yourdomain.com",
"receiving-ip": "203.0.113.46",
"failed-session-count": 1
}
}
}
]
}
Que signifie réellement chaque champ ?
- nom-de-l'organisation : Auteur du signalement. Il s'agit généralement d'un grand fournisseur de messagerie électronique, tel que Google, Microsoft ou Yahoo.
- période : la période couverte par le rapport. La plupart des expéditeurs établissent leurs rapports sur une base glissante de 24 heures.
- coordonnées / identifiant du rapport : Comment contacter l'expéditeur, ainsi qu'un identifiant unique pour ce rapport spécifique. Utile si vous devez faire référence à ce rapport dans un ticket d'assistance.
- policy-type / policy-string : la politique MTA-STS (ou DANE) que le serveur émetteur a détectée pour votre domaine à ce moment-là, affichée exactement telle qu’elle a été récupérée. Cela vous permet de vérifier que la politique que vous avez publiée correspond bien à celle que les expéditeurs reçoivent réellement.
- nombre-total-de-sessions-réussies / nombre-total-de-sessions-échouées : le chiffre phare. Dans cet exemple, sur 4 824 tentatives de livraison, 4 821 ont abouti et 3 ont échoué.
- failure-details : une entrée par type d’échec, avec un nombre d’occurrences. C’est la partie qui mérite une intervention :
– certificate-expired : le certificat TLS avait expiré pour 2 des sessions ayant échoué. Solution : renouveler et réinstaller le certificat.
– starttls-not-supported : le serveur destinataire (mail2.votredomaine.com) n’a pas du tout répondu à la requête STARTTLS pour une session. Solution : vérifiez la configuration TLS du serveur, car elle est peut-être manquante ou mal configurée.
Types courants d'échecs TLS que vous verrez dans les rapports
Les rapports TLS-RPT utilisent un ensemble fixe de valeurs de type de résultat. Voici celles qui apparaissent le plus souvent, leur signification respective et les mesures à prendre en fonction de chacune d'entre elles.
Certificat expiré
Le certificat TLS du serveur destinataire avait dépassé sa date d'expiration. Renouvelez le certificat avant qu'il n'expire et programmez un rappel bien avant la prochaine date d'expiration.
Non-correspondance du nom du certificat
Le certificat présenté ne correspond pas au nom d'hôte attendu par le serveur émetteur. Cela indique généralement un certificat mal configuré ou un enregistrement DNS pointant vers le mauvais hôte.
STARTTLS n'est pas pris en charge
Le serveur destinataire n'a pas du tout répondu à la commande STARTTLS. Vérifiez que le protocole TLS est bien activé sur ce serveur de messagerie et assurez-vous que le logiciel du serveur le prend effectivement en charge.
Échec de la récupération de la politique MTA-STS
Le serveur d'envoi n'a pas pu récupérer votre fichier de politique MTA-STS via HTTPS. Vérifiez que le fichier de politique est accessible, correctement formaté et mis à disposition avec un certificat valide.
Version TLS trop ancienne
La connexion a tenté de négocier une version TLS que le serveur émetteur considère comme obsolète ou non sécurisée. Mettez à jour la configuration TLS de votre serveur de messagerie afin de désactiver les anciennes versions du protocole. Pour les problèmes de validation liés aux certificats en particulier, consultez notre guide sur DANE.
Pourquoi les rapports SMTP TLS sont-ils importants ?
Le rapport SMTP TLS présente de nombreux avantages. En voici quelques-uns :
Sécurité : détection des attaques par « downgrade »
TLS-RPT met en évidence les cas où une connexion a été détournée vers un canal non chiffré, ce qui correspond exactement au schéma à l'origine d'une attaque de « downgrade » de type « man-in-the-middle » (MITM). Sans signalement, ce type d'interception peut se poursuivre indéfiniment sans que personne ne s'en aperçoive.
Visibilité : Éliminer les angles morts
Sans TLS-RPT, il n'existe aucun moyen fiable de savoir pourquoi les e-mails envoyés vers votre domaine ont échoué, ni s'ils ont été remis sans cryptage. Les rapports indiquent précisément où et pourquoi une connexion TLS a été interrompue, vous évitant ainsi d'avoir à deviner.
Efficacité : Dépannage plus rapide
L'analyse des journaux du serveur pour identifier l'origine d'un problème de livraison prend du temps. Les rapports TLS-RPT indiquent directement le serveur à l'origine de la défaillance, le type de défaillance et sa fréquence, ce qui permet de réduire le temps de dépannage de plusieurs jours à quelques minutes.
Conclusion : comment PowerDMARC simplifie le reporting TLS
Les rapports TLS-RPT sont fournis sous forme de fichiers JSON bruts, et les parcourir manuellement pour chaque source d'envoi devient très vite fastidieux. PowerDMARC convertit automatiquement ces rapports en tableaux de bord clairs, regroupés par type de résultat et par source d'envoi, ce qui vous permet d'identifier les problèmes et leur origine sans avoir à ouvrir le moindre fichier JSON.
Nous aidons les propriétaires de noms de domaine :
- Analyse automatiquement les données JSON brutes pour les transformer en tableaux de bord lisibles, sans qu'il soit nécessaire de décoder manuellement les fichiers de rapport TLS-RPT.
- Filtrer selon deux vues du rapport : par source d'envoi (mode de politique, nombre de sessions, totaux de livraison) et par résultat (sessions réussies en haut, échecs en bas).
- Les échecs de drilldown permettent de développer une session ayant échoué et d'afficher le nom d'hôte, l'adresse IP, le nombre d'échecs et la raison de l'échec du serveur destinataire, de sorte que la solution à apporter apparaisse clairement au premier coup d'œil.
- Téléchargez des fichiers JSON, ZIP ou GZ grâce à un historique des téléchargements qui vous permet de consulter à tout moment les rapports antérieurs.
- Générez automatiquement et validez les enregistrements CNAME nécessaires pour recevoir vos rapports grâce à une configuration DNS en un clic, ainsi qu'une adresse personnalisable vers laquelle les rapports agrégés seront envoyés.
- Exportez des fichiers JSON bruts lorsque vous avez besoin du fichier d'origine pour un ticket ou pour approfondir votre analyse, grâce à des autorisations détaillées permettant de contrôler quels utilisateurs du compte sont autorisés à importer des rapports.
Commencez un essai gratuit ou réservez une démonstration pour le tester avec les données de votre propre domaine.
Foire aux questions
1. À quoi sert le reporting TLS ?
Les rapports TLS permettent de détecter et de diagnostiquer les problèmes liés à la transmission des e-mails chiffrés, notamment les certificats périmés, les serveurs mal configurés et les attaques par « downgrade », en générant régulièrement des rapports indiquant la nature des problèmes et leurs causes.
2. Le protocole SMTP TLS correspond-il au protocole TLS-RPT ?
Oui. Les termes « SMTP TLS reporting » et « TLS-RPT » font référence à la même norme RFC 8460. TLS-RPT est l'abréviation de ce protocole.
3. Comment configurer les rapports TLS pour mon domaine ?
Pour le configurer sur votre domaine, il vous suffit de publier un enregistrement DNS TLS-RPT indiquant où les rapports doivent être envoyés. Vous pouvez en générer un à l'aide de notre générateur d'enregistrements TLS-RPT et vérifier qu'il est bien opérationnel grâce à notre outil de vérification TLS-RPT.
4. Que se passe-t-il si je n'active pas le protocole TLS-RPT ?
Si vous n'activez pas TLS-RPT, les serveurs de messagerie tenteront tout de même de mettre en place le chiffrement TLS de leur propre initiative, mais vous n'aurez aucune visibilité sur les échecs. Les attaques par « downgrade », les certificats périmés et les serveurs mal configurés peuvent ainsi passer inaperçus indéfiniment.
5. Le protocole TLS-RPT fonctionne-t-il sans MTA-STS ?
Oui, TLS-RPT permet de signaler les échecs TLS de manière autonome. Mais il s'avère particulièrement utile lorsqu'il est associé à MTA-STS, car MTA-STS impose une transmission chiffrée et TLS-RPT rend compte de ce qui s'est passé lorsque cette exigence a été appliquée.
6. À quelle fréquence les rapports SMTP TLS sont-ils envoyés ?
La plupart des expéditeurs génèrent et envoient des rapports environ une fois toutes les 24 heures, bien que l'intervalle exact puisse varier selon le fournisseur.
Expert en sécurité des domaines et des courriels chez PowerDMARC
Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.
Derniers messages de Ahona Rudra (voir tous)
- Qu'est-ce que le rapport TLS ? Comment les rapports TLS SMTP permettent-ils de détecter les échecs de livraison des e-mails ? - 9 juillet 2026
- Les meilleurs serveurs MCP DMARC en 2026 : intégrez l'IA à vos données d'authentification des e-mails - 9 juillet 2026
- Étude de cas DMARC MSP : The Great Geek étend ses services de sécurité des e-mails pour les PME grâce à PowerDMARC - 25 juin 2026
