À quoi sert TLS-RPT
SMTP TLS Reporting (RFC 8460) demande aux serveurs de messagerie expéditeurs de vous prévenir lorsqu'ils n'ont pas pu livrer à votre domaine sur une connexion correctement chiffrée : un certificat expiré sur un hôte MX, un hôte qui ne propose plus STARTTLS, une politique MTA-STS qui ne correspond pas. Les expéditeurs qui le prennent en charge collectent ces événements et envoient un rapport JSON par jour aux adresses que vous publiez.
L'enregistrement est un enregistrement TXT sous _smtp._tls.<domain>, par exemple v=TLSRPTv1; rua=mailto:tls-reports@example.com. La balise rua accepte une ou plusieurs adresses séparées par des virgules, chacune étant soit une adresse mailto:, soit un point de terminaison https: qui reçoit le rapport par POST.
Ce que vérifie cet outil
Il recherche l'enregistrement TXT et s'assure qu'il existe exactement un enregistrement TLS-RPT, qu'il commence par v=TLSRPTv1, que rua est présent et que chaque adresse est une URI mailto: ou https: syntaxiquement valide. Les points de terminaison en http: simple et les adresses sans schéma sont signalés, car les expéditeurs les ignorent.
Il n'envoie pas de rapport de test et ne peut pas savoir si quelqu'un lit la boîte. Les rapports sont du JSON lisible par machine, souvent compressé en gzip ; la plupart des gens font pointer rua vers une boîte aux lettres ou vers un service qui les analyse.
Pourquoi il va de pair avec MTA-STS
MTA-STS en mode enforce amène les expéditeurs à refuser la livraison quand TLS échoue. Sans TLS-RPT, vous ne l'apprendriez que par les personnes dont les e-mails ne sont pas arrivés. Publiez d'abord TLS-RPT, faites fonctionner MTA-STS en mode testing, puis passez à enforce quand les rapports sont propres. TLS-RPT est aussi utile seul, ainsi que pour les domaines qui utilisent DANE.