Le protocole SMTP achemine vos emails depuis un client ou une application jusqu’au serveur du destinataire et chaque connexion passe par un port précis. Pour la soumission depuis un client de messagerie ou un script d’envoi, utilisez le port 587 avec STARTTLS par défaut. Le port 465 fonctionne en TLS implicite et reste une alternative tout aussi valide. Le port 25 sert au transfert entre serveurs et se retrouve bloqué chez la plupart des fournisseurs d’accès et des hébergeurs cloud. Le port 2525 dépanne quand 587 est filtré par un réseau tiers. Ce guide détaille comment vérifier le bon port en 2 minutes avec une seule commande.
Les 4 ports SMTP et leur usage réel
Chaque port correspond à un rôle précis dans la chaîne d’envoi, fixé par les normes du protocole. Le port 25 est le port historique du protocole, réservé au transfert de serveur à serveur (MTA à MTA) : un serveur mail qui relaie un message vers un autre serveur mail passe par là, jamais un client de messagerie ou une application qui soumet un email. Le port 587 a été normalisé en 2007 (RFC 4409, remplacée depuis par la RFC 6409) spécifiquement pour la soumission authentifiée, avec un chiffrement activé après connexion via la commande STARTTLS. Le port 465 a une histoire plus mouvementée. Assigné dans les années 1990 pour SMTP sur SSL, il a été jugé obsolète pendant près de 20 ans au profit du 587, puis officiellement réhabilité. La RFC 8314, publiée par l’IETF en janvier 2018, réintègre le port 465 comme port officiel de soumission en TLS implicite et le présente comme la direction technique recommandée à long terme, devant le 587.
La RFC 8314 qualifie l’usage du texte en clair de dépassé pour la soumission et l’accès aux messages et recommande le chiffrement dès l’ouverture de la connexion plutôt que son activation en cours d’échange (IETF, janvier 2018).
Le port 2525 ne fait l’objet d’aucune normalisation IETF. Il sert de repli quand un réseau filtre 587 et 25 et la plupart des routeurs email commerciaux le supportent, sans que ce port soit garanti chez tous les fournisseurs.
STARTTLS ou TLS implicite : la différence concrète
STARTTLS ouvre la connexion en clair, puis le client envoie la commande STARTTLS pour basculer vers un canal chiffré avant d’échanger identifiants et contenu du message. Le TLS implicite chiffre dès la première poignée de main TCP : aucune donnée ne circule en clair, même pendant la négociation. RFC 8314 justifie ce choix par le risque d’interception pendant la courte fenêtre en clair qui précède la commande STARTTLS, une fenêtre qu’un intercepteur actif sur le réseau peut exploiter pour forcer une connexion non chiffrée. Un client mal configuré peut envoyer un mot de passe SMTP sans protection si le serveur ne rejette pas les tentatives sans STARTTLS. C’est tout ce qui distingue les deux mécanismes du point de vue de la sécurité de la connexion.
Pourquoi le port 25 est bloqué en sortie
Le blocage est volontaire : il relève d’une politique contre le spam sortant. Les fournisseurs d’accès français grand public (Orange, Free, SFR, Bouygues Telecom) filtrent les connexions sortantes en 25 sur leurs box pour empêcher les machines compromises de leur parc de relayer du spam directement vers Internet. Le raisonnement est identique côté cloud : d’après la documentation officielle d’AWS, le trafic sortant sur le port 25 est bloqué par défaut pour toutes les instances EC2 et fonctions Lambda, sauf demande explicite de levée validée par un ticket de support. OVHcloud applique une restriction comparable sur une partie de son catalogue d’hébergement mutualisé. L’échec est systématique. Une application hébergée sur un VPS ou une box grand public qui tente d’envoyer directement en port 25 échoue quelle que soit la qualité de sa configuration DNS ou de son contenu. La solution n’est pas de contourner ce blocage mais de soumettre le message sur 587 ou 465, ports que ces mêmes réseaux laissent ouverts.
Quel port utiliser selon votre fournisseur
Le tableau suivant liste uniquement les ports acceptés en soumission. Pour l’adresse exacte du serveur de votre fournisseur, consultez notre guide pour trouver le serveur SMTP de sa messagerie.
| Fournisseur | Ports acceptés | Remarque |
|---|---|---|
| Gmail | 587, 465 | 587 recommandé par Google, authentification obligatoire sur les deux |
| Outlook / Microsoft 365 | 587 | 465 non pris en charge par le relais SMTP Microsoft 365 |
| Yahoo | 587, 465 | Authentification à 2 facteurs impose un mot de passe d’application |
| Orange | 465 | Seul port officiellement recommandé pour smtp.orange.fr ; le 587 n’existe que sur le serveur Orange Business, distinct du compte grand public |
| Free | 465 | 587 non systématiquement proposé selon l’offre |
| SFR | 465, 587 | 465 recommandé en premier, 587 en repli si le réseau bloque le SSL direct |
| Bouygues Telecom | 587, 465 | 587 STARTTLS fonctionne notamment sur iOS, 465 SSL en alternative |
| OVHcloud | 465, 587 | 465 en SSL direct, 587 en STARTTLS selon l’offre mail |
| Ionos | 587, 465 | 587 STARTTLS recommandé en premier par l’éditeur |
Tester si un port SMTP est ouvert
Deux commandes suffisent à vérifier qu’un port répond avant de modifier une configuration à l’aveugle. Avec OpenSSL installé, lancez openssl s_client -connect smtp.exemple.com:587 -starttls smtp depuis un terminal. Une réponse qui commence par 220 suivi du nom du serveur confirme que le port écoute et accepte la négociation STARTTLS. Sans OpenSSL, telnet fait l’affaire pour un test basique : telnet smtp.exemple.com 587. Une sortie qui affiche 220 mail.exemple.com ESMTP ready signifie que la connexion TCP s’établit. Si l’invite reste vide plusieurs secondes puis se ferme, le port est filtré quelque part entre votre machine et le serveur, souvent par un pare-feu local ou une box grand public. Ce test prend moins de 2 minutes et évite de deviner à l’aveugle quel élément de la chaîne bloque réellement l’envoi.
Comprendre les erreurs de connexion SMTP
3 messages reviennent le plus souvent quand un envoi échoue. Chacun pointe vers une cause différente.
- Connection timed out : la connexion TCP n’aboutit jamais. Le port est bloqué par un pare-feu, une box FAI ou une règle de sécurité cloud avant même d’atteindre le serveur mail. Testez un autre port (587 si 25 échoue, 2525 si 587 échoue aussi) plutôt que de modifier les identifiants.
- Connection refused : la machine cible répond mais rien n’écoute sur ce port précis. Le serveur SMTP existe mais le service n’est pas configuré sur ce numéro de port ou tourne sur une autre interface réseau. Vérifiez le port réellement ouvert avec la commande openssl vue plus haut avant de changer la configuration du client.
- Must issue a STARTTLS command first : le serveur exige un chiffrement et le client tente d’envoyer des identifiants en clair. Le paramètre à corriger est la sécurité côté client, STARTTLS sur 587 ou SSL/TLS sur 465. Le numéro de port reste correct.
Un message d’erreur qui mentionne un délai ou un refus concerne quasiment toujours le port ou le pare-feu, jamais le contenu de l’email. Un message qui mentionne l’authentification ou le chiffrement concerne le paramètre de sécurité de la connexion, indépendamment du numéro de port. Cette distinction évite de reconfigurer SPF, DKIM, DMARC ou le contenu du message alors que le problème se situe une couche en dessous, au niveau du transport.
Si votre propre serveur reste filtré malgré un port correctement ouvert côté client, passer par un relais SMTP contourne le blocage sans toucher à votre infrastructure.
Le bon port ouvre la connexion. Il ne garantit rien sur la suite du trajet : des messages qui partent normalement mais finissent en dossier spam pointent vers l’authentification du domaine expéditeur et vers la propreté de la liste de contacts envoyée.
