Quelle différence entre validateur et record check TLS-RPT ?

Le validateur analyse une syntaxe que vous collez, avant publication DNS, sans lire la configuration déjà en place. Le record check interroge le DNS en direct pour vérifier l'enregistrement publié à _smtp._tls.domaine. Utilisez le validateur en amont, le record check en aval.

Pourquoi valider la syntaxe TLS-RPT hors ligne ?

Un enregistrement invalide est silencieusement ignoré par les serveurs émetteurs : vous ne recevez aucun rapport et le savez seulement quand un incident survient. Valider hors ligne permet de détecter les erreurs avant qu'elles n'impactent vos rapports d'échec TLS.

Quelles erreurs de syntaxe TLS-RPT sont les plus courantes ?

Les erreurs typiques : version absente ou incorrecte (TLSRPT1 au lieu de TLSRPTv1), balise rua absente, schéma mailto: ou https: oublié devant l'URI, adresse email mal formée, et tag inconnu hérité de DMARC comme ruf= qui n'existe pas pour TLS-RPT.

Faut-il une autorisation pour envoyer les rapports vers un autre domaine ?

Non. Contrairement à DMARC, TLS-RPT n'exige aucun enregistrement d'autorisation côté destinataire pour un rua externe : la RFC 8460 a écarté ce mécanisme. Une URI pointant vers un service tiers est donc valide telle quelle, et le validateur ne rejette jamais un enregistrement à cause d'un rua externe.

Quelle différence entre URIs mailto et https ?

Les URIs mailto reçoivent les rapports en pièces jointes email (JSON compressé gzip). Les URIs https reçoivent les rapports via HTTP POST sur un endpoint webhook. mailto est plus simple à déployer, https permet un traitement automatisé.

Comment corriger une erreur 'version invalide' ?

La version doit être exactement v=TLSRPTv1 (sensible à la casse), en première position du record. Vérifiez la casse, les espaces et l'absence de caractère parasite. v=TLSRPT1 ou v=tlsrptv1 sont rejetés.

Faut-il aussi déployer MTA-STS avec TLS-RPT ?

Oui, fortement recommandé. MTA-STS applique le chiffrement TLS, TLS-RPT vous informe quand l'application échoue. Sans TLS-RPT, vous ne saurez pas si des serveurs externes ne parviennent pas à se connecter en TLS à votre domaine.

Comment valider la syntaxe TLS-RPT pour Microsoft 365 et Google Workspace ?

Collez votre enregistrement TLS-RPT dans le validateur. La syntaxe est identique quel que soit le fournisseur. Pour Microsoft 365 ou Google Workspace, l'enregistrement doit être publié à _smtp._tls.captaindns.com une fois validé. Combinez avec MTA-STS pour forcer le chiffrement.

TLS-RPT Validator gratuit - Syntaxe hors ligne

Pourquoi utiliser un validateur hors ligne

Un validateur de syntaxe TLS-RPT analyse votre enregistrement sans publier ni interroger le DNS. Cette approche hors ligne couvre quatre 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 hors ligne → Reproduisez et corrigez une erreur sans dépendre du DNS public, par exemple sur un enregistrement de pré-production qui n'est pas encore publié.
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:, et absence de tag inconnu. La validation tourne sur nos serveurs : l'enregistrement que vous collez est transmis à CaptainDNS pour être analysé. Rien n'est publié en revanche, aucune requête DNS n'est émise et aucune URI rua n'est contactée.

Comment utiliser ce validateur en 2 é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 ne lit aucune source externe : seul le texte que vous fournissez est analysé.

Étape 2 : 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
Identification des URIs externes	Aucune	Automatique
Détection valeur publiée	Statique	État réel
Données envoyées au serveur	L'enregistrement collé	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 réel

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.

Un seul champ, un seul mode

Le formulaire n'expose qu'une zone de saisie : l'enregistrement TLS-RPT lui-même. Ni domaine, ni second mode. Ce qui est analysé :

Version TLSRPTv1 exacte et en première position
Présence de la balise rua=
Format des URIs (mailto: ou https:)
Adresses email bien formées dans les URIs mailto:
Tags inconnus signalés en avertissement

Ce dépouillement vient de la RFC 8460. DMARC réclame un enregistrement d'autorisation _report._dmarc chez le destinataire dès que les rapports partent vers un autre domaine ; le §7 de la RFC 8460 a délibérément écarté ce mécanisme pour TLS-RPT. Il n'y a donc aucun domaine à confronter à vos URIs rua : une adresse chez un fournisseur tiers de collecte est valide telle quelle.

Pour savoir lesquelles de vos URIs déjà publiées sortent de votre domaine, c'est le record check qui les repère, à partir du domaine interrogé.

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@)
Aucune autorisation côté destinataire requise, même pour une adresse sur un autre 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)
Aucune autorisation côté destinataire requise, même pour un hôte sur un autre domaine que l'enregistrement

URIs externes (rua vers un autre domaine)

Quand une URI pointe vers un domaine différent de celui analysé (par exemple un service tiers de collecte de rapports), TLS-RPT n'exige aucune autorisation côté destinataire :

Contrairement à DMARC et son enregistrement _report._dmarc, la RFC 8460 ne définit aucun mécanisme de vérification : son §7 a délibérément écarté toute autorisation cross-domain
Une URI externe est donc valide telle quelle ; les serveurs émetteurs envoient les rapports sans contrôle préalable côté destinataire

Le validateur ne les rejette donc jamais. Il ne les distingue pas non plus des autres : sans domaine de référence, il n'a rien à quoi les comparer.

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

URI externe : ce n'est pas une erreur

À savoir : une URI rua pointant vers un autre domaine (service tiers de collecte) est parfaitement valide. Contrairement à DMARC, TLS-RPT n'impose aucun enregistrement d'autorisation côté destinataire : le validateur ne rejette jamais un record à cause d'un rua externe.

Vous pouvez donc pointer en toute confiance vers un fournisseur tiers :

v=TLSRPTv1; rua=mailto:tls-reports@uriports.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: enforce une fois les problèmes résolus

Outils complémentaires et ressources

Outil	Quand l'utiliser
TLS-RPT record check	Audit en direct 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)
Considérations de sécurité - rua externe (§7)