Politique de rapport TLS SMTP
DNS et enregistrements
Lookup DNS Tous les enregistrements DNS d'un domaine Lookup d'enregistrement A Adresses IPv4 d'un domaine Lookup d'enregistrement AAAA Adresses IPv6 d'un domaine Lookup MX Serveurs de messagerie d'un domaine Lookup NS Serveurs de noms faisant autorité Lookup TXT Enregistrements TXT, SPF, vérification Lookup CNAME Enregistrements de nom canonique (alias) Lookup SOA Enregistrement Start of Authority Lookup SRV Enregistrements de localisation de service Lookup CAA Quelles CA peuvent émettre des certificats DNS inversé (PTR) Adresse IP vers nom d'hôte Vérification DNSSEC Le domaine est-il signé et validé ? Diagnostic DNS Un bilan complet de délégation et de DNSDélivrabilité des e-mails
Vérification SPF Validez votre enregistrement Sender Policy Framework Vérification DMARC Inspectez et évaluez votre politique DMARC Vérification DKIM Trouvez et validez votre clé publique DKIM Vérification de liste noire Vérifiez une IP face aux listes de blocage e-mail (DNSBL) Test SMTP Connectez-vous à un serveur de messagerie et vérifiez STARTTLS Vérification MTA-STS Politique TLS imposée pour le courrier entrant Vérification BIMI Enregistrement de logo de marque pour l'e-mail Vérification TLS-RPT Politique de rapport TLS SMTPRéseau et web
Vérification de certificat SSL Inspectez le certificat TLS d'un site et son expiration Vérification des en-têtes HTTP Inspectez les en-têtes de réponse, redirections et sécurité Ping (TCP) Accessibilité et latence via TCP Vérification de ports Quels ports courants sont ouvertsDomaine
Lookup WHOIS Données d'enregistrement pour domaines, IP et ASNTLS-RPT (SMTP TLS Reporting) permet à un domaine de recevoir des rapports quotidiens sur les échecs de connexion TLS de la part des serveurs émetteurs, afin de détecter le courrier acheminé de façon non sécurisée. IPeek lit l'enregistrement TXT _smtp._tls et affiche les destinations de reporting. Il complète MTA-STS et DANE en vous donnant une visibilité sur la performance réelle de ces règles sur le terrain.
TLS-RPT est publié sous forme d'un unique enregistrement TXT DNS à l'adresse _smtp._tls.votre-domaine. L'enregistrement contient une balise de version et une balise rua= indiquant où les rapports doivent être envoyés, soit une adresse mailto, soit un point de terminaison HTTPS. Les serveurs émetteurs qui prennent en charge la norme agrègent sur une journée les résultats de leurs négociations TLS avec vos hôtes MX et envoient un rapport JSON à ces destinations. Chaque rapport comptabilise les sessions réussies et échouées et catégorise les échecs, comme les erreurs de validation de certificat ou l'indisponibilité de STARTTLS, vous offrant une boucle de retour sur la remise réelle.
IPeek confirme si l'enregistrement TXT _smtp._tls existe et affiche les destinations rua qu'il analyse. Vérifiez que la version est TLSRPTv1 et que chaque cible rua est une boîte mail ou une URL HTTPS valide que vous surveillez réellement. L'enregistrement en lui-même n'applique rien ; il se contente de demander des rapports, donc sa présence signifie que les émetteurs savent où envoyer les données d'échec TLS. Une fois les rapports reçus, examinez les types d'échec : certificate-expired, échecs de validation et starttls-not-supported pointent chacun vers une correction précise à apporter à votre infrastructure de réception, avant qu'ils ne causent des problèmes de remise silencieux.
MTA-STS et DANE imposent TLS sur le courrier entrant, mais cette application n'est sûre que si vous pouvez observer son effet sur le trafic réel. TLS-RPT apporte cette visibilité : lorsque vous déployez MTA-STS en mode testing, les rapports révèlent quels émetteurs rencontrent des échecs TLS avant que vous ne passiez en enforce. Il en va de même pour les non-concordances DANE TLSA. Considérez TLS-RPT comme la couche de surveillance de votre posture TLS, déployée aux côtés des mécanismes d'application, et non à leur place, afin de détecter tôt les problèmes de certificat et de configuration.
C'est un enregistrement TXT publié à l'adresse _smtp._tls.votre-domaine qui demande des rapports d'échec TLS. L'enregistrement contient une balise de version v=TLSRPTv1 et une balise rua= précisant où vont les rapports, sous forme d'adresse mailto ou d'URL HTTPS. Les serveurs émetteurs compatibles TLS-RPT l'utilisent pour savoir où remettre leurs rapports quotidiens agrégés sur les connexions TLS vers votre domaine.
Un rapport TLS-RPT est un document JSON résumant une journée de négociations TLS entre un serveur émetteur et vos hôtes MX. Il comptabilise les sessions réussies et échouées et ventile les échecs par type, comme les certificats expirés, les erreurs de validation de certificat ou l'indisponibilité de STARTTLS. Cela vous permet de repérer précisément quels hôtes de réception ou quels certificats provoquent des remises non sécurisées ou en échec.
Non. TLS-RPT est un mécanisme purement de reporting et n'impose rien par lui-même. L'application provient de MTA-STS ou de DANE, qui exigent TLS et peuvent bloquer une remise non sécurisée. TLS-RPT se place aux côtés de ces règles comme couche de surveillance, en vous montrant à quelle fréquence TLS réussit ou échoue afin de déployer l'application en toute confiance.
Publiez un enregistrement TXT à l'adresse _smtp._tls.votre-domaine contenant v=TLSRPTv1 et une balise rua= pointant vers une boîte mail ou un point de terminaison HTTPS que vous surveillez, par exemple rua=mailto:tlsrpt@votre-domaine. Choisissez une destination que vous consultez réellement, car les rapports arrivent quotidiennement au format JSON. Associez-le à MTA-STS ou DANE pour que les rapports décrivent la performance de votre politique TLS appliquée.
TLS-RPT apporte la visibilité qui rend le déploiement de MTA-STS sûr. Lorsque vous publiez une règle MTA-STS en mode testing, les serveurs émetteurs signalent tout échec TLS via TLS-RPT, ce qui vous permet de voir quels émetteurs seraient bloqués avant de passer en enforce. Les deux sont conçus pour fonctionner ensemble : MTA-STS définit la règle, et TLS-RPT vous indique comment elle se comporte en pratique.