Lisez l’enregistrement TLS-RPT qu’un domaine publie sur _smtp._tls, vérifiez-le selon la RFC 8460 et voyez exactement où partent ses rapports TLS. L’outil fonctionne gratuitement dans votre navigateur via DNS-over-HTTPS, sans inscription et sans rien enregistrer.
Créez un compte Unspam gratuit pour enregistrer vos résultats et relancer ces vérifications à tout moment, afin de repérer une configuration défaillante avant qu’elle ne vous coûte cher. Sans carte bancaire.
TLS-RPT est un enregistrement DNS qui demande aux serveurs de messagerie destinataires de vous dire comment s’est passé le chiffrement lorsqu’ils vous ont remis du courrier. Les serveurs compatibles envoient un résumé une fois par jour, indiquant combien de connexions ont négocié TLS avec succès et combien ont échoué, avec le motif. Le publier ne change rien à la remise de vos e-mails : c’est un canal de retour, pas une politique. Ce que cela vous apporte, c’est d’apprendre qu’un certificat a expiré, qu’un serveur de messagerie ne propose plus STARTTLS ou qu’une politique MTA-STS échoue, avant qu’un client ne vous le signale. L’enregistrement tient sur une ligne, il se trouve sur _smtp._tls sous votre domaine, et ce vérificateur le lit en entier, car contrairement à MTA-STS il n’y a pas de seconde moitié derrière un serveur web qu’un navigateur ne peut pas atteindre.
La version, qui doit venir en tout premier dans l’enregistrement et s’écrire exactement ainsi. La RFC 8460 la définit comme un texte sensible à la casse et demande aux expéditeurs d’écarter tout ce qui ne commence pas par v=TLSRPTv1 suivi d’un point-virgule. v=tlsrptv1 n’est donc pas une coquille aux conséquences esthétiques : c’est un enregistrement que personne ne lit.
Où vont les rapports. Le champ accepte une adresse ou une liste séparée par des virgules, et deux types seulement sont autorisés : mailto: pour une boîte aux lettres et https: pour un point de terminaison qui accepte un POST. Les rapports sont du JSON compressé en gzip et arrivent à peu près quotidiennement de chaque fournisseur compatible avec la norme.
Si un expéditeur trouve plus d’un enregistrement TLS-RPT sur ce nom, la RFC 8460 lui impose de traiter le domaine comme n’implémentant pas du tout TLS-RPT. Deux enregistrements ne sont pas une sécurité, c’est un interrupteur d’arrêt. C’est la même règle que pour SPF et DMARC, et la même erreur que l’on commet en ajoutant un second enregistrement au lieu de modifier le premier.
La norme prévoit un emplacement d’extension pour de futurs champs et demande aux expéditeurs d’ignorer tout champ qu’ils ne reconnaissent pas : une balise inconnue ne peut donc jamais casser un enregistrement. Sur l’ensemble des fournisseurs de boîtes aux lettres, relais et hébergeurs contre lesquels ce vérificateur a été testé, aucun enregistrement réel ne porte autre chose que la version et rua.
v=tlsrptv1 ou v=TLSRPTV1 ont l’air corrects et ne collectent rien. L’enregistrement est écarté avant même d’être analysé, il n’y a donc d’erreur nulle part : les rapports n’arrivent tout simplement jamais, et le seul symptôme est un silence dont vous ignoriez qu’il était anormal.
C’est en général le résultat d’un nouvel enregistrement ajouté pendant une migration au lieu de modifier l’ancien. Cela coupe les rapports plutôt que de les envoyer aux deux. Gardez un seul enregistrement listant les deux destinations dans son rua.
La virgule sépare la liste des destinations : une virgule non encodée à l’intérieur d’une adresse la coupe en deux. Le point d’exclamation est le suffixe de limite de taille de DMARC, que TLS-RPT ne connaît pas, et il doit s’écrire %21. Les deux doivent être encodés en pourcentage et les deux abîment la liste des destinations sans prévenir.
Seuls mailto et https existent. Un point de terminaison en http simple n’est pas un schéma qu’un expéditeur utilisera : les rapports sont abandonnés plutôt que rétrogradés.
Les rapports TLS arrivent en JSON compressé en gzip, chaque jour, de chaque fournisseur compatible avec la norme. Dirigés vers une boîte partagée, ils deviennent du bruit en une semaine. Dirigez-les vers une boîte ou un service d’analyse qui les traite, sinon l’enregistrement ne sert à rien.
Il rend compte, il n’exige rien. Si vous voulez que les serveurs destinataires imposent TLS lorsqu’ils vous remettent du courrier, cela relève de MTA-STS ou de DANE. TLS-RPT est le moyen de savoir si l’un des deux fonctionne, et c’est pourquoi ils sont généralement déployés ensemble.
