Test MX et STARTTLS

Comment un message trouve votre serveur

Quand quelqu’un écrit à anna@example.com, son serveur e-mail cherche les enregistrements MX de example.com. Chaque enregistrement nomme un serveur et lui donne un numéro. Le plus petit numéro est essayé en premier et les autres servent de secours. Le serveur expéditeur ouvre alors une connexion sur le port 25 et les deux machines dialoguent en SMTP, un protocole de 1982 qui envoie tout sous forme de texte lisible.

Le chiffrement est venu plus tard, comme une mise à niveau au sein de la même conversation. Le serveur récepteur liste STARTTLS parmi ses capacités, l’expéditeur répond avec le même mot et à partir de là la session est protégée par TLS, la technologie derrière HTTPS. Si le mot n’est pas dans la liste, le message voyage en clair.

Ce que le test fait sur le port 25

Pour cinq serveurs MX au plus, par ordre de priorité, il résout la première adresse IPv4 et joue le début d’une livraison :

S: 220 mx1.example.com ESMTP
C: EHLO <our server>
S: 250-mx1.example.com
S: 250-SIZE 52428800
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
   (négociation TLS, lecture du certificat)
C: QUIT

Et c’est là qu’il s’arrête. Il ne donne jamais d’expéditeur, de destinataire ni de message. Lors de la négociation, il note la version de TLS, le chiffrement, l’émetteur et la date d’expiration du certificat, si le certificat nomme l’hôte MX et si sa chaîne mène à une autorité de confiance.

Ensuite il cherche deux enregistrements DNS et un fichier : l’enregistrement TXT à _mta-sts, la politique à https://mta-sts.example.com/.well-known/mta-sts.txt et l’enregistrement TXT à _smtp._tls.

Lire les quatre tuiles

Serveurs

Combien d’hôtes MX ont répondu à la connexion. Un serveur de secours muet reçoit un avertissement. Si aucun ne répond, les expéditeurs mettent vos e-mails en file d’attente puis les renvoient au bout de quelques jours.

Chiffrement

« Partiel » veut dire qu’au moins un serveur joignable n’a pas terminé STARTTLS. C’est le seul constat ici qui fait passer tout le résultat au rouge alors que les e-mails continuent d’arriver.

Certificats

« À revoir » couvre un certificat expiré, auto-signé, ou émis pour un autre nom. TLS 1.0 et 1.1 sont signalés séparément comme dépassés.

MTA-STS

Montre le mode trouvé dans le fichier de politique : enforce, testing ou none. Il passe au rouge quand l’enregistrement DNS existe mais que le fichier est introuvable, n’a pas de ligne de mode ou omet l’un de vos hôtes MX.

Un domaine sans MX, ou avec l’enregistrement « null MX » 0 ., est signalé comme ne recevant pas d’e-mails. Pour un domaine qui ne sert qu’un site web, c’est une configuration valide.

Pourquoi un mauvais certificat reçoit quand même des e-mails et comment MTA-STS change cela

STARTTLS simple est opportuniste. La plupart des expéditeurs chiffrent quand ils le peuvent et ne vérifient pas le certificat. Quelqu’un qui contrôle le chemin réseau peut donc supprimer la ligne STARTTLS de la réponse et tout lire. MTA-STS ferme cette brèche. Vous publiez, en HTTPS, la liste de vos hôtes MX et la règle selon laquelle ils doivent présenter un certificat valide. Gmail et Outlook.com l’appliquent quand ils vous écrivent.

Le fichier de politique tient en quatre lignes :

version: STSv1
mode: testing
mx: mx1.example.com
max_age: 604800

Servez-le depuis le sous-domaine mta-sts avec un certificat HTTPS valide, puis ajoutez deux enregistrements TXT :

_mta-sts.example.com.   TXT "v=STSv1; id=20260115"
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Restez en testing jusqu’à ce que les rapports TLS-RPT quotidiens reviennent sans échec, puis passez à enforce et changez la valeur de id pour que les expéditeurs rechargent la politique. Avec un e-mail hébergé comme Google Workspace ou Microsoft 365, les certificats MX sont l’affaire du fournisseur. La politique est la seule partie que vous devez publier.