TLS-RPT : le rapport de transport chiffré

v=TLSRPTv1; rua=mailto:tlsrpt@exemple.fr

Une différence de format volontaire

Le choix du JSON plutôt que du XML n'est pas anecdotique. Les rapports DMARC ont hérité du XML pour des raisons historiques liées à l'époque de leur conception ; TLS-RPT, plus récent, adopte un format plus léger et plus simple à parser avec les outils modernes. Concrètement, cela signifie que les scripts d'ingestion pour TLS-RPT sont généralement plus courts à écrire que leurs équivalents DMARC — un détail appréciable pour qui envisage de bâtir son propre pipeline de traitement plutôt que de dépendre d'un service tiers.

Le format des rapports

Les rapports TLS-RPT sont au format JSON (contrairement au XML des rapports DMARC), généralement compressés en gzip et envoyés par email en pièce jointe, ou récupérables via l'API lorsqu'une URI https: a été choisie. Chaque rapport couvre une fenêtre de 24 heures et regroupe les résultats par « policy domain » (le domaine dont la politique MTA-STS a été évaluée) et par type d'échec.

Un rapport typique indique, par exemple : « 4 892 sessions réussies vers mail.exemple.fr, 3 sessions en échec de type certificate-expired, depuis Gmail, sur la période du 29 juillet. » Cette granularité permet d'isoler un problème précis — ici, un certificat à renouveler d'urgence — plutôt que de deviner à partir d'une plainte vague d'un destinataire.

Pourquoi c'est indispensable avant enforce

Le mode testing de MTA-STS journalise les échecs sans bloquer la livraison — mais cette journalisation ne sert qu'à condition d'être lue. Sans TLS-RPT, aucune visibilité n'existe sur ce que ce mode test observe réellement : la politique est publiée, puis vient l'attente, et l'espoir que tout se passe bien. Avec TLS-RPT, l'échec des connexions et sa cause apparaissent concrètement, jour après jour — exactement la même logique de preuve avant durcissement qui s'applique à la séquence DMARC none → quarantine → reject, détaillée dans atteindre p=reject sans casser ses emails.

Passer MTA-STS en enforce sans avoir lu au moins quelques semaines de rapports TLS-RPT propres, c'est durcir à l'aveugle : si un serveur destinataire légitime a un problème de certificat temporaire, le mode enforce refusera la livraison du courrier vers lui, sans autre signal qu'une baisse silencieuse de délivrabilité, potentiellement pendant des semaines avant que quelqu'un ne s'en aperçoive.

Lire un rapport : les signaux qui doivent alerter

Une fois les rapports en place, quelques signaux méritent une attention particulière :

• Un taux d'échec en hausse soudaine vers un destinataire précis — souvent le signe d'un problème de certificat ou de configuration récente de ce côté-là, à surveiller mais pas nécessairement du ressort de l'expéditeur.
• Des échecs mta-sts-policy-invalid répétés — ceux-là relèvent d'une responsabilité interne : la politique elle-même est mal formée ou introuvable, et mérite une correction immédiate.
• Des échecs certificate-expired sur les serveurs du domaine — le signal le plus urgent, puisqu'il indique que l'infrastructure elle-même a un certificat TLS périmé, bloquant potentiellement la réception de courrier légitime dès que MTA-STS sera en enforce.
• Une absence totale de rapports — la syntaxe DNS mérite un contrôle avant de conclure que tout va bien ; comme pour rua en DMARC, un enregistrement mal formé peut simplement empêcher l'envoi des rapports plutôt que signaler une absence de trafic. Le même réflexe de patience s'applique aussi : un silence de moins de 48 heures ne veut rien dire.

Après enforce : garder TLS-RPT allumé

La tentation, une fois MTA-STS passé en enforce, est de considérer TLS-RPT comme un échafaudage à démonter — la preuve est faite, à quoi bon continuer ? C'est exactement l'inverse. C'est en mode enforce que les rapports deviennent les plus précieux : un certificat qui expire, une migration de serveur mail, un changement de MX oublié dans le fichier de politique — chacun de ces événements ordinaires peut se mettre à bloquer du courrier légitime, silencieusement, du jour au lendemain. TLS-RPT est alors le seul canal qui donne l'alerte avant que les correspondants ne le fassent. C'est une supervision permanente, au même titre que la boîte rua DMARC : un flux qu'on lit tant que la politique existe, pas seulement pendant sa phase de test.

Le lien avec DANE et les autres mécanismes de sécurisation du transport

TLS-RPT n'est pas exclusivement lié à MTA-STS, même si c'est de loin l'usage le plus courant. La RFC 8460 conçoit le protocole comme un mécanisme de reporting générique pour les échecs de sécurisation du transport SMTP, ce qui inclut aussi DANE (DNS-based Authentication of Named Entities), une approche alternative qui ancre la validation TLS dans des enregistrements DNSSEC plutôt que dans un fichier de politique HTTPS. Dans une organisation qui a déployé DANE plutôt que (ou en plus de) MTA-STS, TLS-RPT continue de fournir la même visibilité sur les échecs de connexion, avec des codes d'erreur adaptés à ce mécanisme.

En pratique, la grande majorité des déploiements en 2026 privilégient MTA-STS pour sa simplicité de mise en œuvre — DANE exige une infrastructure DNSSEC déjà en place et correctement maintenue, une barrière technique plus haute pour beaucoup d'organisations. Mais le fait que TLS-RPT couvre les deux mécanismes signifie que l'investissement dans la configuration des rapports n'est pas perdu en cas de migration ou de combinaison des approches plus tard.

La fenêtre de 24 heures et le décalage à anticiper

Comme pour les rapports agrégés DMARC, il faut compter avec un décalage entre l'événement observé et sa réception dans la boîte de collecte. Un rapport TLS-RPT couvrant la journée du 29 juillet arrive généralement le 30 ou le 31, une fois le fournisseur émetteur ayant terminé d'agréger ses propres observations sur la fenêtre. Ce décalage a une conséquence pratique directe sur la cadence de surveillance pendant la phase testing de MTA-STS : aucun signal instantané n'est à attendre après un changement de configuration côté serveur — il faut plutôt compter 48 à 72 heures avant de pouvoir juger de l'effet réel d'un correctif sur le taux d'échec observé.

Outillage : lire du JSON à la main n'est pas viable

Comme pour les rapports DMARC, lire manuellement des dizaines de fichiers JSON compressés quotidiens n'est réaliste que pour un tout petit domaine. Dès que le volume grandit, un outil d'agrégation qui transforme ces rapports en tableau de bord lisible devient nécessaire — le même type de plateforme qui traite déjà les rapports DMARC agrégés propose souvent une prise en charge TLS-RPT en parallèle, puisque les deux flux partagent la même logique de collecte et de visualisation. Mutualiser les deux dans un seul outil évite de multiplier les tableaux de bord à surveiller séparément, et facilite la corrélation entre un incident d'authentification et un incident de transport survenant sur la même période.

En résumé

TLS-RPT est à MTA-STS ce que les rapports agrégés sont à DMARC : la boucle de preuve qui transforme une politique publiée à l'aveugle en un durcissement fondé sur des données réelles. Le configurer est un enregistrement DNS de plus, sans piège d'autorisation externe à gérer, et la lecture régulière de ses rapports est ce qui distingue un déploiement MTA-STS prudent d'un pari risqué sur la délivrabilité.

Pour vérifier l'état de l'authentification email de base — le socle sur lequel MTA-STS et TLS-RPT viennent s'ajouter — un passage du domaine dans l'analyseur DMARC gratuit suffit. C'est l'étape à traiter en priorité ; le transport chiffré vient ensuite compléter une identité déjà solide, pas la remplacer, et c'est dans cet ordre que les deux protocoles apportent le plus de valeur.