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 MTAs ne peuvent pas livrer les rapports, ils sont jetés
• Pas d'autorisation externe → si vous déléguez à un analyseur tiers, ses serveurs rejettent les rapports

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, récupère le TXT publié et résout l'autorisation externe si nécessaire.

Étape 2 : analyser les résultats

Le checker affiche :

Étape 3 : corriger les problèmes flaggé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 MTAs é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 MTAs é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é → pas d'autorisation externe nécessaire
• Le domaine est différent → vérifier la présence de [domaine].{_report._tls.[tiers]} (cross-domain authorization)
• L'URI https répond en HTTPS valide (sondage léger côté serveur)

Hygiene 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 : le RFC interdit le CNAME à cet emplacement. Publier un TXT direct.

Autorisation externe requise (rua_unauthorized_external)

Cause : l'adresse rua utilise un domaine différent du domaine TLS-RPT.

Solution : le domaine destinataire (par exemple uriports.com) doit publier :

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

Cet enregistrement autorise la réception des rapports pour captaindns.com.

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.

Cross-domain authorization et rua externe

Le RFC 8460 reprend la convention DMARC (RFC 7489 §7.1) : un domaine ne peut pas demander à un autre domaine de recevoir ses rapports sans son accord explicite.

Le mécanisme

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

Le domaine externe uriports.com doit publier :

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

Sans cet enregistrement, les MTAs émetteurs conformes refusent d'envoyer les rapports vers uriports.com (ils protègent les analyseurs tiers contre des abus de redirection).

Pièges courants

• Confusion avec DMARC : DMARC utilise _report._dmarc.[tiers], TLS-RPT utilise _report._tls.[tiers]. Vérifier le bon préfixe.
• Plusieurs domaines surveillés : un analyseur multi-tenants (Postmark, Uriports, Dmarcian, Valimail, Sendmarc) doit publier un enregistrement par domaine client (client1.com._report._tls.postmarkapp.com, client2.com._report._tls.postmarkapp.com, etc.).
• Wildcard interdit : il faut un enregistrement explicite par couple (domaine surveillé, domaine analyseur).
• Le checker signale automatiquement les rua externes sans autorisation publiée.

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 MTAs é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
• RFC 7489 §7.1 - Cross-domain reporting