Pourquoi utiliser un validateur offline
Un validateur de syntaxe TLS-RPT analyse votre enregistrement sans publier ni interroger le DNS. Cette approche hors ligne couvre trois cas d'usage clés que l'audit en direct ne peut pas traiter.
Cas d'usage typiques :
- Avant déploiement → Validez un brouillon avant publication DNS, pour éviter un enregistrement silencieusement ignoré par les MTA.
- Validation d'un brouillon → Vérifiez la syntaxe d'un enregistrement copié depuis un générateur, un wiki interne ou un template partagé.
- Débogage offline → Reproduisez et corrigez une erreur sans toucher au DNS public, par exemple en environnement isolé ou pré-production.
- Revue de configuration → Examinez un enregistrement reçu d'un partenaire ou exporté d'un outil tiers avant de l'appliquer.
Le validateur applique la spécification RFC 8460 sur la syntaxe : version TLSRPTv1, balise rua, format des URIs mailto: et https:, autorisation cross-domain et absence de tag inconnu. Aucune requête DNS n'est effectuée. Vos données restent dans votre navigateur.
Comment utiliser ce validateur en 3 étapes
Étape 1 : coller l'enregistrement
Copiez la valeur de votre enregistrement TLS-RPT dans le champ prévu :
v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Vous pouvez coller un brouillon, un enregistrement existant ou la sortie d'un générateur. Le validateur n'effectue aucune connexion réseau pour cette étape.
Étape 2 : ajouter un domaine (optionnel)
Saisir un domaine active la vérification d'autorisation cross-domain. Le validateur passe en mode record_and_domain et analyse chaque URI externe pour vérifier qu'un enregistrement TLSRPT d'autorisation existe côté destinataire.
Sans domaine, seule la syntaxe pure est analysée (mode record_only).
Étape 3 : analyser le verdict
Les résultats sont classés par niveau de gravité :
- Erreur → Problème bloquant, l'enregistrement sera ignoré ou rejeté par les serveurs émetteurs
- Avertissement → Fonctionnel mais amélioration recommandée
- Valide → Syntaxe conforme RFC 8460
Corrigez chaque alerte avant de publier votre enregistrement dans le DNS public.
Validator ou record check : quand utiliser chaque outil
Les deux outils sont complémentaires. Ils ne se remplacent pas : ils interviennent à des moments différents du cycle de vie d'un enregistrement TLS-RPT.
| Dimension | Validator (cet outil) | Record check |
|---|---|---|
| Moment d'utilisation | Avant déploiement | Après déploiement |
| Lookup DNS | Aucun | Résolution _smtp._tls en direct |
| Source du record | Manuelle (collé) | DNS public |
| Vérification cross-domain | Optionnelle (via domain) | Systématique |
| Détection valeur publiée | Statique | État réel |
| Données envoyées au serveur | Aucune | Domaine analysé |
Workflow recommandé :
- Concevez l'enregistrement → validateur pour vérifier la syntaxe
- Publiez le TXT dans le DNS → attendez la propagation
- Record check pour confirmer l'état live
Le validateur détecte les erreurs de saisie avant publication. Le record check détecte les dérives et confirme que l'enregistrement servi par le DNS correspond bien à ce qui a été conçu.
Modes de validation
Le validateur prend en charge deux modes selon les champs renseignés.
Mode record_only
Vous collez uniquement l'enregistrement TLS-RPT. Validation pure de syntaxe :
- Version
TLSRPTv1exacte et en première position - Présence de la balise
rua= - Format des URIs (
mailto:ouhttps:) - Adresses email bien formées dans les URIs
mailto: - Tags inconnus signalés en avertissement
Aucune requête réseau. Idéal pour valider un brouillon avant publication.
Mode record_and_domain
Vous collez l'enregistrement et un domaine. En plus de la validation de syntaxe, le validateur effectue une vérification d'autorisation cross-domain pour les URIs externes :
- Détecte chaque URI dont le domaine diffère du domaine analysé
- Recherche l'enregistrement TLSRPT d'autorisation côté destinataire
- Signale les URIs externes non autorisées
Ce mode aide à détecter une configuration où vous pointez vers un fournisseur tiers (analyse de rapports managée) sans qu'il ait publié l'autorisation côté serveur.
Règles de syntaxe vérifiées
Le validateur applique les règles de la RFC 8460 §3 sur l'enregistrement TXT _smtp._tls.domaine :
| Champ | Règle |
|---|---|
| v | Doit être exactement TLSRPTv1 (sensible à la casse), en première position |
| rua | Requis, contient une ou plusieurs URIs séparées par , |
| Format global | Paires cle=valeur séparées par ; |
| Tags inconnus | Tolérés mais signalés en avertissement |
| Espaces | Tolérés autour du ; et après = |
Exemple valide :
v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Format des URIs rua
Chaque URI dans rua= doit utiliser un schéma reconnu :
| Schéma | Format | Usage |
|---|---|---|
mailto: | mailto:adresse@domaine | Rapports reçus en pièces jointes email |
https: | https://hote/chemin | Rapports postés sur un endpoint webhook |
Plusieurs URIs sont possibles, séparées par , :
v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com,https://api.captaindns.com/tlsrpt
Chaque URI reçoit les mêmes rapports agrégés (un par 24 heures et par expéditeur).
rua URIs : mailto vs https
Le choix entre mailto: et https: impacte la complexité de déploiement et le traitement des rapports.
URIs mailto
rua=mailto:tls-reports@captaindns.com
Caractéristiques :
- Rapports reçus en pièces jointes email (JSON compressé gzip)
- Configuration simple, aucun développement requis
- Adresse souvent dédiée (
tlsrpt@,reports@) - Pas d'autorisation cross-domain nécessaire si l'email est sur le même domaine que l'enregistrement
URIs https
rua=https://tlsrpt.captaindns.com/v1/report
Caractéristiques :
- Rapports envoyés par HTTP POST sur un endpoint webhook
- Permet un traitement automatisé en temps réel
- Nécessite un endpoint HTTPS valide (certificat reconnu)
- Pas d'autorisation cross-domain nécessaire si l'hôte est sur le même domaine que l'enregistrement
Cross-domain authorization
Quand une URI pointe vers un domaine différent de celui analysé (par exemple un service tiers de collecte de rapports), la RFC 8460 §3.3 impose une autorisation côté destinataire :
- Le destinataire publie un enregistrement TLSRPT à
[domaine-source]._report._tls.[domaine-destinataire] - Sans cette autorisation, les serveurs émetteurs n'enverront pas les rapports
Le validateur signale les URIs externes pour lesquelles cette autorisation manque, à condition d'avoir renseigné le champ domain.
Exemples invalides
- rua=tls-reports@captaindns.com
+ rua=mailto:tls-reports@captaindns.com
- rua=mailto:tlsrpt
+ rua=mailto:tls-reports@captaindns.com
- rua=http://tlsrpt.captaindns.com/report
+ rua=https://tlsrpt.captaindns.com/report
Erreurs de syntaxe courantes et corrections
Version absente ou incorrecte
Cause : balise v= manquante, ou valeur différente de TLSRPTv1.
Correction :
- rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
- v=TLSRPT1; rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
Balise rua manquante
Cause : l'enregistrement contient v=TLSRPTv1 sans aucune URI rua.
Correction : ajoutez au moins une URI :
- v=TLSRPTv1
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
URI mailto invalide
Cause : schéma mailto: oublié, adresse email mal formée ou tronquée.
Correction :
- v=TLSRPTv1; rua=tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
- v=TLSRPTv1; rua=mailto:tlsrpt@
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
URI https invalide
Cause : schéma http: au lieu de https:, ou URL incomplète.
Correction : seuls les endpoints HTTPS sont acceptés par la RFC 8460.
- v=TLSRPTv1; rua=http://tlsrpt.captaindns.com/report
+ v=TLSRPTv1; rua=https://tlsrpt.captaindns.com/report
Cross-domain non autorisé
Cause : une URI externe (autre domaine que celui analysé) pointe vers un destinataire qui n'a pas publié d'enregistrement TLSRPT d'autorisation.
Correction : demandez au fournisseur tiers de publier l'enregistrement d'autorisation, ou utilisez une URI sur votre propre domaine :
- rua=mailto:tls-reports@uriports.com
+ rua=mailto:tls-reports@captaindns.com
Tag inconnu
Cause : présence d'un tag non défini par la RFC 8460 (ruf=, par exemple, qui n'existe pas pour TLS-RPT contrairement à DMARC).
Correction : retirez le tag inconnu :
- v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com; ruf=mailto:forensic@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com
TLS-RPT et MTA-STS : déploiement combiné
TLS-RPT brille avec MTA-STS. Les deux protocoles forment un duo indissociable pour la sécurité du transport SMTP.
| Protocole | Rôle |
|---|---|
| MTA-STS | Applique le chiffrement TLS pour le courrier entrant |
| TLS-RPT | Rapporte les échecs et les anomalies de connexion TLS |
Pourquoi ensemble :
- MTA-STS sans TLS-RPT → vous appliquez le TLS mais ne savez pas si des serveurs y échouent silencieusement
- TLS-RPT sans MTA-STS → vous recevez des rapports utiles mais sans renforcement du chiffrement
- MTA-STS + TLS-RPT → vous appliquez ET mesurez, avec visibilité complète
Déploiement recommandé :
- Validez votre politique MTA-STS avec le MTA-STS Syntax Checker
- Validez votre enregistrement TLS-RPT avec ce validateur
- Publiez TLS-RPT en premier (pour collecter les rapports dès la phase testing de MTA-STS)
- Publiez MTA-STS en
mode: testing - Surveillez les rapports TLS-RPT pendant 2 à 4 semaines
- Passez MTA-STS en
mode: enforceune fois les problèmes résolus
Outils complémentaires et ressources
| Outil | Quand l'utiliser |
|---|---|
| TLS-RPT record check | Audit live de l'enregistrement publié dans le DNS |
| Monitoring TLS-RPT | Recevez et analysez automatiquement vos rapports TLS-RPT |
| TLS-RPT generator | Créer un enregistrement TLS-RPT conforme RFC 8460 |
| MTA-STS syntax checker | Valider la politique MTA-STS associée hors ligne |
| DMARC record check | Compléter la sécurité d'authentification email |
| Propagation DNS | Confirmer la propagation après publication |
Guides associés
- TLS-RPT : le guide complet pour surveiller le chiffrement TLS de vos emails - Comprendre le protocole et son intégration avec MTA-STS.
- Déployer TLS-RPT sur Microsoft 365, Google Workspace et OVHcloud - Procédure pas à pas par fournisseur.
- Analyser les rapports TLS-RPT : guide pratique - Lire et exploiter les rapports reçus.
Spécifications
- RFC 8460 - SMTP TLS Reporting (spécification officielle)
- RFC 8461 - MTA-STS (protocole compagnon)
- Format de l'enregistrement TLS-RPT (§3)
- Cross-domain authorization (§3.3)