Qu'est-ce qu'un serveur SMTP ? Hôte, port, utilisateur et mot de passe

Ce qu'un serveur SMTP fait réellement

Un serveur SMTP est un programme qui écoute sur un port réseau et parle le protocole SMTP. Quand vous cliquez sur envoyer dans un client de messagerie, quand vous validez un formulaire de contact ou quand vous appelez une fonction d'envoi dans votre application, le message ne part pas directement vers le destinataire : il arrive d'abord à un serveur qui accepte d'en prendre la responsabilité. Ce serveur lit l'enveloppe — qui prétend être l'expéditeur et à qui le message est destiné —, décide s'il peut l'accepter, puis le fait avancer. Deux rôles différents portent le nom de « serveur SMTP », et ils ne se comportent pas du tout de la même manière.

La soumission est le premier rôle. Le serveur de votre fournisseur accepte un message venant de vous, de votre application ou de votre CRM, en votre nom. Il exige une authentification, attend un chiffrement, et écoute sur les ports 587 ou 465. C'est le rôle qui se cache derrière chaque écran de « réglages SMTP » que vous avez rempli. Le relais est le second rôle : un serveur de messagerie qui remet un message à un autre serveur de messagerie pendant qu'il voyage vers le domaine du destinataire. Le relais fonctionne sur le port 25, et le serveur qui le reçoit le juge sur la réputation de l'IP émettrice et sur les enregistrements DNS, pas sur un mot de passe. Personne ne s'authentifie auprès d'un relais comme votre application s'authentifie pour soumettre.

Cette distinction compte parce que le serveur de soumission est aussi ce qui construit votre réputation d'expéditeur. Chaque message que vous lui remettez est associé à votre compte et, dès qu'un domaine que vous contrôlez apparaît dans l'en-tête From, à ce domaine également. C'est pourquoi l'authentification n'est pas une formalité facultative : un chemin de soumission négligé est la manière habituelle de finir sur une liste de blocage, et un courrier parti d'un serveur que personne ne peut relier à vous ne peut pas non plus être relié à vous en votre faveur.

Les quatre réglages de connexion, un par un

Tout client de messagerie, toute application et toute bibliothèque demandent les mêmes quatre valeurs sous une forme ou une autre. Voici ce qu'elles sont, à quoi elles ressemblent, d'où elles viennent et où l'erreur se glisse le plus souvent.

L'hôte

C'est l'adresse du serveur lui-même, écrite comme un nom d'hôte, par exemple smtp.gmail.com ou smtp.yourprovider.com. Elle vient de la documentation de votre fournisseur de messagerie ou du panneau de contrôle de votre hébergeur. L'erreur courante est d'y mettre le domaine de votre site, ou la partie de votre adresse qui suit le @. Ces deux valeurs indiquent au monde où votre courrier vous est livré, pas quel serveur accepte celui que vous envoyez, et ce sont souvent des machines différentes.

Le port

C'est le canal numéroté sur cet hôte. Le 587 avec STARTTLS est la valeur par défaut pour la soumission, et le 465 s'utilise quand la connexion doit être chiffrée dès le premier octet (TLS implicite). Le numéro vient de la documentation de votre fournisseur, pas d'une supposition. L'erreur courante est de laisser le port 25 en place, ou d'associer le mauvais mode de chiffrement au port choisi. Notre guide des ports SMTP détaille cette association.

L'utilisateur

En général votre adresse e-mail complète, parfois un identifiant qui ne correspond à aucune boîte aux lettres et, chez certains fournisseurs, l'identifiant d'une clé API. Il désigne la boîte aux lettres ou l'identité d'envoi que vous êtes autorisé à utiliser. L'erreur courante est de fournir un nom d'affichage, un alias, ou les identifiants du panneau de contrôle plutôt que ceux de la boîte aux lettres.

Le mot de passe

Le mot de passe de la boîte aux lettres, un mot de passe d'application lorsque la validation en deux étapes est activée, ou un secret d'API chez un fournisseur d'envoi. Ce n'est jamais le mot de passe avec lequel vous vous connectez au panneau de votre site ou à celui de votre hébergeur. L'erreur courante est de coller le mot de passe du compte là où le fournisseur exige désormais un mot de passe d'application généré, et c'est exactement pourquoi Gmail et Microsoft 365 rejettent autant de premières tentatives.

Une valeur manque visiblement dans cette liste, et c'est celle vers laquelle on se tourne quand quelque chose échoue. L'adresse d'expédition (From) n'est pas un identifiant. C'est un en-tête que les destinataires voient, et il doit se trouver sur un domaine pour lequel vous êtes autorisé à envoyer ; sinon le serveur de soumission aura toutes les raisons d'accepter votre message et aucune de le rendre délivrable.

Formulaire de configuration MailCannon affichant les champs hôte SMTP, port, utilisateur, mot de passe et SSL/TLS

La capture ci-dessus montre ces mêmes quatre valeurs dans une interface réelle : MailCannon demande un nom, un hôte, un port, un utilisateur, un mot de passe et un mode de chiffrement, et rien d'autre. Si la documentation de votre fournisseur vous donne correctement ces quatre valeurs, le formulaire est déjà résolu.

Où trouver vos réglages SMTP

Presque tous ceux qui cherchent l'adresse de leur serveur SMTP cherchent en réalité le nom d'hôte et le port attendus par leur fournisseur. Voici les quatre sources que vous rencontrerez le plus souvent.

Fournisseur	Hôte	Port	Utilisateur	Mot de passe
Google Workspace / Gmail	`smtp.gmail.com`	587 ou 465	votre adresse Gmail complète	un mot de passe d'application de 16 caractères, car Google n'accepte plus le mot de passe du compte
Microsoft 365 / Outlook	`smtp.office365.com`	587	l'adresse complète de votre boîte aux lettres	le mot de passe de la boîte ou un mot de passe d'application ; SMTP AUTH doit parfois être activé boîte par boîte
cPanel / hébergement mutualisé	`mail.yourdomain.com` ou le nom d'hôte de votre e-mail de bienvenue	587 ou 465	l'adresse complète créée dans le panneau	le mot de passe que vous avez défini pour cette boîte
Amazon SES	`email-smtp.<region>.amazonaws.com`	587, 465 ou 25	l'utilisateur SMTP généré dans la console	le mot de passe SMTP généré avec lui

Les valeurs par défaut des fournisseurs changent : vérifiez donc ces informations dans la documentation actuelle de votre fournisseur avant de les figer quelque part.

Authentification et causes d'échec

La plupart des problèmes SMTP cessent d'être mystérieux dès que vous lisez le code de réponse. Quatre cas couvrent l'immense majorité des configurations qui échouent.

535 authentication failed. L'utilisateur est faux, ou un mot de passe de compte ordinaire a été envoyé là où le fournisseur exige désormais un mot de passe d'application ou un secret d'API.
550 relay denied. L'utilisateur s'est authentifié, mais il n'est pas autorisé à envoyer pour le domaine présent dans l'en-tête From : une incohérence entre la boîte avec laquelle vous vous êtes connecté et l'adresse depuis laquelle vous prétendez envoyer.
Délai de connexion dépassé. Le port est faux, ou votre réseau le bloque. Si le serveur ne répond pas du tout, vérifiez quels ports SMTP vous sont ouverts avant de toucher aux identifiants.
Erreurs de certificat ou de poignée de main. Du TLS implicite configuré sur un port STARTTLS, ou l'inverse. La connexion atteint le serveur, puis les deux côtés ne sont pas d'accord sur le début du chiffrement.

Une fois l'authentification réussie, il reste une question : les fournisseurs de boîtes aux lettres vous font-ils confiance ? Cela se décide par les enregistrements de votre domaine, pas par la connexion, et c'est ce que couvre notre guide sur SPF, DKIM et DMARC.

Un serveur SMTP n'est pas une API e-mail

Les deux chemins aboutissent au même endroit : un message qui arrive au serveur de messagerie du destinataire. La différence tient à tout ce que vous gérez en route. Avec SMTP, vous gérez vous-même la connexion — l'hôte, le port, les identifiants, la logique de nouvelle tentative quand un serveur refuse temporairement un message, et la réputation de l'IP que votre fournisseur vous prête. Quand quelque chose casse, c'est à vous d'interpréter l'erreur.

Une API e-mail confie presque tout cela au fournisseur. L'authentification, les nouvelles tentatives, les pools d'IP et la réputation deviennent son problème, et vous envoyez une requête structurée au lieu de parler un protocole. La plupart des produits finissent par utiliser les deux : SMTP pour les boîtes aux lettres depuis lesquelles les gens répondent réellement, une API pour l'envoi à grand volume. La documentation MailCannon couvre les deux chemins, et MailCannon accepte aussi bien un serveur SMTP personnalisé qu'une clé API de fournisseur : vous pouvez donc commencer avec la boîte aux lettres que vous avez déjà.

Questions fréquentes

Qu'est-ce que l'adresse d'un serveur SMTP ?

C'est le nom d'hôte et le port auxquels votre client se connecte, par exemple smtp.gmail.com sur le port 587. On dit « adresse » en pensant aux deux parties, car se tromper sur l'une ou l'autre produit le même échec.

Ai-je besoin de mon propre serveur SMTP ?

Non. Presque toutes les entreprises envoient via le serveur de leur fournisseur de messagerie ou via un fournisseur d'envoi. Faire tourner le vôtre signifie gérer vous-même la réputation de l'IP, le DNS inverse, les listes de blocage et les plaintes pour abus : un vrai travail, et rarement le cœur du produit que vous construisez.

Quel port utiliser pour SMTP ?

Le 587 avec STARTTLS, ou le 465 avec TLS implicite si votre fournisseur le documente. Le port 25 sert au relais entre serveurs et il est généralement bloqué en sortie.

Mon utilisateur SMTP est-il mon adresse e-mail ?

En général oui, surtout chez les fournisseurs de boîtes aux lettres. Certains délivrent un identifiant distinct, et d'autres — Amazon SES est l'exemple classique — vous donnent un utilisateur et un mot de passe SMTP générés dans leur console, sans aucun lien avec une boîte aux lettres.

Qu'est-ce qu'un relais SMTP ?

Au sens strict, un serveur de messagerie qui transmet un message à un autre serveur au lieu de le remettre directement à sa destination. Le terme désigne aussi, plus largement, un fournisseur d'envoi qui accepte votre courrier et le remet pour vous.

Puis-je envoyer des e-mails en masse depuis le serveur SMTP de mon hébergeur ?

En général non, et surtout pas en volume. Les hébergeurs mutualisés plafonnent l'envoi horaire et leurs IP sont souvent mauvaises pour l'envoi massif, car des milliers d'autres clients partagent la même réputation. Pour des campagnes, utilisez un fournisseur prévu pour cela.

Étape suivante

Avec les quatre réglages en main, les lectures naturelles qui suivent sont notre explication de ce qu'est SMTP et le guide des ports SMTP. Ensuite, mettez les identifiants au travail : passez le Vérificateur de délivrabilité sur votre domaine, puis ajoutez le serveur dans les réglages MailCannon pour envoyer votre première campagne avec lui.