Rapports TLS

À quoi servent les rapports TLS

Quand un serveur de messagerie vous écrit, le chiffrement de la connexion est opportuniste. Le serveur émetteur demande poliment STARTTLS, et si quelque chose se passe mal, certificat expiré, chaîne incomplète, aucune version de TLS en commun, il a le choix entre deux mauvaises options : renvoyer le message en clair, ou renoncer à vous le remettre.

Dans les deux cas, personne ne vous prévient. Le message arrive, ou n’arrive pas, et rien dans vos journaux ne dit qu’il a voyagé sans protection.

Les rapports TLS (RFC 8460) comblent exactement ce trou. Vous publiez un enregistrement DNS qui dit « si vous rencontrez un problème en m’écrivant, racontez-le moi », et les opérateurs qui implémentent la norme, Google, Microsoft, Yahoo et quelques autres, vous envoient chaque jour un compte rendu chiffré de ce qu’ils ont observé.

Le point le plus souvent mal compris Ces rapports décrivent le courrier entrant, celui qu’on vous envoie, vu depuis les serveurs de l’expéditeur. Ils ne disent rien de vos propres campagnes. Si vous cherchez à savoir comment vos envois sont reçus, c’est du côté des rapports DMARC qu’il faut regarder.

Avant de commencer

Il vous faut deux choses :

un domaine ajouté et vérifié dans Sender Audit. Les rapports reçus pour un domaine non vérifié sont rejetés, sans quoi n’importe qui pourrait faire déposer des données sur votre compte ;
l’accès à la zone DNS de ce domaine, pour y publier un enregistrement TXT.

Activer les rapports

Carte d'activation des rapports TLS dans le tableau de bord, avec l'hôte DNS et l'enregistrement TXT à copier — La carte en haut de la page **Rapports TLS** vous donne les deux valeurs à publier. L’adresse de collecte est propre à votre compte.

Ouvrez votre tableau de bord, puis Rapports TLS dans le menu de gauche.
Repérez l’hôte DNS à créer. C’est toujours _smtp._tls. suivi de votre domaine. Pour mondomaine.fr, l’hôte est donc _smtp._tls.mondomaine.fr.
Copiez la valeur complète de l’enregistrement TXT avec le bouton Copier le record. Elle a cette forme :
```
v=TLSRPTv1; rua=mailto:votre-adresse-de-collecte@…
```
Créez l’enregistrement TXT dans votre zone DNS, avec l’hôte de l’étape 2 et la valeur de l’étape 3.
Attendez. Les premiers rapports arrivent généralement sous 24 à 72 heures, parce qu’ils sont envoyés une fois par jour et seulement si du courrier vous a été adressé.

Publier ce record ne change rien à la réception de votre courrier L’enregistrement _smtp._tls ne modifie aucune règle de remise et n’impose aucune contrainte de chiffrement. Il demande uniquement à recevoir des comptes rendus. Vous pouvez le retirer à tout moment sans conséquence sur vos flux. C’est MTA-STS, un mécanisme distinct, qui rend le chiffrement obligatoire.

Pour vérifier que la publication est correcte avant même le premier rapport, passez le domaine dans le vérificateur TLS-RPT, ou interrogez directement le DNS :

dig +short TXT _smtp._tls.mondomaine.fr

Lire le graphe des succès et des échecs

Graphe quotidien des sessions TLS réussies et échouées sur 30 jours — Chaque barre représente une journée, toutes sources confondues. Le sélecteur en haut à droite bascule entre 7, 30 et 90 jours.

Chaque journée agrège toutes les sessions rapportées par tous les opérateurs qui vous ont écrit ce jour-là. Deux lectures sont utiles :

le niveau de fond. Une part d’échecs stable et faible est banale : elle vient souvent d’un unique serveur mal configuré qui réessaie en boucle ;
les ruptures. Un pic d’échecs qui apparaît un jour donné et ne redescend pas est le vrai signal. Il correspond presque toujours à un changement de votre côté : renouvellement de certificat, bascule de MX, mise à jour du serveur.

Si vous suivez plusieurs domaines, les pastilles au-dessus du graphe le limitent à un seul domaine.

Lire la liste des rapports

Tableau des rapports TLS reçus, avec le domaine, l'organisation émettrice, la période et le compte de succès et d'échecs — Un rapport par opérateur et par jour. Cliquer sur une ligne déplie son détail.

Colonne	Ce qu’elle contient
Domaine	Le domaine concerné, parmi vos domaines vérifiés
Org	L’opérateur qui a produit le rapport, pas vous. Typiquement `google.com` ou `Microsoft Corporation`
Date	La période couverte, en pratique une journée
Succès	Nombre de sessions TLS établies sans erreur
Échecs	Nombre de sessions ayant échoué

Un compte élevé de succès chez un seul opérateur ne veut pas dire que tout va bien partout : il veut dire que cet opérateur là vous écrit beaucoup et que ça se passe bien avec lui.

Ouvrir le détail d’un rapport

Détail d'un rapport TLS déplié, avec la politique appliquée, la barre de répartition et le tableau des échecs — Le détail donne la politique appliquée, la répartition succès/échecs, puis la liste des échecs ligne par ligne.

La politique appliquée apparaît en tête de chaque bloc :

sts : l’expéditeur a trouvé et appliqué votre politique MTA-STS ;
tlsa : il a validé votre serveur via DANE, en s’appuyant sur DNSSEC ;
no-policy-found : aucune des deux. La connexion a bien pu être chiffrée, mais rien ne garantissait qu’elle devait l’être. C’est le cas par défaut tant que vous n’avez pas déployé MTA-STS.

Le tableau des échecs liste, pour chaque type d’erreur, le serveur émetteur avec son pays, votre MX concerné, et le nombre de sessions touchées. C’est cette dernière colonne qui hiérarchise le travail : trois sessions échouées depuis un serveur isolé ne méritent pas la même attention que quatre mille.

Comprendre les types d’échec

Type d’échec	Ce qui s’est passé	Où chercher
`starttls-not-supported`	Votre serveur n’a pas proposé `STARTTLS` du tout	Configuration du MTA. Le chiffrement est absent, pas cassé
`certificate-not-trusted`	La chaîne de certification n’a pas pu être validée	Cause la plus fréquente : un certificat intermédiaire manquant dans la chaîne servie
`certificate-expired`	Le certificat présenté était périmé	Renouvellement, et surveillance de l’échéance
`certificate-host-mismatch`	Le nom du certificat ne correspond pas au nom du MX contacté	Le certificat doit couvrir le nom d’hôte annoncé dans vos enregistrements MX, pas seulement votre domaine
`validation-failure`	Échec de validation ne rentrant dans aucune case plus précise	À corréler avec les journaux du serveur sur la même période
`handshake-failure`	Aucune version de protocole ou suite cryptographique en commun	Serveur trop restrictif, ou au contraire trop ancien face à un émetteur moderne
`sts-policy-fetch-error`	Votre politique MTA-STS n’a pas pu être récupérée	Le fichier `mta-sts.txt` ou son hôte HTTPS ne répond pas
`sts-policy-invalid`	Politique MTA-STS récupérée mais illisible	Syntaxe du fichier de politique
`sts-webpki-invalid`	Le certificat de l’hôte servant la politique MTA-STS est invalide	Certificat de `mta-sts.votredomaine`, pas celui du MX
`dane-required`	L’émetteur exigeait DANE et n’a pas pu l’appliquer	Enregistrements TLSA et signature DNSSEC
`dane-tlsa-invalid`	Enregistrement TLSA présent mais ne correspondant pas au certificat servi	Régénérer le TLSA après tout changement de certificat
`dnssec-invalid`	La chaîne DNSSEC n’a pas validé	Signature de la zone
`other`	L’émetteur n’a pas su qualifier l’erreur	Journaux serveur

Des échecs ne signifient pas des messages perdus Le chiffrement SMTP restant opportuniste par défaut, un échec TLS se termine le plus souvent par une remise en clair, pas par un rejet. Le message est arrivé, sans protection. C’est précisément ce que ces rapports servent à rendre visible.

Combien de temps vos rapports sont conservés

La durée pendant laquelle vous pouvez remonter dans l’historique dépend de votre offre. Quand la profondeur affichée est plus courte que celle de vos données, un bandeau vous l’indique en haut de la page, avec le nombre de jours effectivement consultables.

Ce que cela implique en pratique :

le graphe et la liste sont tronqués à cette profondeur, y compris quand vous demandez 90 jours dans le sélecteur. Ce n’est pas une absence de données, c’est une limite d’affichage ;
les rapports plus anciens ne sont pas perdus immédiatement. Ils cessent simplement d’être consultables. Une montée d’offre les rend à nouveau visibles sans avoir à attendre de nouveaux rapports ;
pour garder une trace au-delà, exportez ou notez ce qui compte au moment où vous le constatez. Un incident TLS analysé six mois plus tard ne se rejoue pas.

Si vous avez besoin d’un historique long pour des raisons de conformité ou d’audit, c’est le critère à regarder en premier au moment de choisir une offre, avant le nombre de domaines.

Quand rien n’arrive

Aucun rapport après 72 heures. Reprenez dans l’ordre :

l’enregistrement TXT répond bien, avec la commande dig donnée plus haut ;
le domaine est bien vérifié dans Sender Audit, pas seulement ajouté ;
du courrier vous a effectivement été adressé pendant la période. Sans trafic entrant, il n’y a rien à rapporter ;
ce trafic vient d’opérateurs qui implémentent TLS-RPT. Beaucoup de petits serveurs ne l’implémentent pas et n’enverront jamais rien, quoi que vous publiiez.

Le sous-domaine. Les rapports concernent le domaine exact que vous avez publié. Si vous recevez du courrier sur mail.mondomaine.fr avec ses propres MX, il lui faut son propre enregistrement _smtp._tls.

Pour aller plus loin

Le chiffrement TLS des emails, expliqué, sur le blog, pour le fonctionnement de STARTTLS lui-même
Vérificateur TLS-RPT, pour contrôler la publication d’un domaine sans compte