TLS-RPT Checker

Pourquoi vérifier votre TLS-RPT

Le transport SMTP utilise TLS de façon opportuniste : si la négociation échoue, la connexion bascule en clair sans alerte. Vos emails partent en clair, et personne ne vous prévient. Pire, un MITM peut activement supprimer STARTTLS pour forcer cette bascule.

TLS-RPT (RFC 8460) ne corrige pas la faille de chiffrement (c'est MTA-STS qui s'en charge), mais il vous donne enfin de la visibilité. Chaque MTA émetteur qui échoue à établir TLS envoie un rapport JSON à l'adresse rua que vous publiez. Sans ce mécanisme, vous êtes aveugle.

Vérifier la configuration avant de l'oublier dans un coin du DNS est essentiel :

• Enregistrement absent → vous ne savez rien des échecs TLS, audit trail nul
• URI rua invalide → les MTA ne peuvent pas livrer les rapports, ils sont jetés
• Enregistrements multiples → les MTA émetteurs ignorent un TLS-RPT dupliqué, aucun rapport n'est envoyé

Cas d'usage courants :

• Après publication → confirmer que l'enregistrement est correctement propagé
• Audit de sécurité mail → valider la couverture TLS et la visibilité des échecs
• Avant MTA-STS enforce → s'assurer que TLS-RPT collecte les rapports pendant la phase testing

Comment utiliser ce checker en 3 étapes

Étape 1 : entrer le domaine à analyser

Saisissez le domaine exactement comme il apparaît dans vos adresses email :

• captaindns.com (domaine principal)
• marketing.captaindns.com (sous-domaine si vous envoyez depuis un sous-domaine)

L'outil interroge automatiquement _smtp._tls.domaine et récupère le TXT publié.

Étape 2 : analyser les résultats

Le checker affiche :

Étape 3 : corriger les problèmes signalés

Les résultats sont classés par gravité :

• Critique → l'enregistrement est invalide, aucun rapport ne sera envoyé
• Avertissement → fonctionne, mais expose à un risque ou à une couverture partielle
• Info → bonne pratique non bloquante (tag inconnu, MTA-STS absent)

Corrigez le DNS, attendez la propagation, puis relancez le checker.

Qu'est-ce que TLS-RPT

TLS-RPT (SMTP TLS Reporting, RFC 8460) est un mécanisme qui :

1. Publie une adresse de rapport dans le DNS pour le domaine récepteur
2. Demande aux MTA émetteurs d'envoyer un rapport JSON quand TLS échoue
3. Fournit une trace des échecs de chiffrement (certificat expiré, downgrade, mismatch)

L'architecture est volontairement minimaliste : un seul enregistrement TXT publié sur _smtp._tls.domaine, contenant la version et une ou plusieurs URIs rua=.

Exemple d'enregistrement TLS-RPT :

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

Cet enregistrement indique aux MTA émetteurs (Gmail, Outlook, etc.) d'envoyer leurs rapports d'échec TLS à tls-reports@captaindns.com.

Différence avec MTA-STS : TLS-RPT est le compagnon de MTA-STS, pas une alternative. MTA-STS impose le chiffrement TLS, TLS-RPT signale les échecs. Les deux protocoles sont publiés à des endroits distincts (_mta-sts.domaine pour STS, _smtp._tls.domaine pour RPT) et fonctionnent en tandem.

Ce que vérifie le checker

Cinq dimensions sont analysées en parallèle pour produire un score 0-100 :

Enregistrement DNS publié

Syntaxe de l'enregistrement

URIs de rapport

Qualité du rua

• Le domaine de l'URI rua correspond au domaine vérifié (destination interne)
• Le domaine est différent (destination externe) : valide sans aucune autorisation côté destinataire
• L'URI https répond en HTTPS valide (sondage léger côté serveur)

Hygiène globale

• Présence simultanée de MTA-STS (bonus +2 au score)
• Pas de tag inconnu pollué dans l'enregistrement
• Politique cohérente avec le déploiement mail du domaine

Diagnostics courants et solutions

Enregistrement absent (missing_record)

Cause : aucun TXT n'existe sur _smtp._tls.captaindns.com.

Solution : publier

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

Tag rua manquant (rua_missing)

Cause : l'enregistrement contient v=TLSRPTv1 mais aucune destination.

Solution : ajouter au moins une URI : v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Sans rua, aucun MTA n'enverra de rapport.

URI rua invalide (rua_invalid_uri)

Cause : l'URI est mal formée (manque mailto:, espace dans l'adresse, schéma inconnu).

Exemples de correction :

- rua=tls-reports@captaindns.com         # Manque mailto:
+ rua=mailto:tls-reports@captaindns.com

- rua=mailto: tls-reports@captaindns.com # Espace interdit après mailto:
+ rua=mailto:tls-reports@captaindns.com

Plusieurs enregistrements (multiple_records)

Cause : plus d'un TXT TLS-RPT existe sur _smtp._tls.captaindns.com.

Solution : RFC 8460 §3 impose un seul enregistrement. Identifiez les doublons, conservez celui à appliquer, supprimez les autres.

CNAME sur _smtp._tls (cname_on_smtp_tls)

Cause : _smtp._tls.domaine est un CNAME vers une autre destination.

Solution : aucune RFC n'interdit le CNAME à cet emplacement. Le checker le remonte en avertissement, pas en erreur : Microsoft 365 ignore un _smtp._tls en alias. Publier un TXT direct reste la configuration sûre.

MTA-STS absent (mta_sts_companion_missing)

Cause : TLS-RPT est publié mais MTA-STS ne l'est pas.

Solution : déployer MTA-STS pour donner du sens aux rapports TLS-RPT. Voir le MTA-STS Checker et le guide complet.

Envoyer les rapports vers un domaine tiers

Vous pouvez diriger vos rapports TLS-RPT vers un domaine que vous ne contrôlez pas, par exemple un analyseur tiers. Contrairement à DMARC, la RFC 8460 ne définit aucun enregistrement d'autorisation côté destinataire : un rua vers un domaine tiers fonctionne sans publication supplémentaire.

Le mécanisme

Votre domaine : captaindns.com URI rua : mailto:tls-reports@uriports.com

Aucun enregistrement n'est requis sur uriports.com. Le rapport est envoyé directement. La confiance repose sur deux garde-fous prévus par la RFC 8460 §7 :

• mailto : le rapport est signé en DKIM par le MTA émetteur, ce qui authentifie son origine.
• https : le domaine de destination contrôle son propre point de collecte (possession DNS).

La RFC 8460 §7 a délibérément écarté tout mécanisme de vérification supplémentaire, le risque d'amplification étant plus faible qu'avec DMARC.

Pièges courants

• Ne pas transposer le mécanisme DMARC : DMARC exige un enregistrement [domaine]._report._dmarc.[tiers] pour autoriser un rua vers un domaine tiers. TLS-RPT n'a pas d'équivalent. Publier un enregistrement _report._tls est inutile et n'est attendu par aucun MTA.
• Vérifier la destination : assurez-vous simplement que l'adresse mailto ou l'URL https de collecte est correcte et opérationnelle.

TLS-RPT et MTA-STS : déploiement combiné

Les deux protocoles forment une défense en profondeur :

Ordre de déploiement recommandé

1. Publier TLS-RPT en premier pour collecter les rapports
2. Déployer MTA-STS en mode testing sans bloquer la livraison
3. Observer 2 à 4 semaines les rapports TLS-RPT pour identifier les MX problématiques
4. Passer MTA-STS en mode enforce quand les rapports sont propres
5. Maintenir TLS-RPT indéfiniment pour la surveillance continue

Sans MTA-STS : TLS-RPT signale les échecs mais aucune politique ne contraint les MTA émetteurs à utiliser TLS. Vous voyez les problèmes sans pouvoir les empêcher.

Sans TLS-RPT : MTA-STS impose TLS mais vous ne saurez jamais qu'un MTA légitime est bloqué par votre politique. Risque de non-livraison silencieuse.

Outils complémentaires et ressources

Ressources :

• TLS-RPT : le guide complet
• Configurer TLS-RPT sur Microsoft 365, Google Workspace et OVHcloud
• Analyser les rapports TLS-RPT au quotidien
• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - MTA-STS