Générateur de politiques MTA-STS et d'enregistrements DNS TLS-RPT

Générateur de politiques MTA-STS et d'enregistrements DNS TLS-RPT

Guide de référence technique et bonnes pratiques pour générer les fichiers de stratégie RFC 8461 MTA-STS, les enregistrements DNS TXT _mta-sts et les rapports d'incidents RFC 8460 TLS-RPT.

Préréglages :
Configuration de la politique et du DNS

Hôte de politique : mta-sts.example.com

Strict security: rejects unencrypted/invalid TLS delivery.

Noms d'hôte des serveurs de messagerie (MX) autorisés2
mx:mail.example.com
mx:mx2.example.com
7 days (1 week)

Modifiez l'ID lors de l'édition de la politique pour forcer la réactualisation.

Rapports d'incidents SMTP TLS-RPT (RFC 8460)
version: STSv1
mode: enforce
mx: mail.example.com
mx: mx2.example.com
max_age: 604800
Niveau d'application
enforceStrict TLS
Cibles de messagerie autorisées
2 MX Patterns
Durée de vie du cache de politique
7 days (1 week)

Compilation locale sans latence

Génère instantanément les fichiers de politique RFC 8461 et les enregistrements DNS TXT dans la mémoire du navigateur, sans transfert réseau.

Validation RFC 8461 & RFC 8460

Valide la syntaxe des jokers MX, les contraintes de non-IP, les limites alphanumériques de l'ID de politique et les normes HTTPS.

Déploiement multiplateforme clé en main

Exporte des extraits prêts à déployer pour BIND, Cloudflare, Route 53, Nginx, Caddy, Apache et HashiCorp Terraform.

Référence technique et guide d'architecture

Guide Développeur : Générateur de Stratégies MTA-STS et Enregistrements DNS TLS-RPT — Guide de référence

Guide de référence technique et bonnes pratiques pour générer les fichiers de stratégie RFC 8461 MTA-STS, les enregistrements DNS TXT _mta-sts et les rapports d'incidents RFC 8460 TLS-RPT.

Paramètres clés et contrôles

modestring (enforce | testing | none)

Définit le niveau d'application de la politique MTA-STS pour les flux SMTP entrants. 'testing' demande aux MTA expéditeurs de signaler les anomalies TLS sans bloquer les messages, 'enforce' impose TLS et refuse les connexions non conformes, tandis que 'none' désactive la politique.

Par défaut : testing
mxstring | string[]

Liste des hôtes de messagerie autorisés (FQDN ou jokers mono-niveau comme *.mail.example.com) auxquels les MTA émetteurs sont autorisés à se connecter et dont les certificats SAN doivent être validés.

Par défaut : mail.example.com
max_ageinteger (secondes)

Durée en secondes pendant laquelle un MTA expéditeur met en cache localement la stratégie. En production, les valeurs recommandées se situent entre 604800 (1 semaine) et 1209600 (2 semaines). Une valeur de 86400 est conseillée lors du déploiement initial.

Par défaut : 604800
policy_idstring

Identifiant unique spécifié dans l'enregistrement DNS TXT _mta-sts (souvent un horodatage comme 2026101701). Sa modification ordonne aux serveurs distants d'invalider leur cache et de recharger mta-sts.txt en HTTPS.

Par défaut : 20261017000000
ruastring (mailto URI)

Adresse de messagerie déclarée dans l'enregistrement _smtp._tls où les serveurs tiers compatibles transmettent les rapports quotidiens agrégés au format JSON concernant les échecs de négociation TLS (TLS-RPT).

Par défaut : mailto:[email protected]

Conseils de pro et bonnes practices

Configurez votre enregistrement

Configurez votre enregistrement _smtp._tls et maintenez MTA-STS en mode 'testing' pendant au moins deux semaines avant de basculer en 'enforce'. L'analyse des rapports agrégés TLS-RPT permet d'identifier les suites cryptographiques obsolètes, les chaînes de certificats incomplètes ou les soucis SNI sans perte de courriels.

Le fichier de stratégie doit

Le fichier de stratégie doit impérativement être servi sur https://mta-sts.<domaine>/.well-known/mta-sts.txt avec un code HTTP 200, un Content-Type text/plain et un certificat TLS valide émis par une autorité publique reconnue. Les redirections vers d'autres domaines et les certificats auto-signés sont rejetés.

Chaque ligne 'mx

Chaque ligne 'mx:' du fichier de stratégie doit correspondre aux enregistrements DNS MX et aux entrées Subject Alternative Name (SAN) du certificat présenté par le serveur de messagerie. Si le MX est mail.example.com, le certificat doit couvrir explicitement mail.example.com ou *.example.com.

Pièges courants et dépannage

Échec de récupération de la stratégie : Les serveurs distants signalent une erreur HTTPS sur le sous-domaine mta-sts

Assurez-vous que les enregistrements DNS A/AAAA pour 'mta-sts.<votredomaine>' sont opérationnels et que le serveur web hébergeant le fichier dispose d'un certificat TLS valide pour ce sous-domaine. Le port 443 doit être accessible sans dépassement de délai (moins de 10 secondes).

Rejet ou non-distribution d'e-mails légitimes après activation du mode 'enforce'

Vérifiez si le certificat de l'un de vos serveurs MX a expiré ou si la commande STARTTLS a échoué. En cas d'urgence, repassez la politique en 'testing' et incrémentez le policy_id dans votre DNS TXT pour forcer la mise à jour immédiate du cache des MTA émetteurs.

Foire aux questions (FAQ)

Quelle est la différence fondamentale entre MTA-STS et DANE TLSA ?▼

MTA-STS (RFC 8461) s'appuie sur la PKI Web traditionnelle (certificats HTTPS délivrés par des autorités reconnues) et des enregistrements DNS TXT pour parer aux attaques de rétrogradation STARTTLS. À l'inverse, DANE (RFC 7672) ancre les empreintes de certificats directement dans le DNS via des enregistrements TLSA, ce qui impose une signature DNSSEC intégrale.

Pourquoi le paramètre policy_id dans l'enregistrement DNS est-il critique ?▼

Les MTA distants conservent la politique en cache selon la valeur de max_age. Pour limiter les requêtes web superflues, ils vérifient d'abord l'enregistrement DNS TXT. Tant que la valeur 'id=' reste inchangée, les serveurs continuent d'utiliser la copie locale sans interroger le fichier HTTPS.

Que se passe-t-il si un serveur expéditeur ne prend pas en charge MTA-STS ?▼

Les serveurs non conformes à la RFC 8461 ignorent simplement les enregistrements _mta-sts et le fichier HTTPS. Ils poursuivent l'acheminement selon le principe opportuniste habituel de STARTTLS, avec un repli possible en texte clair en cas d'échec.

Peut-on déclarer plusieurs serveurs MX dans une seule stratégie MTA-STS ?▼

Oui. Vous pouvez spécifier autant de directives 'mx:' que nécessaire, à raison d'une par ligne (ex. 'mx: mx1.example.com' et 'mx: mx2.example.com'). Tous les hôtes MX publiés dans votre zone DNS doivent être couverts.

Outils et utilitaires connexes

Tous les outils →