MTA-STS Validator gratuit

Pourquoi utiliser un validateur offline

Un validateur de syntaxe MTA-STS analyse votre enregistrement DNS TXT et votre fichier de politique sans publier ni interroger le DNS. Cette approche hors ligne couvre trois cas d'usage clés que l'audit en direct ne peut pas traiter.

Cas d'usage typiques :

• Avant déploiement → Validez un brouillon de politique avant la publication, pour éviter une mauvaise configuration en production.
• Préparation multi-domaines → Vérifiez la conformité de plusieurs politiques en lot, par exemple lors d'une migration ou d'un audit interne.
• Débogage offline → Reproduisez et corrigez une erreur sans accès au DNS public, par exemple en environnement isolé ou pré-production.
• Revue de configuration → Examinez un enregistrement reçu d'un partenaire ou exporté d'un outil tiers avant de l'appliquer.

Le validateur applique la spécification RFC 8461 sur la syntaxe : version, identifiant, mode, patterns MX, max_age, cohérence entre l'enregistrement DNS et la politique. Il ne se connecte à aucun serveur, ne fait aucune résolution DNS et ne télécharge aucun fichier distant.

Comment utiliser ce validateur en 3 étapes

Étape 1 : coller l'enregistrement et la politique

Vous pouvez valider trois combinaisons :

• Uniquement l'enregistrement TXT _mta-sts (mode record_only)
• Uniquement le contenu du fichier mta-sts.txt (mode policy_only)
• Les deux ensemble pour vérifier la cohérence (mode complet)

Aucune connexion réseau n'est effectuée. Vos données restent dans votre navigateur.

Étape 2 : ajouter un domaine (optionnel)

Saisir un domaine active la validation hybride : le validateur résout les enregistrements MX du domaine et vérifie que les patterns déclarés dans la politique correspondent aux serveurs réels. Ce mode aide à détecter une politique trop restrictive ou un MX oublié.

Sans domaine, seule la syntaxe pure est analysée.

Étape 3 : analyser le verdict

Les résultats sont classés par niveau de gravité :

• ❌ Erreur → Problème bloquant, la politique sera ignorée par les MTA destinataires
• ⚠️ Avertissement → Fonctionnel mais amélioration recommandée
• ✅ Valide → Syntaxe conforme RFC 8461

Corrigez chaque alerte avant de publier votre enregistrement et votre fichier en production.

Validator ou record check : quand utiliser chaque outil

Les deux outils sont complémentaires. Ils ne se remplacent pas : ils interviennent à des moments différents du cycle de vie d'une politique MTA-STS.

Workflow recommandé :

1. Concevez la politique → validateur pour vérifier la syntaxe
2. Publiez DNS + fichier → attendez la propagation
3. Record check pour confirmer l'audit live complet

Le validateur détecte les erreurs de saisie avant qu'elles n'atteignent vos utilisateurs. Le record check détecte les dérives, les certificats expirés et les problèmes de fetch HTTPS qui n'apparaissent qu'en conditions réelles.

Modes de validation

Le validateur prend en charge quatre modes selon les champs renseignés.

Mode record_only

Vous collez uniquement l'enregistrement TXT. Validation de :

• Format v=STSv1
• Présence et format de la balise id
• Tags inconnus ou dupliqués

Mode policy_only

Vous collez uniquement le contenu du fichier de politique. Validation de :

• Directive version
• Directive mode (enforce, testing, none)
• Patterns mx (au moins un requis)
• Directive max_age (bornes 0 à 31557600)

Mode record et policy combinés

Vous collez les deux. Validation complète plus :

• Cohérence de version entre TXT et fichier
• Cohérence d'intention (un mode: none avec un id actif est suspect)

Mode hybride avec domaine

Ajoutez un domaine au mode complet pour activer :

• Résolution des MX du domaine
• Vérification que chaque MX réel matche au moins un pattern mx:
• Détection des serveurs MX oubliés ou patterns trop stricts

Cette validation MX reste statique : elle compare les patterns aux MX déclarés sans tester les connexions SMTP.

Règles de syntaxe vérifiées

Enregistrement DNS

Le validateur applique les règles de la RFC 8461 §3.1 sur le TXT _mta-sts.domaine :

Exemple valide :

v=STSv1; id=20240115120000

Fichier de politique

Le validateur applique la RFC 8461 §3.2 sur mta-sts.txt :

Exemple valide :

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.backup.captaindns.com
max_age: 604800

Cohérence entre record et politique

Quand les deux sont fournis :

• L'id du TXT doit correspondre à une politique cohérente (un changement de politique implique un nouvel id).
• Le mode: none avec un TXT actif est signalé : indique souvent une intention de retrait incomplète.

Patterns MX et règles wildcard

La RFC 8461 §4.1 définit un format strict pour les patterns mx:. Le validateur applique le matching exact suivant.

Nom d'hôte exact

mx: mail.captaindns.com
mx: smtp.captaindns.com

Correspond au nom exact, casse insensible.

Pattern wildcard

mx: *.mail.captaindns.com

Règles strictes :

• Le wildcard * doit être le label le plus à gauche
• Correspond à un seul label (serveur1.mail.captaindns.com matche, a.b.mail.captaindns.com ne matche pas)
• Pas de double wildcard (**.captaindns.com est invalide)
• Pas de wildcard en milieu ou en fin (mail.*.captaindns.com est invalide)

Plusieurs patterns dans une politique

Une politique peut contenir plusieurs lignes mx: :

mx: mail.captaindns.com
mx: smtp.captaindns.com
mx: *.backup.captaindns.com

Un MX réel doit correspondre à au moins un pattern. Le validateur signale les MX réels orphelins quand un domaine est fourni.

Patterns invalides typiques

Erreurs de syntaxe courantes et corrections

Version incorrecte

Cause : v=sts1, v=STSV1 ou version: stsv1 au lieu de STSv1 exactement.

Correction :

- v=sts1; id=20240115
+ v=STSv1; id=20240115

Identifiant absent

Cause : L'enregistrement TXT ne contient pas la balise id.

Correction : Ajoutez un identifiant unique (timestamp recommandé) :

v=STSv1; id=20240115120000

Format d'id incorrect

Cause : Espaces, caractères spéciaux ou longueur excessive dans id.

Correction : Utilisez uniquement des caractères alphanumériques, 1 à 32 caractères.

- id=my policy id
+ id=mypolicyid20240115

Mode invalide

Cause : mode: strict, mode: ENFORCE ou faute de frappe.

Correction : une seule des trois valeurs autorisées :

- mode: strict
+ mode: enforce

Valeur max_age hors bornes

Cause : Valeur négative, non numérique, ou supérieure à 31557600.

Correction : entier dans [0, 31557600]. Valeur recommandée pour la production : 604800 (1 semaine).

- max_age: 99999999
+ max_age: 604800

Pattern malformé

Cause : Wildcard mal placé ou caractères interdits dans une ligne mx:.

Correction : voir la section patterns MX ci-dessus.

- mx: mail.*.captaindns.com
+ mx: *.mail.captaindns.com

Aucun pattern de serveur

Cause : Aucune ligne mx: dans une politique en mode enforce ou testing.

Correction : Ajoutez au moins une ligne mx: correspondant à votre infrastructure. En mode none, l'absence de mx: est tolérée.

Outils complémentaires et ressources

Guides associés

• MTA-STS : le guide complet pour sécuriser le transport de vos emails - Configuration, déploiement et bonnes pratiques.
• Dépannage MTA-STS : erreurs courantes et solutions - Diagnostiquer les problèmes de politique en production.
• Passer MTA-STS du mode testing au mode enforce - Migration progressive sans casser la délivrabilité.

Spécifications

• RFC 8461 - SMTP MTA Strict Transport Security (spécification officielle)
• Format de l'enregistrement DNS MTA-STS (§3.1)
• Format du fichier de politique MTA-STS (§3.2)
• Documentation MTA-STS Google (guide Workspace)

FAQ - Questions fréquentes

Q : Quelle différence entre le validateur et le record check MTA-STS ?

R : Le validateur analyse une syntaxe que vous collez, avant publication, sans toucher au DNS. Le record check interroge le DNS et HTTPS pour vérifier la configuration publiée. Utilisez le validateur en amont, le record check en aval.

Q : Pourquoi valider la syntaxe MTA-STS hors ligne ?

R : Pour détecter les erreurs avant qu'elles n'impactent vos utilisateurs. Une politique invalide est ignorée par les MTA destinataires : votre domaine reste exposé. Mieux vaut corriger une faute de frappe dans un brouillon que diagnostiquer un échec en production.

Q : Quelles sont les erreurs de syntaxe courantes ?

R : Les classiques : STSV1 au lieu de STSv1, mode: strict au lieu de enforce, max_age non numérique, wildcard mal placé (mail.*.captaindns.com), absence de balise id dans le TXT, ou plusieurs version dans le fichier.

Q : Quels formats de pattern MX sont valides ?

R : Nom exact (mail.captaindns.com) ou wildcard à un seul label en position leftmost (*.mail.captaindns.com). Pas de wildcard nu, pas de double wildcard, pas de wildcard en milieu de nom.

Q : Quelles valeurs max_age sont recommandées ?

R : La RFC 8461 impose 0 ≤ max_age ≤ 31557600 (1 an). Valeurs courantes : 86400 (1 jour) pour la phase de testing, 604800 (1 semaine) en production stable, 31557600 (1 an) pour une politique mature et figée.

Q : Comment corriger une erreur 'version invalide' ?

R : La version doit être exactement STSv1 (sensible à la casse) dans le TXT (v=STSv1) et dans la politique (version: STSv1). Vérifiez la casse, les espaces et l'absence de caractère parasite.

Q : Comment valider la syntaxe MTA-STS pour Microsoft 365 ?

R : Collez votre TXT et votre politique. Assurez-vous que vos patterns MX couvrent *.mail.protection.outlook.com. Le validateur vérifie la conformité RFC 8461 avant publication DNS, puis utilisez le record check après déploiement.

Q : Comment vérifier la syntaxe MTA-STS pour Google Workspace ?

R : Collez votre TXT et votre politique. Les MX Google sont en *.google.com (ou aspmx.l.google.com). Vérifiez que vos patterns matchent ces hostnames avant publication.