Qu'est-ce que MTA-STS ?
MTA-STS (RFC 8461) permet à un domaine de demander aux serveurs d'envoi de ne lui livrer ses e-mails qu'en TLS, avec un certificat valide, vers les hôtes MX qu'il désigne. Il a deux parties : un enregistrement TXT à _mta-sts.yourdomain portant un identifiant de politique, et un fichier de politique servi en https à mta-sts.yourdomain/.well-known/mta-sts.txt.
Lire le résultat
L'outil lit l'enregistrement, puis récupère le fichier de politique. Vous voyez l'identifiant, le mode (enforce, testing ou none), les motifs MX que la politique autorise et max_age, la durée pendant laquelle les expéditeurs peuvent la garder en cache. Un enregistrement dont le fichier de politique est inaccessible est signalé comme un échec.
Beat tourne sur le même moteur, à intervalles réguliers, sur l’ensemble des 41 vérifications et des 25 blacklists. Ce qu’il ajoute : reposer la question, remarquer quand une réponse change et vous dire quoi faire.
Problèmes fréquents de MTA-STS
Un fichier de politique inaccessible
Le fichier doit être servi en https depuis mta-sts.yourdomain avec un certificat valide pour ce nom. Un sous-domaine absent, une erreur 404 ou un mauvais certificat laisse l'enregistrement pointer vers rien.
Le mode est sur testing
Les expéditeurs signalent les problèmes TLS à l'adresse de votre enregistrement TLS-RPT (RFC 8460) et livrent quand même. Testing est le bon point de départ, et ne protège rien tant que vous ne passez pas à enforce.
Un MX que la politique ne liste pas
En mode enforce, les expéditeurs refusent de livrer à un hôte MX qui ne correspond à aucune ligne mx: de la politique. Changer de fournisseur de messagerie sans mettre la politique à jour bloque les e-mails entrants.
Une politique modifiée avec le même identifiant
Les expéditeurs gardent la politique en cache et ne la récupèrent à nouveau que quand l'identifiant de l'enregistrement TXT change. Modifiez le fichier sans changer l'identifiant et ils continuent d'utiliser l'ancien jusqu'à l'expiration de max_age.