Vérificateur de dossiers TLS-RPT gratuit

Vérificateur d'enregistrement TLS-RPT

Outil gratuit de vérification TLS-RPT : vérifiez instantanément l'enregistrement DNS de rapport TLS SMTP de votre domaine, assurez-vous qu'il est conforme à la norme RFC 8460, vérifiez qu'il correspond bien à votre politique MTA-STS et assurez-vous que vos adresses de rapport peuvent effectivement recevoir des rapports.

Pourquoi vérifier votre enregistrement TLS-RPT ?

Même un serveur de messagerie correctement configuré peut, sans le laisser paraître, ne pas parvenir à acheminer les messages via TLS. Un enregistrement TLS-RPT est le seul moyen de s'en rendre compte lorsque cela se produit.

Détecter rapidement les défaillances TLS

Identifiez précisément les moments où les serveurs de messagerie ne parviennent pas à établir une connexion cryptée avec votre domaine, avant que cela ne se transforme en problème de distribution.

Vérifiez la configuration de votre MTA-STS

TLS-RPT signale toute défaillance de politique ou de connexion due à l'application du protocole MTA-STS. Cet outil analyse votre politique MTA-STS en temps réel afin que vous puissiez visualiser les appariements.

Vérifier que les rapports peuvent être reçus

Une adresse de notification ne sert à rien si le courrier ne peut pas y parvenir. Nous vérifions que chaque destinataire RUA dispose bien d'un lieu où les notifications peuvent être remises.

Comment utiliser l'outil de vérification TLS-RPT

Une requête TLS-RPT ne prend que quelques secondes. Suivez ces trois étapes pour vérifier la configuration de vos rapports TLS SMTP.

Saisissez votre nom de domaine. Saisissez votre domaine racine (par exemple : example.com) - pas besoin d'ajouter le _smtp._tls préfixe, nous nous en chargeons automatiquement.

Choisissez un résolveur et vérifiez. Choisissez Google, Cloudflare, OpenDNS ou Quad9, puis appuyez sur Entrée ou cliquez sur « Vérifier l'enregistrement » pour interroger le DNS en temps réel depuis notre serveur.

Vérifiez les résultats. Nous validons les balises « version » et « rua » au regard de la norme RFC 8460, nous vérifions votre politique MTA-STS associée et nous nous assurons que chaque destination de rapport est accessible.

Qu'est-ce qu'un enregistrement TLS-RPT ?

Le protocole SMTP TLS Reporting (TLS-RPT) est une norme de messagerie électronique définie dans la RFC 8460 qui permet aux propriétaires de domaines de recevoir des rapports concernant les échecs de remise des e-mails via une connexion TLS chiffrée. Il fonctionne en complément du protocole MTA-STS pour mettre en évidence des problèmes — échec de la validation des certificats, attaques par « downgrade », protocole STARTTLS non pris en charge — qui, sans cela, passeraient inaperçus.

Un seul enregistrement TXT

Publié le _smtp._tls.yourdomain.com, il indique aux serveurs de messagerie destinataires où envoyer les rapports globaux concernant les tentatives de connexion TLS.

Signaler, et non faire respecter la loi

TLS-RPT ne bloque ni n'impose quoi que ce soit en soi. Il s'agit uniquement d'un canal de retour d'information, c'est-à-dire la couche de visibilité qui s'associe à MTA-STS.

Gratuit et sans effort

Il suffit de deux balises. Ce n'est pas obligatoire, mais c'est une bonne pratique qui ne coûte rien et qui comble une véritable lacune.

_smtp._tls.votredomaine.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
; v -> identifie l'enregistrement comme TLS-RPT (RFC 8460)
; rua -> adresse à laquelle sont envoyés les rapports TLS agrégés

TLS-RPT ou MTA-STS : quelle est la différence ?

Le protocole MTA-STS (Mail Transfer Agent Strict Transport Security) est un mécanisme d'application : il indique aux serveurs de messagerie émetteurs que votre domaine exige une connexion valide et chiffrée par TLS, et bloque la transmission via des connexions non chiffrées ou mal configurées. TLS-RPT est un mécanisme de signalement : il n’impose aucune contrainte en soi, mais indique aux serveurs expéditeurs où signaler les tentatives de connexion TLS réussies ou ayant échoué, y compris celles causées par votre politique MTA-STS.

Ces deux éléments sont conçus pour fonctionner de concert : MTA-STS impose le chiffrement, tandis que TLS-RPT vous fournit la boucle de rétroaction nécessaire pour savoir si cette imposition entraîne des problèmes de livraison. C'est pourquoi cet outil de vérification examine également votre politique MTA-STS : vous pouvez ainsi vous assurer que les deux aspects sont bien alignés. Vous pouvez approfondir l'aspect « imposition » grâce à notre outil de vérification des enregistrements MTA-STS.

Explication des balises TLS-RPT

Chaque enregistrement TLS-RPT est constitué d'un petit ensemble de balises. Voici la signification de chacune d'entre elles.

Version (obligatoire)

Identifie l'enregistrement comme un enregistrement TLS-RPT. Il doit s'agir de la première balise et sa valeur doit toujours être définie sur TLSRPTv1.

rua=

URI du rapport agrégé (obligatoire)

Où sont envoyés les rapports TLS agrégés. Accepte une mailto: adresse, un https:// point de terminaison, ou une liste des deux séparés par une virgule.

Problèmes courants liés à TLS-RPT et comment les résoudre

Voici les problèmes qui surviennent généralement lors de la configuration d'un TLS-RPT, ainsi que les conséquences de chaque situation pour votre domaine.

Aucun enregistrement trouvé

Rien dans _smtp._tls

Aucun enregistrement TXT n'existe sur l'hôte concerné ; vous ne recevez donc aucun rapport d'échec de transmission TLS.

Publiez un enregistrement TXT sur _smtp._tls.votredomaine.com avec des balises v= et rua= valides.

Balise « v= » incorrecte

Non reconnu comme TLS-RPT

L'enregistrement ne commence pas par « v=TLSRPTv1 » ; les serveurs de messagerie ne le traiteront donc pas comme un enregistrement TLS-RPT.

Définissez v=TLSRPTv1 comme la première balise exacte de l'enregistrement.

rua= manquant ou non valide

Les rapports n'ont nulle part où aller

Aucune destination de rapport n'est définie, ou l'URI « mailto/https » est incorrect, ce qui empêche la transmission des rapports.

Ajoutez au moins une URI « mailto: » ou « https: » valide, puis vérifiez que le destinataire peut bien la recevoir.

Plusieurs enregistrements

Plus d'un enregistrement TLS-RPT

La présence de deux enregistrements TLS-RPT ou plus sur un même hôte n'est pas autorisée par la norme RFC 8460 et peut entraîner des erreurs de validation.

Regrouper le tout en un seul enregistrement TLS-RPT, avec toutes les destinations dans une seule balise « rua ».

Comment lire vos rapports TLS-RPT

Une fois votre enregistrement mis en ligne, les serveurs de réception commenceront à envoyer des rapports agrégés périodiques à votre adresse RUA. Voici ce qu'ils contiennent.

Détails de la politique

Le type de politique en vigueur (par exemple, « sts », « no-policy-found ») pour le domaine d'origine concerné par le rapport.

Chiffres récapitulatifs

Nombre total de tentatives de connexion TLS réussies et échouées au cours de la période considérée, qui correspond généralement à une période de 24 heures.

Détails de l'échec

Types d'échecs classés par catégorie (certificat expiré, nom d'hôte non correspondant, STARTTLS non pris en charge) avec des exemples d'adresses IP sources.

Les rapports JSON bruts sont difficiles à lire lorsqu'ils sont nombreux, surtout lorsque vous les recevez de dizaines de fournisseurs de messagerie différents. La plateforme PowerDMARC analyse automatiquement les rapports TLS-RPT pour les présenter sous forme de tableau de bord lisible, aux côtés de vos données DMARC, SPF et MTA-STS.

Comment publier un enregistrement TLS-RPT

Connectez-vous à l'interface de votre fournisseur DNS et ajoutez un nouvel enregistrement TXT avec les valeurs suivantes.

Hôte / Nom

_smtp._tls

Type

TXT

TTL

3 600 (par défaut)

Multiplication

Jusqu'à 48 heures

Valeur

v=TLSRPTv1 ; rua=mailto:[email protected]

La propagation des modifications DNS peut prendre jusqu'à 48 heures, même si la plupart des fournisseurs effectuent la mise à jour en quelques heures. Une fois les modifications effectives, utilisez l'outil de vérification ci-dessus pour vous assurer qu'elles ont bien été publiées.

Foire aux questions

Le protocole TLS-RPT est-il identique au protocole DMARC ?

Non. Les rapports DMARC signalent les échecs d'authentification (SPF/DKIM) pour les messages envoyés depuis votre domaine. Les rapports TLS-RPT signalent spécifiquement les échecs d'établissement d'une connexion TLS chiffrée lors de la remise du courrier à votre domaine. Il s'agit de normes complémentaires mais indépendantes.

Les données relatives à mon nom de domaine sont-elles transmises à vos serveurs ?

Le nom de domaine que vous saisissez est envoyé à notre serveur, qui effectue pour vous la recherche DNS auprès du résolveur public que vous avez choisi — il s'agit de la même requête que n'importe qui pourrait effectuer avec un dig commande. Nous n'enregistrons ni ne conservons les noms de domaine que vous consultez, ni les enregistrements renvoyés.

Ai-je besoin de MTA-STS pour utiliser TLS-RPT ?

Non, TLS-RPT peut être déployé de manière autonome. Il s'avère toutefois particulièrement utile lorsqu'il est associé à MTA-STS, car il signale toute défaillance de connexion ou de politique résultant de l'application de MTA-STS. Cet outil de vérification examine également votre politique MTA-STS afin que vous puissiez voir dans quelle mesure les deux sont alignés.

Le protocole TLS-RPT est-il obligatoire ?

Non, le TLS-RPT est facultatif et n'est exigé par aucun des principaux fournisseurs de messagerie. Il s'agit d'un moyen gratuit et peu contraignant d'obtenir une visibilité sur les problèmes de livraison TLS qui, sans cela, resteraient invisibles, et il est considéré comme une bonne pratique au même titre que le DMARC, l'SPF, le DKIM et le MTA-STS.

Puis-je utiliser plusieurs adresses RUA ?

Oui. Vous pouvez indiquer plusieurs destinations séparées par des virgules, en mélangeant des URL de type « mailto: » et « https: » — par exemple rua=mailto:[email protected],https://reports.example.com/tlsrpt. Cet outil vérifie chacune d'entre elles et s'assure que les adresses e-mail destinataires peuvent effectivement recevoir des messages.

Est-il possible d'envoyer des rapports vers un domaine différent du mien ?

Oui. Contrairement à DMARC, la norme RFC 8460 ne définit pas d'enregistrement d'autorisation de destination externe pour TLS-RPT ; vous pouvez donc configurer rua pour qu'il pointe vers un processeur tiers (tel que PowerDMARC) sans aucune configuration DNS supplémentaire. Cet outil signale les destinations externes à des fins de clarté, mais celles-ci sont tout à fait valides.

Pourquoi mon enregistrement TLS-RPT apparaît-il comme « introuvable » ?

Soit l'enregistrement n'a pas encore été publié, soit les modifications du DNS ne se sont pas encore entièrement propagées, soit l'enregistrement a été ajouté sur le mauvais hôte — il doit correspondre exactement à _smtp._tls.yourdomain.com, et pas seulement votredomaine.com.

Puis-je utiliser un point de terminaison HTTPS à la place de l'e-mail pour les rapports ?

Oui. La spécification RFC 8460 prend en charge à la fois les URI de rapport « mailto: » et « https: ». Un point de terminaison https doit accepter les requêtes HTTP POST contenant le rapport sous forme de charge utile JSON compressée au format gzip — une méthode généralement utilisée par les grandes entreprises ou les plateformes telles que PowerDMARC qui traitent automatiquement les rapports.

Automatisez l'authentification de vos e-mails

PowerDMARC surveille vos enregistrements DMARC, SPF, DKIM, BIMI, MTA-STS et TLS-RPT depuis un seul tableau de bord, et vous envoie des alertes dès qu'un problème survient.

Réserver une démonstration Commencez votre essai de 15 jours