Outils de diagnostic réseau

Vérification MTA-STS

Politique TLS imposée pour le courrier entrant

esc
Votre IP 8.8.8.8 ou google.com

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 DNS

Dé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 SMTP

Ré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 ouverts

Domaine

Lookup WHOIS Données d'enregistrement pour domaines, IP et ASN

Qu'est-ce que MTA-STS ?

MTA-STS permet à un domaine d'exiger que le courrier entrant soit acheminé via TLS authentifié, ce qui le protège contre les attaques de déclassement (downgrade) et de l'homme du milieu. IPeek lit l'enregistrement TXT _mta-sts et récupère le fichier de règles publié sur mta-sts.votre-domaine. Il comble la faille laissée par STARTTLS opportuniste, qu'un attaquant peut supprimer silencieusement.

Comment MTA-STS publie et applique une règle

MTA-STS repose sur deux éléments. Un enregistrement TXT situé à _mta-sts.votre-domaine contient une version et un identifiant de règle (policy ID) qui signale aux serveurs émetteurs qu'une règle existe et qu'elle change à chaque mise à jour. La règle elle-même réside dans un fichier texte servi en HTTPS à l'adresse https://mta-sts.votre-domaine/.well-known/mta-sts.txt. Ce fichier indique la version, le mode, les noms d'hôtes MX autorisés et une durée de mise en cache max_age. Un serveur émetteur compatible MTA-STS récupère et met en cache la règle, puis refuse la remise vers tout MX dont le certificat ne se valide pas par rapport à elle.

Comment interpréter vos résultats MTA-STS

IPeek indique si l'enregistrement TXT _mta-sts existe et si le fichier de règles est accessible en HTTPS. La valeur du mode est ce qui compte le plus. none signifie qu'aucune règle n'est en vigueur, testing signifie que les échecs sont signalés mais que le courrier circule quand même, et enforce signifie que l'émetteur doit interrompre la remise en cas d'échec de l'authentification TLS. Vérifiez que les entrées mx de la règle correspondent à vos véritables enregistrements MX et que le certificat HTTPS de l'hôte de la règle est valide. Une valeur max_age élevée, souvent 604800 secondes, renforce la protection, car les règles mises en cache résistent à une altération en temps réel.

Problèmes MTA-STS courants et comment les corriger

L'erreur la plus fréquente est un enregistrement TXT qui existe alors que le fichier de règles renvoie une erreur 404 ou une redirection, ce qui rend la règle inutilisable. L'hôte de la règle doit servir un HTTPS valide : un certificat expiré ou non concordant sur mta-sts.votre-domaine casse complètement l'application de la politique. Des entrées MX désynchronisées de votre DNS provoquent des échecs de remise dès que vous passez en mode enforce. Déployez d'abord en mode testing, surveillez les rapports TLS-RPT à la recherche d'échecs, et ne passez en enforce qu'après avoir confirmé que chaque MX présente un certificat valide et concordant.

Questions fréquentes

Quelle est la différence entre les modes testing et enforce de MTA-STS ?

En mode testing, les serveurs émetteurs qui détectent un échec TLS remettent quand même le courrier mais signalent le problème, ce qui vous permet de repérer les anomalies sans bloquer le trafic. En mode enforce, l'émetteur doit interrompre la remise vers tout MX dont le certificat échoue à la validation. Commencez en testing, surveillez vos rapports TLS-RPT, et ne passez en enforce qu'une fois qu'aucun échec n'apparaît.

Où se trouve le fichier de règles MTA-STS ?

Le fichier de règles est servi en HTTPS à l'adresse https://mta-sts.votre-domaine/.well-known/mta-sts.txt, sur un sous-domaine nommé mta-sts. L'enregistrement TXT DNS situé à _mta-sts.votre-domaine se contente d'annoncer qu'une règle existe et porte un identifiant ; les règles réelles, dont le mode et les hôtes MX autorisés, résident dans ce fichier HTTPS. Les deux doivent être présents et valides pour que MTA-STS fonctionne.

En quoi MTA-STS diffère-t-il de STARTTLS ?

STARTTLS est opportuniste : il propose le chiffrement, mais un attaquant réseau peut supprimer l'annonce STARTTLS et forcer une remise en clair, sans être détecté. MTA-STS ajoute une règle publiée qui indique aux émetteurs que TLS est requis et quels certificats MX faire confiance ; ainsi, une connexion TLS supprimée ou invalide entraîne l'échec de la remise plutôt qu'un déclassement silencieux. Il renforce STARTTLS contre les attaques de déclassement.

MTA-STS nécessite-t-il DNSSEC ?

Non. MTA-STS s'appuie délibérément sur HTTPS et la PKI web pour établir sa confiance, et non sur DNSSEC, ce qui le rend plus simple à déployer que DANE. Le certificat HTTPS du fichier de règles assure l'authentification. Si votre domaine dispose déjà de DNSSEC, vous pouvez faire fonctionner DANE aux côtés de MTA-STS, car les deux mécanismes se complètent au lieu de s'opposer.

Comment déployer MTA-STS en toute sécurité ?

Publiez d'abord l'enregistrement TXT et le fichier de règles en mode testing, puis activez TLS-RPT afin que les serveurs émetteurs vous envoient des rapports sur les éventuels échecs TLS. Vérifiez que les noms d'hôtes MX de votre règle correspondent au DNS et que chaque MX présente un certificat valide. Une fois que les rapports ne montrent plus aucun échec sur un cycle de reporting normal, passez le mode en enforce et mettez à jour l'identifiant de règle.

Outils connexes

Deutsch | English | Español | Français | Italiano | Português | Русский | Українська | 日本語 | 简体中文 | 한국어