← Tous les guides

587, sauf si on vous dit 465

Lequel choisir, pourquoi le vôtre est bloqué, et ce qu'un port ouvert ne règle pas.

6 minutes de lecture

Les trois ports en un coup d'œil

PortÀ quoi il sertChiffrementPour qui
587Déposer un message sur son serveur d'envoiSTARTTLS (démarre en clair, passe en chiffré)Vous, par défaut
465La même choseTLS dès la connexionVous, si votre fournisseur l'indique
25Relier deux serveurs de messagerie entre euxOpportuniste, sans authentificationLes serveurs — bloqué presque partout ailleurs

Le port de soumission est défini par la RFC 6409 (2006) ; le retour en grâce du 465 vient de la RFC 8314 (2018), qui recommande le chiffrement dès la connexion. Ce ne sont pas des conventions de fournisseur : c'est pour ça qu'un même port se comporte pareil partout.

Trois numéros reviennent dès qu'on configure un envoi d'e-mails, et la moitié des réglages ratés tiennent à les confondre. Ils ne font pas la même chose : l'un relie deux serveurs entre eux, les deux autres servent à vous, qui déposez un message.

Le port 587, celui qu'il vous faut presque toujours

C'est le port de soumission : celui par lequel un logiciel remet un message à son serveur d'envoi, avec un identifiant et un mot de passe. La connexion démarre en clair puis passe en chiffré par la commande STARTTLS.

C'est le choix par défaut, et il l'est depuis longtemps : la norme qui le décrit a vingt ans. Si votre fournisseur ne dit rien, prenez 587.

Le port 465, revenu en grâce

Il fait la même chose, mais chiffré dès la première seconde : pas de phase en clair, pas de commande STARTTLS. Longtemps donné pour périmé, il a été réhabilité en 2018 par une norme qui le recommande explicitement pour la soumission.

En clair : 465 et 587 sont tous les deux bons. Prenez celui que votre fournisseur indique, et ne changez pas d'avis au milieu d'un réglage qui marche.

Le port 25, qui n'est pas pour vous

Le 25 relie les serveurs entre eux. Ce n'est pas un port de dépôt : on ne s'y authentifie pas, et c'est précisément pour ça qu'il a été le port des envois indésirables pendant vingt ans.

La plupart des fournisseurs d'accès le bloquent en sortie, sur les connexions résidentielles comme sur beaucoup de serveurs mutualisés. Si votre logiciel est réglé sur 25 et que rien ne part, c'est presque toujours ça — et le correctif n'est pas d'insister, c'est de passer en 587.

Un domaine d'envoi authentifié, et ses enregistrements DNS.VérifiéCe domaine est authentifiéTYPENOMVALEURCNAMEpm1._domainkeypm1.dkim.plumail.frCNAMEpm2._domainkeypm2.dkim.plumail.frTXT@v=spf1 include:…
Un domaine d'envoi authentifié, et ses enregistrements DNS.

Quand rien ne part

Pourquoi ça ne passe toujours pas

  • Le pare-feu de la machine ou du réseau. Un port sortant fermé se manifeste par un délai d'attente, pas par un refus : le message reste en file, sans explication.
  • L'hébergeur mutualisé. Beaucoup interdisent toute connexion SMTP sortante vers l'extérieur et imposent leur propre serveur. C'est écrit dans leur documentation, rarement dans leur interface.
  • Le mot de passe. Sur un compte protégé par une double authentification, le mot de passe habituel ne passe pas : il faut un mot de passe d'application, généré à part.

Ce qu'un bon port ne règle pas

Un port ouvert transporte votre message ; il ne prouve pas qui vous êtes. L'authentification du domaine — SPF, DKIM, DMARC — se joue ailleurs, dans vos enregistrements DNS, et c'est elle que Gmail et Yahoo regardent avant de décider où poser votre lettre.

Autrement dit : un réglage SMTP parfait sur un domaine non authentifié finit en indésirable, sans qu'aucun port n'y puisse quoi que ce soit.

Envoyer sans régler de port

Avec Plumail, l'envoi passe par une API HTTP, et l'authentification du domaine se règle une fois, guidée. 3 000 envois par mois offerts, sans carte bancaire.