Test SMTP en ligne

Quand un serveur SMTP cesse de répondre, la boutique n’envoie plus ses confirmations de commande. Le copieur du couloir refuse ses numérisations. Et le logiciel de gestion garde ses avis d’échéance au chaud sans prévenir personne. Avant de retourner votre configuration dans tous les sens, il suffit souvent de tester le serveur SMTP pour savoir de quel côté chercher.

L’outil ci-dessous fait ce test en direct. Il ouvre une vraie connexion vers le serveur que vous indiquez, déroule le même dialogue que votre logiciel de messagerie, puis vous rend la transcription complète. Comptez une dizaine de secondes.

Ce que nous enregistrons : rien. Aucun serveur testé, aucun identifiant, aucun mot de passe, aucun résultat n'est conservé. Pas de base de données, pas de journal, pas d'email. Un compteur anonyme limite simplement le nombre de tests par adresse pour éviter que l'outil serve à scanner des réseaux. Les adresses privées et les ports autres que SMTP sont refusés, pour la même raison.

Ce que le test SMTP vérifie, étape par étape

Un envoi d’email échoue rarement pour une seule raison. Le test décompose donc la séquence et s’arrête à la première marche qui casse.

La connexion TCP ouvre la porte. Si elle échoue, le problème n’a rien à voir avec vos identifiants : soit rien n’écoute sur ce port, soit un pare-feu s’interpose. C’est le cas le plus courant chez les fournisseurs d’accès qui ferment le port 25 sortant.

La bannière est la première phrase du serveur. Elle commence par 220 et donne son nom réel. Comparez-la au nom que vous avez saisi : un écart signale souvent un enregistrement DNS qui pointe ailleurs que là où vous croyez.

La présentation EHLO demande au serveur ce dont il est capable. Sa réponse liste les extensions disponibles, dont STARTTLS et les méthodes d’authentification. Un serveur qui refuse EHLO à ce stade filtre probablement votre adresse IP.

Le chiffrement est négocié ensuite. En STARTTLS, la connexion démarre en clair puis bascule. En SSL direct, elle est chiffrée dès la première seconde. Le test valide au passage le certificat : expiré, auto-signé ou établi pour un autre nom de domaine, il fait échouer la négociation, et votre logiciel se comportera exactement pareil.

L’authentification n’est testée que si vous renseignez des identifiants, et uniquement une fois le canal chiffré. Envoyer un mot de passe en clair sur un port non chiffré n’a aucun intérêt, même pour un test.

Comment lire le résultat

Chaque étape ressort avec un statut, et la nuance entre les trois compte.

Statut	Ce que ça veut dire	Ce qu’il faut faire
Réussi	L’étape s’est déroulée normalement	Rien, passez à la suivante
Avertissement	Ça fonctionne, mais dans des conditions discutables	Corriger quand vous pourrez, ce n’est pas bloquant
Échec	La séquence s’arrête là	Traiter cette étape avant de regarder les autres

La transcription complète est affichée en dessous. Les lignes précédées de > sont ce que le testeur envoie, les autres ce que le serveur répond. C’est la même chose que ce que verrait un telnet, en plus lisible, et c’est ce qu’il faut copier dans un ticket de support quand vous en ouvrez un.

Quel port SMTP essayer, et dans quel ordre

Commencez par le port 587 en STARTTLS. C’est le port de soumission des messages authentifiés, et il fonctionne dans la grande majorité des cas. Il circule beaucoup de folklore sur les ports SMTP, mais quatre cas couvrent presque tout.

Port	Mode	Quand l’utiliser
587	STARTTLS	Le choix par défaut, celui à essayer en premier. C’est le port dédié à la soumission de messages authentifiés
465	SSL direct	Quand le logiciel ou l’appareil ne sait pas faire de STARTTLS. Beaucoup de copieurs sont dans ce cas
25	STARTTLS ou clair	Le port historique, entre serveurs. Bloqué en sortie par la plupart des fournisseurs d’accès et des hébergeurs
2525 et suivants	STARTTLS	Ports de repli, quand un pare-feu d’entreprise ferme les précédents

Si le 587 échoue et que le 465 passe, ne cherchez pas plus loin : c’est un filtrage réseau, pas une panne du serveur. Les alternatives disponibles chez nous sont détaillées sur la page flexibilité.

Les erreurs SMTP que vous allez rencontrer, et ce qu’elles disent

Les codes d’erreur SMTP sont normalisés, et leur premier chiffre suffit à trancher. Un code en 4xx est temporaire, le serveur vous demande de repasser plus tard. Un code en 5xx est définitif, insister ne servira à rien.

Ce que vous voyez	Cause réelle	Piste
Connexion refusée	Rien n’écoute sur ce port	Vérifier le port, puis le nom du serveur
Délai dépassé	Un pare-feu avale les paquets sans répondre	Essayer un autre port, tester depuis un autre réseau
421	Serveur saturé, ou envoi bridé volontairement	Ralentir la cadence d’envoi
535	Identifiant ou mot de passe refusé	Vérifier que l’identifiant est bien l’adresse complète
550	Le destinataire refuse le message	Adresse inexistante, ou réputation de l’IP émettrice
554 5.7.1	Relais interdit, ou message assimilé à du spam	Authentification manquante, SPF ou DKIM absents
Certificat rejeté	Certificat expiré, auto-signé, ou nom incorrect	Corriger le certificat, ne jamais désactiver la vérification

Le détail des codes de rejet et des rapports d’envoi se trouve dans notre guide sur les codes d’erreur des messages non délivrés.

Un test au vert ne veut pas dire que vos emails arrivent

Un test SMTP réussi prouve que le serveur accepte votre connexion. Il ne prouve pas que vos messages atterrissent en boîte de réception. C’est le malentendu le plus répandu, et il coûte cher en temps perdu.

Ce testeur valide le transport : le serveur répond, le canal est chiffré, vos identifiants sont acceptés. Il ne dit rien de ce qui se passe après, quand le message quitte le serveur et se présente chez Gmail, Outlook ou La Poste. Là, d’autres critères prennent le relais, et ils n’ont rien à voir avec la connexion.

L’authentification de votre domaine en fait partie. Sans enregistrement SPF publié et sans signature DKIM, un message parfaitement transmis finira quand même en indésirable chez une bonne partie des destinataires. La réputation de l’adresse IP qui porte vos envois compte tout autant, et c’est un travail de fond, pas un réglage. Nous détaillons ces deux volets sur la page sécurité.

Autrement dit : un test réussi élimine la moitié des causes possibles. C’est déjà beaucoup quand on cherche une panne, mais ce n’est pas un certificat de bonne délivrabilité.

Pourquoi le SMTP de votre hébergeur finit par lâcher

Il y a une catégorie de résultats qui revient souvent, et qui n’est pas vraiment une panne.

Le serveur répond, la connexion est bonne, l’authentification passe, et pourtant les emails partent mal. Ce sont les quotas. Un hébergement mutualisé impose une limite d’envoi par heure et par jour, partagée entre tous les comptes du serveur. Tant que votre site envoie trois emails par semaine, personne ne le remarque. Le jour où la boutique fait vingt commandes dans la journée, ou bien le jour où l’application de gestion locative expédie ses avis d’échéance à la même heure, la limite tombe et les messages sont mis en attente, ou perdus.

Le même mécanisme frappe les copieurs multifonctions depuis que Microsoft a fermé l’authentification SMTP simple sur Microsoft 365. Les appareils ne savent pas gérer les protocoles d’authentification modernes. Ils ont besoin d’un relais qui accepte un identifiant et un mot de passe, tout simplement.

Dans ces deux cas, le testeur affiche du vert et le problème persiste, parce que le problème n’est pas technique. Il est contractuel. C’est exactement la raison d’être d’un relais SMTP indépendant : un compte à vous, un quota que vous choisissez, des adresses IP françaises dont la réputation est surveillée, et rien qui dépende de votre hébergeur. Nos tarifs commencent à 29 euros par an.

Questions fréquentes

Est-ce que vous enregistrez le serveur ou le mot de passe que je saisis ? Non, rien du tout. Le mot de passe est utilisé le temps de la connexion, en mémoire, puis disparaît. Il n’apparaît pas dans la transcription affichée, qui le remplace par des astérisques. Aucune donnée saisie n’est écrite en base ni dans un journal.

Le test échoue alors que mon logiciel envoie correctement, c’est possible ? Oui, et c’est instructif. Notre testeur part de nos serveurs, pas de votre poste. Si votre logiciel fonctionne et que le test échoue, le serveur filtre probablement par adresse IP, ou bien il n’est accessible que depuis votre réseau interne.

Puis-je tester un serveur sur mon réseau local ? Non. L’outil refuse volontairement les adresses privées, en 192.168, 10.x et assimilées, ainsi que tous les ports qui ne sont pas des ports SMTP. Un testeur public sans cette restriction devient un outil de reconnaissance pour n’importe qui.

Pourquoi le test d’authentification est-il ignoré sur un port non chiffré ? Parce qu’il enverrait votre mot de passe en clair sur le réseau. Nous refusons de le faire, même pour un test. Basculez en STARTTLS ou en SSL direct.

Est-ce la même chose qu’un « SMTP checker » ? Oui, c’est le nom anglais du même outil. La plupart des SMTP checkers se contentent d’annoncer que le port est ouvert. Celui-ci va jusqu’au bout du dialogue, vérifie le certificat et teste l’authentification si vous le demandez.

Que faire de la transcription ? Copiez-la telle quelle dans votre demande au support, le vôtre ou le nôtre. Elle contient l’enchaînement exact des réponses du serveur, ce qui évite plusieurs allers-retours de diagnostic.