← RFC Reference

RFC 8460 : Rapport TLS SMTP (TLSRPT)

Pourquoi cela existe

Deux normes appliquent TLS pour les e-mails serveur à serveur : MTA-STS (RFC 8461) et DANE (RFC 7672). Les deux indiquent aux serveurs d'envoi « vous devez établir une connexion TLS valide avant de livrer du courrier à ce domaine ». Mais lorsque la négociation TLS échoue, le serveur d'envoi revient soit au texte clair (mauvais), soit refuse la livraison (courrier perdu). Dans les deux cas, le domaine destinataire n'a aucune idée qu'il y a un problème.

TLSRPT ferme cette lacune de visibilité. Les propriétaires de domaines publient un enregistrement DNS demandant des rapports TLS, et les MTA d'envoi regroupent leurs résultats de connexion TLS dans des rapports JSON quotidiens livrés par e-mail ou HTTPS.

Sans TLSRPT, vous pourriez déployer MTA-STS avec une erreur de certificat et ne pas réaliser qu'un pourcentage important du courrier entrant est rejeté ou livré de manière non sécurisée.

Comment ça marche

Étape 1 : Publier un enregistrement DNS TLSRPT

Ajoutez un enregistrement TXT à _smtp._tls.yourdomain.com spécifiant où les rapports doivent être envoyés :

Étape 2 : Les serveurs d'envoi collectent les données

Lorsqu'un MTA d'envoi livre du courrier à votre domaine, il enregistre le résultat de la négociation TLS : session réussie avec certificat valide, échec de la négociation, incompatibilité de certificat, échec de la politique MTA-STS, échec de la validation DANE, etc.

Étape 3 : Livraison quotidienne des rapports

Une fois par jour, le MTA d'envoi regroupent ses résultats et envoie un rapport JSON. Lorsqu'il est livré par e-mail, il arrive en tant que message multipart/report avec report-type=tlsrpt :

Content-Type: multipart/report; report-type=tlsrpt;
    boundary="TLSRPT-001"

--TLSRPT-001
Content-Type: text/plain

SMTP TLS report for example.com
Report period: 2026-03-10T00:00:00Z to 2026-03-11T00:00:00Z

--TLSRPT-001
Content-Type: application/tlsrpt+json

{
  "organization-name": "Sender Corp",
  "date-range": {
    "start-datetime": "2026-03-10T00:00:00Z",
    "end-datetime": "2026-03-11T00:00:00Z"
  },
  "contact-info": "postmaster@sendercorp.com",
  "report-id": "2026-03-10-example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce",
        "mx: mail.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 9450,
      "total-failure-session-count": 12
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.example.com",
      "failed-session-count": 12
    }]
  }]
}

--TLSRPT-001--

Détails techniques clés

Format de l'enregistrement DNS

Types de résultats d'échec

Types de politiques

Erreurs courantes

• Publier MTA-STS sans TLSRPT. MTA-STS en mode enforce forcera les serveurs d'envoi à rejeter le courrier lorsque TLS échoue. Sans TLSRPT, vous n'avez aucune visibilité sur ces défaillances. Déployez toujours les deux ensemble.
• Ignorer les rapports. Recevoir des rapports TLSRPT n'est utile que si vous les analysez et les surveillez réellement. Configurez un traitement automatisé ou utilisez un service qui regroupe et alerte sur les défaillances.
• Utiliser uniquement la livraison HTTPS. Bien que HTTPS POST soit plus propre pour le traitement automatisé, certains MTA d'envoi ne prennent en charge que la livraison par e-mail. Fournissez à la fois un URI mailto: et https: si possible.
• Mauvais emplacement de l'enregistrement DNS. L'enregistrement doit être à _smtp._tls.yourdomain.com, pas à _tls.yourdomain.com ou _tlsrpt.yourdomain.com. Le préfixe est spécifiquement _smtp._tls.
• Laisser les certificats expirer. L'échec le plus courant signalé via TLSRPT est certificate-expired. Automatisez le renouvellement des certificats (par exemple, avec Let's Encrypt) et surveillez les dates d'expiration.
• Ne pas vérifier le nom d'hôte MX par rapport au certificat. Votre certificat TLS doit couvrir les noms d'hôte figurant dans votre politique MTA-STS et vos enregistrements MX. Si votre MX est mail.example.com mais votre certificat concerne example.com, les expéditeurs signaleront certificate-host-mismatch.

Impact sur la délivrabilité

• Visibilité sur les défaillances TLS. Sans TLSRPT, les défaillances de négociation TLS sont invisibles. Vous ne savez pas que le courrier d'un expéditeur majeur est rejeté parce que votre certificat a expiré la semaine dernière.
• Condition préalable à l'application sécurisée de MTA-STS. Le chemin de déploiement recommandé est : publier MTA-STS en mode testing, activer TLSRPT, surveiller les rapports pour détecter les défaillances, corriger les problèmes, puis passer à enforce. Ignorer l'étape de surveillance risque de perdre du courrier.
• Détection des attaques de l'homme au milieu. Une augmentation soudaine de certificate-not-trusted ou starttls-not-supported provenant d'un réseau spécifique pourrait indiquer une attaque de suppression STARTTLS. TLSRPT rend cela visible.
• Preuve de conformité. Pour les domaines traitant des communications sensibles, les rapports TLSRPT fournissent la preuve que TLS est négocié avec succès pour la grande majorité des connexions entrantes.

Related RFCs