Rapports TLS-RPT : lire les rapports TLS SMTP

Quelles sont les exigences ?

Un enregistrement TLS-RPT fournit la destination

La RFC 8460 définit un enregistrement TXT DNS à _smtp._tls.. Sa balise rua contient une ou plusieurs destinations mailto ou https.

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Ceci n’est qu’un exemple de forme. Publiez l’adresse ou le point HTTPS que votre organisation contrôle.

La RFC exige la balise de version v=TLSRPTv1. La valeur rua indique où l’expéditeur peut livrer le rapport. Elle n’oblige aucun expéditeur à en produire et ne crée pas de politique MTA-STS. Voir le sens de v=TLSRPTv1 dans un enregistrement TLS-RPT pour le détail.

Le rapport suit le schéma JSON RFC 8460

La section 4 de la RFC 8460 définit un rapport I-JSON : organisation émettrice, période couverte, ID de rapport et résultats par politique. Chaque entrée donne le type et le domaine de politique, les hôtes MX, les totaux de sessions et des détails d’échec facultatifs.

{
  "organization-name": "Example Mail Sender",
  "date-range": {
    "start-datetime": "2026-08-12T00:00:00Z",
    "end-datetime": "2026-08-13T00:00:00Z"
  },
  "contact-info": "tls-reporting@example.net",
  "report-id": "example-report-id",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": ["version: STSv1", "mode: enforce"],
        "policy-domain": "yourdomain.com",
        "mx-host": ["mail.yourdomain.com"]
      },
      "summary": {
        "total-successful-session-count": 125,
        "total-failure-session-count": 2
      },
      "failure-details": []
    }
  ]
}

Ces valeurs ne sont qu’un exemple. Ne prenez pas cet exemple pour un rapport reçu pour un vrai domaine.

Commencez par total-successful-session-count et total-failure-session-count. Des sessions réussies servent aussi de signal de vie : la négociation TLS a eu lieu comme prévu. Un nombre d’échecs non nul demande une enquête, mais n’identifie le message touché que si les détails d’échec du rapport contiennent assez de preuves.

Les types de résultat classent l’échec

La section 4.3 de la RFC 8460 définit les types de résultat des détails d’échec. Les échecs de négociation incluent starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted et validation-failure.

Types propres à DANE : tlsa-invalid, dnssec-invalid et dane-required. Types propres à MTA-STS : sts-policy-fetch-error, sts-policy-invalid et sts-webpki-invalid. La RFC définit aussi des échecs généraux et temporaires.

Pour certificate-not-trusted et validation-failure, la RFC 8460 demande à l’expéditeur de préciser dans failure-reason-code. Traitez ce champ comme un diagnostic fourni par l’expéditeur. Il est utile, mais ne remplace pas la vérification du certificat, du DNS, du service MX et du chemin de livraison réel.

Envoi par e-mail : format et nom de fichier définis

La section 5 de la RFC 8460 permet l’envoi par e-mail ou HTTPS. Un nom de fichier a cette forme :

sender!policy-domain!begin-timestamp!end-timestamp[!unique-id].json
sender!policy-domain!begin-timestamp!end-timestamp[!unique-id].json.gz

Les horodatages sont en secondes depuis l’epoch Unix. La RFC autorise gzip pour les fichiers .json.gz.

Par e-mail, le message est de type multipart/report avec report-type="tlsrpt". La partie lisible par machine est application/tlsrpt+json ou application/tlsrpt+gzip. Les en-têtes TLS-Report-Domain et TLS-Report-Submitter DOIVENT (MUST) être présents : ce sont de bons filtres dans la boîte qui reçoit les rapports.

Quand l’exigence entre-t-elle en vigueur ?

La RFC 8460, « SMTP TLS Reporting », a été publiée en septembre 2018 comme RFC Standards Track. C’est la spécification de référence des rapports TLS-RPT.

Il n’y a pas de date d’effet, car publier TLS-RPT est facultatif. Cet article ne fixe aucune date d’application par un fournisseur de messagerie : aucune exigence ni conséquence sur la livraison n’a été vérifiée pour la publication d’un enregistrement TLS-RPT.

Selon la section 4.1 de la RFC 8460, un rapport DEVRAIT couvrir une journée entière, de 00:00-24:00 UTC. Il arrive après un délai, peut-être de plusieurs heures. La RFC cite un délai aléatoire de quatre heures au plus. Les rapports décrivent donc souvent le jour UTC précédent, pas l’état en direct des connexions.

Comment mettre en œuvre l’exigence ?

1. Choisissez la destination

Choisissez une adresse mailto ou un point HTTPS contrôlé qui peut recevoir des rapports TLS-RPT lisibles par machine. Désignez qui les examine et où garder les fichiers JSON compressés.

Évitez une boîte partagée sans processus de tri. Les données peuvent répéter des politiques et résultats de connexion à examiner techniquement.

2. Publiez le TXT TLS-RPT

Publiez un TXT v=TLSRPTv1 à _smtp._tls.yourdomain.com avec la destination rua choisie.

Interrogez ensuite le serveur DNS faisant autorité et au moins un résolveur public. La visibilité DNS prouve que l’enregistrement est joignable. Elle ne prouve pas qu’un autre expéditeur produira ou livrera un rapport.

3. Classez politique et type de résultat

À l’arrivée d’un rapport, identifiez d’abord son policy-type. Séparez les constats MTA-STS, DANE et no-policy-found : ils décrivent des contextes de politique de transport différents.

Comparez ensuite les totaux à failure-details. Traitez les erreurs durables de certificat, de nom d’hôte MX, de récupération de politique ou DNSSEC avant les échecs de connexion temporaires. Un classement d’échec doit mener à un test sur le même chemin vers le service MX touché, pas à une retouche DNS au hasard.

4. Gardez les preuves du chemin de livraison

Gardez la pièce jointe ou la charge HTTPS d’origine, sa période, l’organisation émettrice et l’ID de rapport. Si le rapport est arrivé par e-mail, gardez les en-têtes qui identifient le domaine du rapport et l’émetteur.

Comparez les constats au paramétrage MX, à l’état des certificats, à la récupération de la politique MTA-STS le cas échéant et aux journaux du service touché. Un rapport TLS-RPT est une preuve agrégée. Il ne contient pas tous les détails nécessaires pour diagnostiquer une transaction SMTP isolée.

Comment valider la conformité ?

Validez l’enregistrement publié au niveau DNS en interrogeant _smtp._tls.yourdomain.com via le serveur faisant autorité et un résolveur public. Vérifiez que la valeur TXT renvoyée contient v=TLSRPTv1 et la destination rua prévue.

Utilisez le test MTA-STS pour inspecter l’enregistrement _smtp._tls et sa destination analysée. Le test évalue l’enregistrement publié, pas le contenu des rapports. Un résultat valide signifie qu’un v=TLSRPTv1 existe. Il ne prouve pas qu’un expéditeur a utilisé la destination, ne surveille pas les rapports futurs et ne montre pas le chemin SMTP réel.

Au niveau rapport, examinez un JSON reçu : période UTC, domaine et type de politique, totaux de sessions et détails des échecs. Au niveau service, comparez les échecs signalés aux preuves de certificat et de MX. Au niveau message, testez un vrai message livré depuis le chemin d’envoi exact où un échec TLS SMTP est suspecté. Si le domaine utilise DMARC, les rapports agrégés donnent une vue distincte de l’authentification des messages, pas des rapports TLS du transport.

Vérifiez la destination des rapports TLS-RPT

Avant d’attendre des rapports, contrôlez _smtp._tls : sa destination rua doit être l’adresse ou le point que votre équipe attend.

Vérifiez le TLS-RPT avec le test MTA-STS

Un test d’enregistrement ne peut montrer le contenu d’un rapport reçu, prouver qu’un expéditeur en a produit un, ni fixer la future livraison d’un destinataire.

Pour suivre les constats TLS-RPT sur vos domaines, Commencez avec Palisade.