376 milliards d’emails ont circulé chaque jour dans le monde en 2025, d’après le rapport Email Statistics Report 2024-2028 du Radicati Group. Chacun d’eux transite par le même dialogue texte, largement inchangé depuis 1982. SMTP (Simple Mail Transfer Protocol) est le protocole qui achemine un email depuis le logiciel de l’expéditeur jusqu’au serveur du destinataire, en s’appuyant sur une suite de commandes courtes échangées sur une connexion TCP. Il ne s’occupe ni de la réception ni du stockage du message, deux tâches confiées à d’autres protocoles.
Ce que SMTP fait réellement se limite à trois gestes : ouvrir une connexion vers le bon serveur, transmettre l’enveloppe qui indique qui envoie et à qui, puis livrer le contenu du message. Le reste de la chaîne repose sur des couches ajoutées après coup, bien après la publication du protocole d’origine. Authentification et chiffrement forment la première strate ; filtrage anti-spam et tri en boîte de réception, la seconde.
Le rôle de SMTP dans l’envoi d’un email
Un email traverse quatre étapes avant d’atteindre une boîte de réception et SMTP n’en couvre que deux. Le MUA, le logiciel de messagerie que l’expéditeur utilise pour rédiger son message (Outlook, Gmail, Thunderbird), transmet le message à un MSA, le serveur qui accepte la soumission après avoir vérifié l’identité de l’expéditeur. Le MSA passe ensuite la main à un MTA, qui relaie le message de serveur en serveur jusqu’à celui qui héberge la boîte du destinataire. Ce dernier serveur remet enfin le message à un MDA, chargé de le déposer dans la boîte concernée. SMTP pilote les deux maillons du milieu : la soumission par le MSA et le transfert par le MTA. À noter, un même logiciel serveur (Postfix, Exim, Microsoft Exchange) endosse fréquemment les deux rôles à la fois, ce qui brouille la distinction dans la pratique quotidienne mais ne la fait pas disparaître dans les échanges de commandes eux-mêmes.
RFC 5321 et RFC 5322 : l’enveloppe et le message
« The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. » RFC 5321, IETF, 2008.
Deux normes distinctes gouvernent un email et la confusion entre les deux explique une bonne part des malentendus sur la délivrabilité. La RFC 5321 encadre SMTP lui-même : elle définit les commandes, les codes de réponse et les règles de transport de l’enveloppe. La RFC 5322, publiée le même mois d’octobre 2008, régit un objet différent : le format du message transporté, avec ses en-têtes From, To, Subject, Date et Message-ID. Cette séparation remonte au tout premier ancêtre du protocole, la RFC 821, publiée en août 1982 par Jonathan Postel à l’Information Sciences Institute de l’université de Californie du Sud. Elle a été remplacée par la RFC 2821 en 2001, elle-même remplacée par l’actuelle RFC 5321 en 2008. Rien depuis n’a exigé de réécriture complète du transport lui-même, seulement des extensions successives greffées sur le même squelette de commandes.
La conséquence concrète tient en un point technique souvent ignoré : l’adresse déclarée dans la commande MAIL FROM (l’enveloppe, dite 5321.From) et l’adresse affichée dans le champ From du message (l’en-tête, dite 5322.From) n’ont aucune obligation de correspondre. Un service de gestion de liste de diffusion, un outil de suivi de campagne ou un mécanisme de forwarding modifient légitimement l’une sans toucher l’autre. C’est précisément cet écart que SPF vérifie côté enveloppe. DKIM et DMARC s’attachent plutôt à l’en-tête visible par le destinataire, ce qui explique pourquoi les trois mécanismes se complètent sans faire doublon.
Le dialogue SMTP, commande par commande
Ouvrez une session en clair sur le port de soumission d’un serveur mail et le dialogue ressemble à un échange de politesses très strictement chorégraphié. Le serveur répond d’abord par un code 220, signe qu’il accepte la connexion. Le client envoie EHLO suivi de son propre nom de domaine, ce qui annonce sa capacité à parler la version étendue du protocole (ESMTP) et déclenche en retour la liste des extensions disponibles, SIZE pour la taille maximale du message ou AUTH pour l’authentification par exemple. Vient ensuite MAIL FROM, qui déclare l’expéditeur de l’enveloppe ; puis RCPT TO, répété autant de fois qu’il y a de destinataires. La commande DATA ouvre alors la fenêtre de transmission du contenu proprement dit, terminée par une ligne composée d’un seul point. Le client referme poliment avec QUIT.
Chaque étape renvoie un code numérique à trois chiffres qui vaut verdict. Un code commençant par 2 signifie succès (250 pour une commande acceptée). Un code en 3 invite à poursuivre, comme le 354 qui autorise le début du bloc DATA. Un code en 4 signale un échec temporaire, à retenter plus tard. Un code en 5 ferme définitivement la porte, sans retour possible sur ce message. Cette grille tient en quatre familles, pas plus. Elle n’a pas bougé depuis la première spécification du protocole, alors même que le volume d’emails échangés a été multiplié par plusieurs centaines depuis 1982.
Soumission puis transfert : le trajet en deux étapes
La soumission et le transfert répondent à des logiques opposées. La soumission passe par un MSA qui exige une authentification (identifiant et mot de passe ou jeton) avant d’accepter le moindre message : sans elle, n’importe qui pourrait usurper une adresse d’expédition. Le transfert entre MTA, lui, ne demande traditionnellement aucune authentification de ce type. Ce vide historique, SPF, DKIM et DMARC le comblent a posteriori, des décennies après l’écriture du protocole d’origine.
Trouver le serveur SMTP de sa messagerie
Le nom du serveur SMTP à renseigner dans un client mail dépend du fournisseur de messagerie utilisé et non d’un standard universel. Gmail, Outlook, OVH ou un hébergeur mutualisé publient chacun leurs propres adresses de serveur, avec des variantes selon qu’il s’agit d’une adresse professionnelle ou d’un compte grand public et parfois selon le pays de facturation du compte. Ce paramètre se trouve rarement au même endroit d’une interface à l’autre, ce qui pousse beaucoup d’utilisateurs à le chercher à chaque changement de logiciel de messagerie. Comment trouver le serveur SMTP de sa messagerie répertorie ces adresses fournisseur par fournisseur, avec la procédure pour les retrouver quand elles ne sont pas documentées.
Choisir le port SMTP
SMTP s’appuie historiquement sur quatre ports : 25 pour le transfert entre serveurs, 587 pour la soumission authentifiée, 465 pour une connexion chiffrée dès l’ouverture et 2525 comme alternative quand un fournisseur d’accès bloque les précédents. Le port 25 en particulier reste fermé par défaut sur la plupart des connexions résidentielles et sur de nombreux réseaux d’entreprise, pour limiter l’envoi de spam depuis des machines compromises à l’insu de leur propriétaire. Le choix du bon port dépend donc autant du logiciel utilisé que du réseau depuis lequel l’envoi part réellement. Comment déterminer le bon port SMTP détaille les cas d’usage de chacun selon le contexte d’envoi.
Passer par un relais SMTP
Un envoi géré depuis un serveur maison expose à un problème de réputation : une seule adresse mal configurée suffit à faire chuter la délivrabilité de tout le domaine. La plupart des entreprises confient donc l’envoi à un relais SMTP externe (Twilio SendGrid, Brevo, Amazon SES), qui mutualise une IP pool déjà chauffée et gère l’IP warmup à leur place. Le choix entre IP dédiée et IP mutualisée dépend surtout du volume envoyé chaque mois. Le fonctionnement d’un relais SMTP détaille ces compromis.
Authentification SMTP : AUTH, STARTTLS, SPF, DKIM, DMARC, BIMI
Le protocole d’origine ne prévoyait ni chiffrement ni vérification d’identité. La commande AUTH, ajoutée plus tard, impose des identifiants avant d’accepter une soumission. STARTTLS permet ensuite de basculer une connexion en clair vers une connexion chiffrée en cours de session, plutôt que d’ouvrir un canal chiffré dès le départ. Un choix de conception qui reste, encore aujourd’hui, opportuniste plutôt qu’obligatoire sur une bonne partie du parc de serveurs mondial. Au-dessus de cette couche de transport se superpose un triptyque devenu généralisé pour la délivrabilité. SPF vérifie que le serveur émetteur est autorisé à envoyer pour ce domaine. DKIM signe cryptographiquement le contenu et DMARC décide du sort d’un message qui échoue aux deux, jusqu’au DMARC reject qui rejette purement et simplement l’email non conforme. Le détail de SPF, DKIM, DMARC et BIMI explique comment ces couches s’articulent, BIMI ajoutant en bout de chaîne l’affichage d’un logo vérifié dans certains clients mail. Le Postmaster Tools de Gmail reste, à ce jour, l’outil le plus consulté pour observer l’effet réel de ces réglages sur la réputation d’un domaine.
Ce que SMTP ne fait pas
SMTP s’arrête à la remise du message sur le serveur du destinataire. Il ne consulte jamais une boîte de réception et ne stocke rien lui-même. La lecture, le tri, la synchronisation entre appareils relèvent d’IMAP et POP3, deux protocoles qui interviennent après que SMTP a terminé son travail.
Codes de réponse et échecs d’envoi
Un code 550 revenu sur une commande RCPT TO signale un hard bounce : l’adresse n’existe pas ou le serveur refuse définitivement le message. Un code 421 ou 450 correspond à un soft bounce, un échec temporaire (boîte pleine, serveur indisponible, limite de débit atteinte ou filtre temporaire actif) que le MTA expéditeur retentera automatiquement selon son propre calendrier de deferrals. Les versions récentes du protocole accompagnent souvent ce code d’un Enhanced Status Code à trois groupes de chiffres, 5.1.1 pour une adresse inexistante par exemple, qui précise la cause sans changer la nature du verdict. Un piège subsiste sur les domaines configurés en catchall : le serveur renvoie un 250 pour n’importe quelle adresse locale, y compris une boîte qui n’a jamais existé, ce qui rend ce code de succès trompeur pour qui veut juger de la validité réelle d’une adresse. La liste complète des codes de réponse SMTP et le détail des mécanismes de hard bounce et soft bounce aident à diagnostiquer précisément une campagne qui se dégrade. Une adresse invalide qui accumule les hard bounce abîme la sender reputation de l’IP expéditrice avant même qu’un souci d’authentification n’entre en jeu. Un contrôle de la liste avant l’envoi reste la seule façon de savoir où se situe réellement la casse.
Limites et évolutions du protocole
SMTP a été conçu pour du texte ASCII et des adresses en caractères latins, un choix qui excluait de fait les alphabets non latins des adresses email. L’extension SMTPUTF8 corrige ce point en autorisant des adresses en unicode mais son adoption reste marginale en dehors de quelques marchés asiatiques. Deux autres évolutions cherchent à sécuriser le transport entre serveurs, là où STARTTLS reste facultatif : MTA-STS (Mail Transfer Agent Strict Transport Security) impose le chiffrement via une politique publiée en DNS et HTTPS, tandis que DANE s’appuie directement sur DNSSEC pour authentifier le certificat du serveur destinataire. Moins d’1% des domaines du top 1 million publient une politique MTA-STS, un taux qui a plus que doublé entre 2024 et 2026 sans jamais franchir ce seuil (Uriports, 2026). Le paradoxe tient au poids des grands fournisseurs sur le trafic réel : aux Pays-Bas, une étude Zivver de septembre 2025 mesure que 19,1% du volume d’emails passe déjà par une connexion protégée MTA-STS, porté presque entièrement par Gmail et Hotmail. DANE reste une curiosité technique : son adoption dépend de DNSSEC, une brique que la majorité des hébergeurs n’ont toujours pas déployée en amont, ce qui bloque le mécanisme avant même qu’il ait une chance d’être configuré chez le client. Le protocole progresse par la marge, jamais par un remplacement d’ensemble.
