Pourquoi Google envoie-t-il des rapports TLS MTA-STS ?

Exigences actuelles

Publication TLS-RPT pour les rapports agrégés

• Concerne : un domaine de réception qui veut des rapports agrégés SMTP TLS des expéditeurs participants.
• En vigueur : dès qu’il publie un TXT TLS-RPT valide. La RFC 8460 ne fixe aucune date d’application propre à Google.
• Preuve requise : un TXT à _smtp._tls.yourdomain.com avec une balise de version v=TLSRPTv1 et au moins une destination rua.
• Conséquence : les expéditeurs participants peuvent envoyer des rapports à la destination déclarée. L’enregistrement ne prouve pas que chaque expéditeur gère TLS-RPT ni que chaque livraison figurera dans un rapport.

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

Correspondance MTA-STS

• Concerne : un domaine qui publie une politique MTA-STS et dont des expéditeurs l’appliquent.
• En vigueur : quand l’expéditeur a récupéré une politique MTA-STS valide en mode enforce.
• Preuve requise : le TXT _mta-sts.yourdomain.com actif, le fichier de politique HTTPS, les MX actuels et un test de connexion réel par hôte MX.
• Conséquence : selon la RFC 8461, un expéditeur qui applique une politique enforce ne doit pas livrer sans connexion TLS authentifiée vers un hôte MX autorisé.

Rapports Google Workspace : contenu

• Concerne : les administrateurs Google Workspace recevant des rapports sur les connexions à leur domaine.
• En vigueur : Google documente des rapports quotidiens. Google ne publie aucun seuil d’expéditeurs chiffré pour ces rapports.
• Preuve requise : le domaine de politique, la période, les totaux et les détails des échecs du rapport, comparés à l’infrastructure de réception actuelle.
• Conséquence : selon Google, ses rapports peuvent indiquer les politiques MTA-STS détectées, le trafic, les connexions échouées et les messages non livrés. Ils n’identifient pas chaque expéditeur et n’établissent pas la cause d’une non-livraison donnée.

Mise en œuvre et validation

1. Vérifiez que le rapport a été demandé

Vérifiez le DNS du domaine de réception exact nommé dans le rapport. L’enregistrement TLS-RPT est distinct de celui de la politique MTA-STS. Un domaine peut demander des rapports sans MTA-STS, car la RFC 8460 couvre d’autres politiques TLS applicables.

Utilisez le test MTA-STS pour l’enregistrement et la politique publics. Un test public ne voit pas le flux de rapports de Google, vos journaux entrants, l’état DNS futur ni le chemin de chaque expéditeur.

2. Lisez la période et les totaux

La RFC 8460 agrège les résultats sur une période. Commencez par le domaine de politique et les horodatages de début et de fin. Comparez ensuite les sessions réussies et échouées avant de traiter un rapport comme un incident.

Un rapport qui ne contient que des sessions réussies est un retour normal. Quelques échecs isolés peuvent être un signal, mais ne prouvent pas une panne durable. Comparez plusieurs périodes avant de conclure.

3. Reliez chaque échec au chemin de réception actuel

Examinez les détails des échecs avec l’hôte MX qui a traité la connexion. Comparez ensuite la politique décrite à la politique MTA-STS actuelle, aux réponses DNS, au nom et à la chaîne du certificat, et à la négociation TLS SMTP vue de l’extérieur.

Le format indique le contexte de politique et la catégorie d’échec. Relier une catégorie à une cause locale reste une déduction tant que vos preuves DNS, certificat, répartiteur de charge et MTA ne la confirment pas.

Ne retirez pas un hôte MX d’une politique MTA-STS et ne désactivez pas enforce d’emblée. Un changement hâtif peut rendre une route de secours légitime inaccessible aux expéditeurs qui respectent MTA-STS.

4. Testez chaque hôte MX annoncé

Testez les MX principaux et de secours. Incluez les hôtes de moindre préférence, car les expéditeurs peuvent les joindre en cas de bascule. Vérifiez que chaque nom autorisé se résout comme prévu, accepte SMTP, propose STARTTLS et présente un certificat valide pour son nom selon la politique.

Une politique MTA-STS d’exemple a cette forme :

version: STSv1
mode: enforce
mx: mx1.yourdomain.com
mx: mx2.yourdomain.com
max_age: 604800

Le fichier de politique se place à l’adresse HTTPS fixée par la RFC 8461. Changez l’ID de politique dans le TXT _mta-sts à chaque modification pour que les expéditeurs sachent qu’ils doivent la récupérer.

5. Validez sur quatre couches distinctes

Un DNS fonctionnel n’est qu’une couche de preuve.

• DNS : interrogez le DNS faisant autorité et au moins un résolveur public pour _smtp._tls, _mta-sts et les MX.
• Fournisseur : lisez le rapport de Google pour la période et la politique. Il reflète les seules connexions que Google a observées.
• Message et transport : utilisez les journaux MTA entrants ou un test SMTP externe contrôlé par hôte MX. Le DNS ne prouve pas une session TLS réussie.
• Preuves DMARC continues : les rapports agrégés DMARC recensent les e-mails envoyés avec votre domaine. Ils ne remplacent pas les preuves TLS côté réception.

Historique

12 août 2026

Revérifié la documentation MTA-STS et rapports TLS de Google, la RFC 8460 et la RFC 8461. Confirmé que Google documente des rapports TLS quotidiens sur la politique, le trafic, les connexions échouées et les messages non livrés. Confirmé que la RFC 8460 définit les rapports agrégés via une destination TLS-RPT publiée et que la RFC 8461 définit la livraison en mode enforce. Aucun seuil chiffré de Google ni obligation TLS-RPT universelle n’a été trouvé.

18 juillet 2026

Publication du suivi, avec la distinction entre rapports agrégés attendus et échecs durables côté réception. Noté la nécessité de comparer les rapports au DNS actif, à la politique MTA-STS, aux certificats TLS et au service SMTP entrant.

Vérifiez la configuration MTA-STS publique avant d’agir

Passez le domaine de réception dans le test MTA-STS pour voir l’enregistrement TLS-RPT public, l’enregistrement DNS MTA-STS, le fichier de politique et les motifs MX annoncés. Comparez le résultat au domaine de politique et aux échecs du rapport avant de changer un certificat ou une politique.

Palisade est un logiciel DMARC. Il peut analyser les rapports agrégés DMARC, repérer les sources d’envoi et les problèmes d’authentification ou d’alignement, et proposer la prochaine étape de politique à un humain. Il ne répare pas un échec TLS entrant, ne contrôle pas la livraison de Google et ne fait pas d’un test public une preuve continue du transport SMTP.

Commencez avec Palisade