hollop.net

Vérification du serveur de messagerie

Un test pour la réception de courrier d’un domaine : les MX sont-ils corrects, chaque serveur parle-t-il STARTTLS avec un certificat valide, MTA-STS, TLS-RPT et DANE sont-ils bien configurés ?

STARTTLS sur le port 25Politique MTA-STS vérifiéeDANE comparé au vrai certificat
Exemples :

Saisis un domaine, par ex. la partie après le @ de ton adresse e-mail. Les requêtes passent par le serveur hollop.net ; rien n’est enregistré.

DNS via DNS over HTTPS ; la vérification STARTTLS est une connexion SMTP jusqu’à la négociation TLS. Aucun e-mail n’est envoyé.

Fonctionne avec

Vérification SSL →Certificat d’un MX sur le port 25 en détailtransmet directementCAA & DANE →Vérifier ou créer des TLSA pour les MXtransmet directementSPF · DMARC · DKIM →SPF, DMARC et DKIM en détailtransmet directementWhois / RDAP →Bureau d’enregistrement, expiration et DNSSEC du domainetransmet directement

Voir tous les enchaînements →

Ce que vérifie l’outil

L’arrivée des e-mails dépend des enregistrements MX. Leur chiffrement et leur protection en route dépendent de STARTTLS, MTA-STS et DANE. SPF et DMARC empêchent d’autres d’envoyer en ton nom.

MTA-STS et TLS-RPT

STARTTLS seul peut être supprimé : un attaquant retire l’offre et l’expéditeur livre en clair. MTA-STS (RFC 8461) l’empêche. Tu publies en HTTPS une politique indiquant les MX valides et l’obligation de TLS. Les expéditeurs la gardent max_age secondes.

  1. Enregistrement TXT _mta-sts.example.com avec v=STSv1; id=20261113. Augmente l’id à chaque changement de politique.
  2. Le fichier https://mta-sts.example.com/.well-known/mta-sts.txt avec version, mode, une ligne mx par MX et max_age. Certificat valide pour mta-sts.example.com, sans redirection.
  3. Commence avec mode: testing et configure TLS-RPT (_smtp._tls). Après quelques semaines de rapports propres, passe en enforce.

Important : si un MX manque dans la politique ou a un certificat invalide, les expéditeurs en mode enforce n’y livrent plus. Vérifie le certificat du MX dans la vérification SSL avec le port 25.

DANE

DANE (RFC 7672) lie le certificat au DNS via un enregistrement TLSA et exige DNSSEC pour la zone des MX. L’usage courant est 3 1 1, le hachage SHA-256 de la clé publique. Lors d’un changement de certificat, publie d’abord le nouveau TLSA, sinon les expéditeurs DANE ne livrent pas. Crée et vérifie des TLSA sous CAA & DANE.

Le port 25 depuis ici

Pour STARTTLS, le serveur ouvre une connexion SMTP sur le port 25. Si l’hébergeur bloque ce port en sortie, l’outil le signale. La commande openssl sous le résultat aide alors.

FAQ

Quelle différence entre MTA-STS et DANE ?

Les deux imposent une livraison chiffrée. MTA-STS s’appuie sur HTTPS et les autorités de certification publiques, sans DNSSEC. DANE place le certificat dans le DNS et exige DNSSEC. Google et Microsoft gèrent MTA-STS, beaucoup de fournisseurs européens DANE. Les deux ensemble sont possibles.

Faut-il un serveur web pour MTA-STS ?

Oui, un petit fichier texte doit être servi en HTTPS sur mta-sts.ton-domaine. N’importe quel hébergement avec certificat valide suffit.

Pourquoi « port 25 injoignable » ?

Soit le pare-feu du serveur de messagerie refuse les connexions, soit notre serveur ne peut pas joindre le port 25 en ce moment. L’outil détecte ce second cas par une contre-vérification et le signale.

Un e-mail est-il envoyé pendant le test ?

Non. La connexion se termine juste après la négociation TLS, avant tout expéditeur.

Où vérifier DKIM ?

DKIM dépend du sélecteur de l’expéditeur et ne s’interroge pas pour tout un domaine. L’outil SPF · DMARC · DKIM permet de vérifier un sélecteur précis.