TLS-RPT : le guide complet pour monitorer la sécurité TLS de vos emails

Q: Comment configurer un enregistrement TLS-RPT ?

Publiez un enregistrement DNS TXT à _smtp._tls.captaindns.com avec la valeur v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com . Utilisez un générateur TLS-RPT pour créer l'enregistrement, puis ajoutez-le dans votre zone DNS. Les premiers rapports arrivent sous 24 à 48 heures.

Par CaptainDNS
Publié le 10 février 2026

TLS-RPT : surveiller les échecs de chiffrement TLS dans la livraison email

TL;DR

TLS-RPT (RFC 8460) vous envoie un rapport quotidien sur chaque échec de chiffrement TLS détecté par les serveurs qui vous envoient des emails
Sans TLS-RPT, vous ne savez pas si vos emails arrivent en clair à cause d'un certificat expiré, d'un MX mal configuré ou d'une attaque downgrade
Un seul enregistrement DNS TXT à publier : _smtp._tls.captaindns.com avec la directive v=TLSRPTv1; rua=mailto:...
TLS-RPT est le compagnon indispensable de MTA-STS : il vous donne la visibilité nécessaire avant de passer en mode enforce

Votre domaine utilise MTA-STS ou envisage de l'activer ? Vous avez configuré STARTTLS sur vos serveurs de messagerie ? Dans les deux cas, une question reste sans réponse : comment savoir si le chiffrement TLS fonctionne réellement lors de la livraison de vos emails ?

C'est exactement le problème que résout TLS-RPT. Défini dans la RFC 8460, SMTP TLS Reporting est un mécanisme qui permet aux serveurs émetteurs (Gmail, Microsoft, Yahoo et tous les fournisseurs qui le supportent) de vous envoyer des rapports détaillés sur les échecs de négociation TLS qu'ils rencontrent en essayant de livrer des emails à votre domaine.

Ce guide vous explique ce qu'est TLS-RPT, comment il fonctionne, comment le configurer en quelques minutes, et comment interpréter les rapports que vous recevrez. Que vous soyez administrateur système, DevOps ou responsable de l'infrastructure email, vous trouverez ici tout ce qu'il faut pour déployer TLS-RPT sur votre domaine.

Qu'est-ce que TLS-RPT ?

TLS-RPT, pour SMTP TLS Reporting, est un standard internet (RFC 8460) publié en septembre 2018. Son rôle est simple : permettre au propriétaire d'un domaine de recevoir des rapports sur les tentatives de connexion TLS qui échouent quand des serveurs essaient de lui livrer des emails.

Concrètement, quand Gmail tente d'envoyer un email à contact@captaindns.com, il vérifie si le serveur de réception supporte TLS et si la négociation TLS réussit. Si quelque chose échoue (certificat expiré, STARTTLS non supporté, politique MTA-STS non respectée), Gmail enregistre cet échec. Une fois par jour, il agrège tous les échecs et envoie un rapport JSON à l'adresse spécifiée dans votre enregistrement TLS-RPT.

Pourquoi TLS-RPT est indispensable ?

Sans TLS-RPT, vous êtes aveugle sur la qualité du chiffrement de vos emails entrants :

Un certificat TLS expire sur votre serveur MX → les emails continuent d'arriver (en clair si MTA-STS n'est pas en mode enforce), mais vous ne le savez pas
Un MX secondaire ne supporte pas STARTTLS → les emails vers ce MX transitent sans chiffrement
Une attaque man-in-the-middle force un downgrade → impossible à détecter sans rapports

TLS-RPT comble cette lacune. Vous recevez chaque jour un bilan précis : combien de connexions TLS ont réussi, combien ont échoué, et pourquoi elles ont échoué.

Schéma comparatif : sans TLS-RPT vs avec TLS-RPT, visibilité sur les échecs TLS

Quelle différence entre TLS-RPT et DMARC reporting ?

Les rapports DMARC (RUA/RUF) et les rapports TLS-RPT couvrent des domaines différents :

Critère	DMARC Reporting	TLS-RPT
Ce qu'il surveille	L'authentification des emails (SPF, DKIM, alignement)	Le chiffrement du transport (TLS)
RFC	RFC 7489	RFC 8460
Enregistrement DNS	`_dmarc.domaine`	`_smtp._tls.domaine`
Format du rapport	XML (agrégé) ou texte (forensic)	JSON
Fréquence	Configurable (souvent 24h)	Toujours 24h
Protocole	Authentification de l'expéditeur	Sécurité du canal de transport

Les deux sont complémentaires : DMARC vérifie qui envoie l'email, TLS-RPT vérifie comment l'email est transporté. Un domaine sécurisé a besoin des deux.

Comment fonctionne TLS-RPT ?

Le mécanisme TLS-RPT s'intègre dans le flux normal de livraison email :

1. Publication de l'enregistrement DNS

Vous publiez un enregistrement TXT à _smtp._tls.captaindns.com qui contient l'adresse où recevoir les rapports.

2. Détection par le serveur émetteur

Quand Gmail (ou tout autre serveur compatible) veut envoyer un email à votre domaine, il effectue un lookup DNS sur _smtp._tls.captaindns.com pour vérifier si vous avez configuré TLS-RPT.

3. Collecte des résultats TLS

À chaque tentative de livraison, le serveur émetteur enregistre le résultat de la négociation TLS : succès ou échec, avec le type d'erreur le cas échéant.

4. Agrégation et envoi du rapport

Toutes les 24 heures, le serveur émetteur agrège les résultats et envoie un rapport JSON à l'adresse rua spécifiée dans votre enregistrement TLS-RPT.

Qui envoie les rapports ?

Les principaux fournisseurs qui envoient des rapports TLS-RPT :

Fournisseur	Adresse d'envoi	Supporté
Google / Gmail	`noreply-smtp-tls-reporting@google.com`	Oui
Microsoft / Outlook	`tlsrpt@microsoft.com`	Oui
Yahoo / AOL	Variable	Oui
LinkedIn	Variable	Oui
Comcast	Variable	Oui

Si vous recevez un email de noreply-smtp-tls-reporting@google.com, pas de panique : c'est un rapport TLS-RPT légitime envoyé par Google. Il contient un fichier JSON compressé (gzip) détaillant les résultats TLS des dernières 24 heures.

La syntaxe de l'enregistrement TLS-RPT

L'enregistrement TLS-RPT est un record DNS TXT publié à _smtp._tls.<domaine>.

Format de base

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Tag	Obligatoire	Description
`v`	Oui	Version du protocole, toujours `TLSRPTv1`
`rua`	Oui	URI(s) de destination des rapports (`mailto:` ou `https:`)

Exemples de configurations valides

Reporting par email (le plus courant) :

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Reporting par endpoint HTTPS :

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://report.captaindns.com/tlsrpt"

Reporting multiple (email + HTTPS) :

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt"

Reporting vers un domaine externe

Quand vous envoyez les rapports vers un domaine différent du vôtre (par exemple, un service tiers de monitoring), le domaine destinataire doit publier un enregistrement d'autorisation :

captaindns.com._report._tls.monitoring-tiers.com. TXT "v=TLSRPTv1"

Ce mécanisme empêche un attaquant de rediriger les rapports vers un domaine non autorisé. Vérifiez toujours que le domaine externe a bien publié ce record d'autorisation.

Conseils de configuration

Boîte dédiée : utilisez une adresse email dédiée (ex : tlsrpt@captaindns.com) pour ne pas noyer les rapports dans votre boîte principale
TTL raisonnable : un TTL de 300 à 3600 secondes convient pour cet enregistrement
HTTPS pour le volume : si vous recevez beaucoup d'emails, un endpoint HTTPS est plus adapté qu'une boîte email pour traiter les rapports

Comprendre le rapport JSON TLS-RPT

Les rapports TLS-RPT sont envoyés au format JSON, compressés en gzip. Voici la structure d'un rapport type :

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-09T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-08T00:00:00Z_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.captaindns.com",
          "max_age: 604800"
        ],
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 4523,
        "total-failure-session-count": 2
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "192.0.2.1",
          "receiving-mx-hostname": "mail.captaindns.com",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

Décryptage du rapport

Champ	Signification
`organization-name`	Qui envoie le rapport (Google, Microsoft, etc.)
`date-range`	Période couverte (toujours 24h)
`policy-type`	Type de politique appliquée : `sts` (MTA-STS), `tlsa` (DANE), ou `no-policy-found`
`total-successful-session-count`	Nombre de connexions TLS réussies
`total-failure-session-count`	Nombre de connexions TLS échouées
`failure-details`	Détail de chaque type d'échec

Les types d'échecs TLS

Chaque échec est catégorisé par un result-type. Voici les principaux :

Code	Description	Gravité	Action
`starttls-not-supported`	Le serveur MX ne supporte pas STARTTLS	Critique	Activer STARTTLS sur le serveur
`certificate-expired`	Le certificat TLS du serveur a expiré	Critique	Renouveler le certificat immédiatement
`certificate-host-mismatch`	Le certificat ne correspond pas au hostname du MX	Critique	Corriger le certificat ou le hostname
`certificate-not-trusted`	Certificat non signé par une CA de confiance	Élevée	Utiliser un certificat d'une CA reconnue
`validation-failure`	Échec de validation TLS générique	Élevée	Vérifier la configuration TLS complète
`sts-policy-fetch-error`	Impossible de récupérer la politique MTA-STS	Moyenne	Vérifier le fichier `mta-sts.txt`
`sts-policy-invalid`	La politique MTA-STS est invalide	Moyenne	Corriger la syntaxe de la politique
`sts-webpki-invalid`	Le certificat HTTPS du serveur de politique est invalide	Moyenne	Renouveler le certificat du sous-domaine `mta-sts`
`tlsa-invalid`	Record TLSA invalide (DANE)	Moyenne	Corriger les records TLSA
`dnssec-invalid`	Validation DNSSEC échouée	Élevée	Vérifier la configuration DNSSEC

Tableau récapitulatif des types d'échecs TLS-RPT avec leur gravité et l'action recommandée

TLS-RPT et MTA-STS : le duo indispensable

TLS-RPT prend tout son sens quand il est combiné avec MTA-STS. Voici pourquoi :

Le workflow recommandé

Configurer TLS-RPT : publiez votre enregistrement _smtp._tls pour commencer à recevoir des rapports
Activer MTA-STS en mode testing : publiez votre politique MTA-STS avec mode: testing
Analyser les rapports : pendant 1 à 2 semaines, les rapports TLS-RPT vous montrent si des connexions TLS échouent
Corriger les problèmes : certificats expirés, MX non couverts, configurations TLS incorrectes
Passer en mode enforce : une fois que les rapports confirment zéro échec, basculez MTA-STS en mode: enforce

Sans TLS-RPT, passer en mode enforce revient à naviguer à l'aveugle : vous risquez de rejeter des emails légitimes sans le savoir.

TLS-RPT fonctionne aussi avec DANE

TLS-RPT ne se limite pas à MTA-STS. Il rapporte également les échecs liés aux records DANE TLSA (RFC 7672). Si votre domaine utilise DNSSEC et publie des records TLSA, les rapports TLS-RPT incluront les résultats de validation DANE avec le policy-type: tlsa.

Configurer TLS-RPT en 5 minutes

Étape 1 : Choisir l'adresse de reporting

Créez une adresse email dédiée pour recevoir les rapports :

tlsrpt@captaindns.com (recommandé)
Ou utilisez un endpoint HTTPS si vous avez un système de traitement automatisé

Étape 2 : Générer l'enregistrement DNS

Utilisez notre générateur TLS-RPT pour créer l'enregistrement adapté à votre domaine. Vous obtiendrez un record prêt à copier.

Étape 3 : Publier l'enregistrement DNS

Ajoutez l'enregistrement TXT dans votre zone DNS :

Champ	Valeur
Hôte	`_smtp._tls`
Type	`TXT`
Valeur	`v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com`
TTL	`3600`

Étape 4 : Vérifier la configuration

Utilisez notre validateur de syntaxe TLS-RPT pour vérifier que votre enregistrement est correctement formaté.

Étape 5 : Attendre les premiers rapports

Les rapports arrivent en général 24 à 48 heures après la publication de l'enregistrement. Google est souvent le premier à envoyer des rapports.

Erreurs courantes et dépannage

Pas de rapports reçus après 48 heures

Vérifiez que l'enregistrement est bien publié à _smtp._tls.captaindns.com (pas à _smtp-tls ou smtp._tls)
Vérifiez la syntaxe : v=TLSRPTv1 (pas v=TLSRPTv2 ni v=TLSRPT1)
Assurez-vous que la boîte email de réception existe et accepte les pièces jointes gzip
Vérifiez que votre domaine reçoit suffisamment d'emails pour déclencher des rapports

Les rapports arrivent mais sont vides

Si total-failure-session-count est toujours à 0, c'est une bonne nouvelle : votre configuration TLS fonctionne correctement. Les rapports confirment que toutes les connexions TLS réussissent.

Emails de `noreply-smtp-tls-reporting@google.com`

Ces emails sont légitimes. Google envoie un rapport TLS-RPT quotidien pour chaque domaine qui a publié un enregistrement _smtp._tls. Le fichier joint (.json.gz) contient le rapport. Ne marquez pas ces emails comme spam.

🎯 Plan d'action recommandé

Publiez votre enregistrement TLS-RPT : 5 minutes avec le générateur TLS-RPT (voir étape 2 ci-dessus)
Configurez MTA-STS en mode testing : activez la politique MTA-STS pour que les rapports TLS-RPT incluent les résultats de validation
Analysez les rapports pendant 2 semaines : identifiez les échecs TLS et corrigez-les
Passez MTA-STS en mode enforce : une fois les rapports propres, activez le rejet des connexions TLS échouées
Surveillez en continu : les rapports quotidiens vous alertent de tout nouveau problème (certificat expiré, changement de MX, etc.)

FAQ

Qu'est-ce que TLS-RPT et à quoi ça sert ?

TLS-RPT (SMTP TLS Reporting, RFC 8460) est un mécanisme qui permet au propriétaire d'un domaine de recevoir des rapports quotidiens sur les échecs de négociation TLS lors de la livraison d'emails. Il vous donne une visibilité complète sur la qualité du chiffrement de vos emails entrants.

Comment configurer un enregistrement TLS-RPT ?

Publiez un enregistrement DNS TXT à _smtp._tls.captaindns.com avec la valeur v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com. Utilisez un générateur TLS-RPT pour créer l'enregistrement, puis ajoutez-le dans votre zone DNS. Les premiers rapports arrivent sous 24 à 48 heures.

Pourquoi je reçois des emails de noreply-smtp-tls-reporting@google.com ?

Ces emails sont des rapports TLS-RPT légitimes envoyés par Google. Votre domaine a un enregistrement _smtp._tls configuré, et Google vous envoie quotidiennement un rapport JSON compressé détaillant les résultats de négociation TLS pour les emails qu'il vous a envoyés.

Quelle est la différence entre TLS-RPT et DMARC reporting ?

DMARC surveille l'authentification des emails (SPF, DKIM, alignement), tandis que TLS-RPT surveille le chiffrement du transport (TLS). DMARC vérifie qui envoie l'email, TLS-RPT vérifie comment il est transporté. Les deux sont complémentaires et recommandés ensemble.

TLS-RPT est-il obligatoire si j'utilise MTA-STS ?

Non, TLS-RPT n'est pas techniquement obligatoire pour MTA-STS. Mais il est fortement recommandé : sans TLS-RPT, vous ne saurez pas si des connexions TLS échouent. C'est particulièrement critique avant de passer MTA-STS en mode enforce, car les rapports vous permettent d'identifier et corriger les problèmes en amont.

À quelle fréquence les rapports TLS-RPT sont-ils envoyés ?

Les rapports TLS-RPT sont envoyés une fois par jour (période de 24 heures). Chaque fournisseur compatible (Google, Microsoft, Yahoo, etc.) envoie son propre rapport indépendamment. Vous recevrez donc potentiellement plusieurs rapports par jour, un par fournisseur.

Comment lire un rapport TLS-RPT JSON ?

Un rapport TLS-RPT est un fichier JSON compressé en gzip. Il contient l'organisation émettrice, la période couverte, et pour chaque politique TLS (MTA-STS ou DANE) : le nombre de sessions réussies, le nombre d'échecs, et le détail de chaque type d'échec (certificat expiré, STARTTLS non supporté, etc.).

Peut-on utiliser à la fois mailto: et https: dans TLS-RPT ?

Oui, vous pouvez spécifier plusieurs URIs de reporting séparées par des virgules. Par exemple : rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt. L'endpoint HTTPS est recommandé pour les domaines à fort volume d'emails.

📖 Glossaire

TLS-RPT : SMTP TLS Reporting, mécanisme de rapport sur les échecs TLS défini dans la RFC 8460.
MTA-STS : Mail Transfer Agent Strict Transport Security (RFC 8461), politique qui impose le chiffrement TLS pour la réception d'emails.
DANE : DNS-Based Authentication of Named Entities (RFC 7672), mécanisme alternatif à MTA-STS qui utilise DNSSEC et les records TLSA pour valider les certificats TLS.
STARTTLS : Extension SMTP qui permet de chiffrer une connexion initialement en clair. Opportuniste par défaut (pas de rejet si le chiffrement échoue).
Downgrade attack : Attaque où un intermédiaire force la connexion à rester en clair en supprimant la commande STARTTLS de la réponse du serveur.
RUA : Reporting URI for Aggregated reports, l'adresse où les rapports TLS-RPT sont envoyés.

Vérifiez votre configuration maintenant : Utilisez notre vérificateur TLS-RPT pour analyser l'enregistrement _smtp._tls de votre domaine en quelques secondes.