Serveur SMTP : host, port, authentification et service à choisir

Un serveur SMTP est la machine — souvent un service cloud plutôt qu’un matériel — qui reçoit un email envoyé par une application, un client mail ou un script, et le relaie vers le serveur du destinataire. Pour le brancher, il faut trois informations : un host (le nom du serveur, propre à chaque éditeur), un port (25, 587 ou 465 selon le cas d’usage) et des identifiants d’authentification (login/mot de passe ou clé API).

Page éditée par la rédaction de Newsletter Access, dernière mise à jour le 31/08/2026. Ce site est un média indépendant qui compare des services d’emailing ; il n’héberge ni ne gère lui-même de serveur SMTP.

Deux usages différents derrière le même mot

« Serveur SMTP » recouvre en réalité deux besoins distincts, et c’est la première confusion à lever avant de choisir un service :

• SMTP applicatif / transactionnel : un site, une application ou un script envoie des emails déclenchés par une action précise — confirmation de commande, réinitialisation de mot de passe, envoi de facture.
• SMTP marketing : l’envoi de campagnes à une liste de contacts, via un logiciel d’emailing (voir le comparatif des logiciels d’emailing).

Un même éditeur peut couvrir les deux usages avec la même infrastructure d’envoi — c’est le cas de plusieurs services listés plus bas dans ce guide. Cette distinction n’est pas qu’un détail de vocabulaire : elle conditionne le choix du service, car un fort volume transactionnel n’a pas les mêmes exigences de réputation d’IP qu’une campagne marketing ponctuelle envoyée à une liste.

Host, port et identifiants : ce qu’il faut pour se connecter

Pour configurer un serveur SMTP dans un client mail, un CMS ou un script, trois champs sont systématiquement demandés. Ils fonctionnent ensemble : le host indique à quelle machine se connecter, le port indique par quelle porte et avec quel niveau de chiffrement, et les identifiants prouvent au serveur que l’envoi est légitime. L’un des trois manquant, la connexion échoue.

• Le host — le nom du serveur, propre à chaque éditeur (par exemple un sous-domaine dédié). Il se relève sur la documentation officielle de l’outil choisi, jamais deviné.
• Le port — voir le tableau ci-dessous.
• Les identifiants — un couple identifiant/mot de passe ou une clé API, générés depuis le compte de l’éditeur.

Les trois ports SMTP et leur rôle

Le choix du port détermine le niveau de chiffrement de la connexion. Ces trois ports sont normés par l’IETF et ne se périment pas comme un tarif :

En pratique, ces trois ports ne se choisissent pas au hasard. Le port 25 ne concerne pas l’utilisateur final d’une application ou d’un site : c’est le port qu’utilisent les serveurs de messagerie entre eux pour se relayer un message, sans authentification, et il est généralement fermé en sortie sur les hébergements mutualisés précisément pour empêcher l’envoi de spam depuis des machines compromises. Le port 587 est donc, dans l’immense majorité des cas, le premier essayé pour une application ou un script : il exige une authentification, et la connexion démarre en clair avant de monter en TLS via STARTTLS, une négociation qui reste acceptée par la quasi-totalité des fournisseurs de messagerie. Le port 465 reste un choix pertinent quand le logiciel ou la bibliothèque utilisée impose un chiffrement dès l’ouverture de la connexion, sans étape intermédiaire en clair — une exigence qui n’est plus considérée comme dépassée depuis la réhabilitation du port par la RFC 8314.

Pourquoi ne pas utiliser le SMTP de son hébergeur mutualisé

Le serveur SMTP fourni par un hébergeur mutualisé pose plusieurs limites structurelles : l’adresse IP est partagée avec d’autres clients de l’hébergeur, ce qui met la réputation d’envoi hors de son propre contrôle ; les quotas d’envoi sont souvent bas et peu documentés ; et le SPF/DKIM ne sont pas toujours correctement configurés par défaut. Avant d’activer un service d’envoi, il faut de toute façon configurer SPF, DKIM et DMARC pour son domaine — voir le mémo technique dédié à l’authentification email, qui détaille ces réglages.

Quel service SMTP choisir

Le tableau ci-dessous compare les services couramment cités pour le SMTP, sans vainqueur unique : le bon choix dépend du volume et de l’usage (transactionnel pur, marketing, ou les deux).

« Non relevé » : ces valeurs changent régulièrement et n’ont pas pu être vérifiées en direct sur la documentation officielle de chaque éditeur au moment de la publication de cette page. À consulter directement chez l’éditeur avant de choisir.

La fiche complète de Mailjet, avec sa grille tarifaire détaillée, vit sur la page dédiée à Mailjet — ce comparatif ne la reprend pas.

Quel service selon votre profil

• Petit site ou application qui envoie peu de transactionnel : un service au plan gratuit adapté à ce faible volume suffit largement.
• Fort volume applicatif régulier : un spécialiste transactionnel, dont la réputation d’envoi est isolée du trafic marketing, limite le risque qu’une campagne mal reçue n’affecte les emails critiques.
• Besoin mixte, marketing et transactionnel : un ESP généraliste unique évite de gérer deux comptes séparés — voir le comparatif des logiciels d’emailing.
• Profil développeur, recherche du coût minimal au volume : une brique SMTP brute, sans interface de campagne, correspond à ce besoin d’infrastructure pure.

Autres pages de cette rubrique

• A/B test email : quels outils le proposent, et à quel plan
• Délivrabilité email : ce que Gmail, Yahoo et Microsoft exigent
• Taux d’ouverture email : pourquoi ce chiffre est faux depuis 2021