Vous cliquez sur « Envoyer ». Une seconde plus tard, le message est parti. Entre les deux, votre machine a ouvert une connexion réseau, s’est présentée à un serveur, a négocié un chiffrement, s’est authentifiée, a annoncé un expéditeur, puis un destinataire, et n’a transmis le message qu’une fois chaque étape acceptée. Tout cela suit un protocole vieux de plus de quarante ans : le protocole SMTP.
Comprendre ce dialogue n’est pas un exercice d’érudition. C’est ce qui permet de lire un message d’erreur au lieu de le subir, de savoir si un rejet vient de votre configuration ou du serveur d’en face, et de comprendre pourquoi un e-mail parfaitement rédigé peut malgré tout finir en spam.
Qu’est-ce que le protocole SMTP ?
SMTP signifie Simple Mail Transfer Protocol. C’est le protocole standard qui régit l’acheminement des e-mails sur Internet : la manière dont un logiciel de messagerie remet un message à un serveur, et dont les serveurs se le transmettent entre eux jusqu’à destination.
Sa première version date de 1982 (RFC 821). La version en vigueur aujourd’hui est décrite par la RFC 5321, publiée en 2008. Entre les deux, le protocole a été étendu, on parle d’ESMTP, pour Extended SMTP, pour accueillir l’authentification, le chiffrement, les pièces jointes volumineuses et l’annonce des capacités du serveur.
Le point essentiel, et celui que la plupart des explications escamotent : SMTP ne sert qu’à envoyer. Il ne sait pas relever une boîte, ni afficher un message, ni le classer. Cette asymétrie explique à elle seule la moitié des confusions sur le sujet.
SMTP, IMAP et POP3 : qui fait quoi
Trois protocoles cohabitent dans un client de messagerie, et ils ne font pas le même travail. SMTP pousse le courrier vers l’extérieur ; IMAP et POP3 le récupèrent.
| Protocole | Rôle | Sens | Ports usuels |
|---|---|---|---|
| SMTP | Envoi et transfert entre serveurs | Sortant | 25, 465, 587 |
| IMAP | Consultation, les messages restent sur le serveur | Entrant | 143, 993 |
| POP3 | Téléchargement, souvent avec suppression | Entrant | 110, 995 |
La différence pratique entre IMAP et POP3 tient en une phrase : avec IMAP, votre boîte vit sur le serveur et tous vos appareils voient le même état ; avec POP3, chaque appareil rapatrie les messages chez lui. Mais dans les deux cas, l’envoi passe par SMTP. C’est pourquoi un compte peut très bien recevoir sans problème et refuser d’envoyer : ce sont deux configurations distinctes, sur deux serveurs qui peuvent être différents.
Les acteurs d’une transmission : MUA, MTA, MDA
Un e-mail traverse trois types de logiciels, et le vocabulaire revient dans tous les journaux de serveur.
- Le MUA (Mail User Agent) est votre client : Outlook, Thunderbird, l’application Mail de votre téléphone, ou le script qui envoie les notifications de votre site.
- Le MTA (Mail Transfer Agent) est le serveur qui achemine : Postfix, Exim, Sendmail, ou l’infrastructure de votre prestataire. C’est lui qui parle SMTP, aussi bien avec votre MUA qu’avec les autres MTA.
- Le MDA (Mail Delivery Agent) dépose le message dans la boîte du destinataire, une fois le MTA de destination atteint.
Une nuance utile : le premier serveur que contacte votre client s’appelle en réalité un MSA (Mail Submission Agent). Il écoute sur le port 587, exige une authentification, et a le droit de corriger votre message, ajouter un en-tête Date manquant, par exemple. Un MTA classique sur le port 25, lui, relaie sans rien réécrire. Cette séparation entre soumission et relais est ce qui a rendu la lutte anti-spam possible.
Le dialogue SMTP, commande par commande
SMTP est un protocole en texte clair, ligne par ligne. On peut donc l’observer directement. Voici une session réelle vers un serveur de soumission, ouverte avec OpenSSL :
openssl s_client -starttls smtp -crlf -connect smtp.exemple.fr:587Une fois la couche TLS établie, le dialogue se déroule ainsi. Les lignes préfixées de > sont ce que vous envoyez ; les autres sont les réponses du serveur.
220 smtp.exemple.fr ESMTP Postfix
> EHLO client.exemple.fr
250-smtp.exemple.fr
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-AUTH PLAIN LOGIN
250 8BITMIME
> AUTH LOGIN
334 VXNlcm5hbWU6
> dXRpbGlzYXRldXJAZXhlbXBsZS5mcg==
334 UGFzc3dvcmQ6
> bW90ZGVwYXNzZQ==
235 2.7.0 Authentication successful
> MAIL FROM:<expediteur@exemple.fr>
250 2.1.0 Ok
> RCPT TO:<destinataire@autre-domaine.fr>
250 2.1.5 Ok
> DATA
354 End data with <CR><LF>.<CR><LF>
> From: Expediteur <expediteur@exemple.fr>
> To: Destinataire <destinataire@autre-domaine.fr>
> Subject: Test
>
> Corps du message.
> .
250 2.0.0 Ok: queued as 4XyZ12
> QUIT
221 2.0.0 ByeSept commandes suffisent à comprendre l’essentiel :
EHLO, votre client se présente et demande la liste des capacités. Le serveur répond par tout ce qu’il sait faire. C’est là qu’on voit siSTARTTLSetAUTHsont disponibles.AUTH, l’authentification. EnLOGIN, identifiant et mot de passe sont encodés en base64, ce qui n’est pas un chiffrement : sans TLS, ils circulent en clair.MAIL FROM, l’expéditeur d’enveloppe. Retenez cette ligne, on y revient plus bas.RCPT TO, un destinataire. On répète la commande autant de fois qu’il y a de destinataires, et chacun peut être accepté ou refusé séparément.DATA, annonce le contenu. Le serveur répond354et attend. Le message se termine par une ligne ne contenant qu’un point.QUIT, clôt proprement la session.
Ce que cette transcription rend visible : le message n’est transmis qu’en dernier. Tout ce qui précède est une négociation, et un rejet peut survenir à n’importe laquelle de ces étapes. Savoir à quelle commande ça a échoué réduit le diagnostic de moitié.
Les codes de réponse SMTP et ce qu’il faut en faire
Chaque réponse commence par trois chiffres. Le premier donne la nature de la réponse, et c’est le seul qu’il faut mémoriser.
- 2xx, accepté, on continue.
- 3xx, le serveur attend la suite.
- 4xx, échec temporaire. Le message reste en file d’attente et sera réessayé.
- 5xx, échec définitif. Le message est abandonné, un rapport de non-remise part vers l’expéditeur.
La distinction 4xx / 5xx est la plus importante du protocole. Un 4xx ne demande aucune action dans l’immédiat ; un 5xx exige une correction, sans quoi tous les envois suivants échoueront de la même façon.
| Code | Signification | Que faire |
|---|---|---|
| 250 | Commande acceptée | Rien, tout va bien |
| 354 | Le serveur attend le corps du message | Envoyer le contenu, terminer par une ligne avec un point seul |
| 421 | Service indisponible, fermeture de la connexion | Serveur saturé ou limitation de débit. Réduire la cadence d’envoi |
| 450 | Boîte temporairement inaccessible | Souvent du greylisting. Le réessai automatique suffit |
| 451 | Erreur locale du serveur | Ne vient pas de vous. Si ça persiste, contacter le destinataire par un autre canal |
| 452 | Espace de stockage insuffisant | Boîte pleine, ou trop de destinataires d’un coup. Fractionner l’envoi |
| 550 | Boîte inexistante, ou message rejeté | Le plus fréquent. Vérifier l’adresse, puis votre authentification SPF/DKIM |
| 552 | Message trop volumineux | Comparer au SIZE annoncé par le serveur dans sa réponse à EHLO |
| 554 | Transaction refusée | Souvent un blocage pour réputation. Vérifier si votre IP est en liste noire |
Un piège classique : un 550 ne signifie pas toujours « adresse inconnue ». Beaucoup de serveurs l’utilisent aussi pour dire « je ne vous fais pas confiance », sans le formuler. Le texte qui suit le code est alors la seule information exploitable, il faut le lire, jamais le tronquer.
Les ports SMTP : 25, 465, 587 et 2525
Quatre ports circulent dans les documentations, et ils ne sont pas interchangeables.
| Port | Usage | Chiffrement |
|---|---|---|
| 25 | Relais entre serveurs (MTA vers MTA) | STARTTLS opportuniste |
| 587 | Soumission depuis un client, le choix par défaut | STARTTLS, authentification obligatoire |
| 465 | Soumission avec TLS implicite | TLS dès la connexion |
| 2525 | Alternative non normalisée | Selon le prestataire |
Le port 25 est massivement bloqué en sortie par les fournisseurs d’accès, précisément parce qu’il a longtemps servi à relayer du spam depuis des machines infectées. Si vous configurez un client ou un script, le port 587 est la réponse dans la quasi-totalité des cas. Le 2525 n’existe dans aucune norme : c’est une porte de secours proposée par certains prestataires quand les autres sont fermées. Le détail de chaque port, les cas de blocage et les commandes pour tester une connexion sont traités dans notre page dédiée aux ports SMTP.
SMTP-AUTH, STARTTLS et SMTPS : deux problèmes distincts
La confusion la plus répandue consiste à mélanger chiffrer le transport et prouver qui envoie. Ce sont deux mécanismes indépendants.
STARTTLS (RFC 3207) part d’une connexion en clair et la bascule en chiffré à la demande. C’est ce qu’utilisent les ports 25 et 587. Son défaut : la bascule est facultative, donc théoriquement interceptable.
SMTPS désigne le TLS implicite du port 465 : la connexion est chiffrée dès son ouverture, sans négociation préalable. Longtemps déclaré obsolète, il a été réhabilité par la RFC 8314.
SMTP-AUTH est la commande AUTH vue plus haut. Elle prouve au serveur que vous avez le droit d’utiliser son service, rien de plus. Elle ne dit rien au destinataire sur votre identité.
Autrement dit : le chiffrement protège le message pendant le trajet, l’authentification vous ouvre la porte du serveur sortant. Ni l’un ni l’autre ne garantit au serveur d’en face que vous êtes bien qui vous prétendez être.
Pourquoi SMTP ne prouve pas qui vous êtes
Reprenez la transcription plus haut. Deux expéditeurs y figurent, et ils sont indépendants :
- l’expéditeur d’enveloppe, déclaré par
MAIL FROM, qui sert au routage et aux rapports d’erreur ; - l’en-tête
From:, à l’intérieur du blocDATA, qui est le seul que votre destinataire verra.
Rien dans le protocole n’oblige ces deux valeurs à correspondre, et rien ne vérifie que vous avez le droit d’utiliser l’une ou l’autre. Ce n’est pas une faille : SMTP a été conçu en 1982 pour un réseau de quelques centaines de machines qui se faisaient mutuellement confiance. La vérification d’identité n’était pas un besoin.
Toute la couche d’authentification moderne a été ajoutée par-dessus, pour combler exactement ce vide :
- SPF déclare, dans le DNS de votre domaine, quels serveurs ont le droit d’envoyer pour vous. Il vérifie l’expéditeur d’enveloppe.
- DKIM appose une signature cryptographique sur le message, que le destinataire vérifie avec une clé publique publiée dans votre DNS.
- DMARC exige que l’en-tête
From:visible soit aligné avec ce que SPF ou DKIM ont validé, et indique quoi faire en cas d’échec.
C’est pour cette raison qu’un message techniquement irréprochable peut être rejeté ou classé en indésirable : le protocole l’a transmis correctement, mais rien ne prouvait qu’il venait de vous. Si vous n’avez pas encore configuré cette couche, c’est le chantier prioritaire : notre guide SPF, DKIM et DMARC détaille les trois enregistrements, et la création d’un enregistrement DMARC se fait pas à pas.
Serveur SMTP ou relais : quand faut-il vraiment changer
Toutes les pages qui expliquent SMTP finissent par vous vendre un relais. Soyons honnêtes sur le moment où il devient utile, et sur celui où il ne l’est pas.
Le serveur SMTP de votre hébergeur suffit largement pour du courrier professionnel courant, les notifications d’un site vitrine ou les formulaires de contact. Tant que le volume reste modeste et que votre authentification est correctement configurée, ajouter un intermédiaire ne change rien à la délivrabilité.
Un relais dédié se justifie à partir du moment où l’un de ces points devient vrai : vous envoyez plusieurs milliers de messages par mois et les quotas de l’hébergeur deviennent contraignants ; vous avez besoin de statistiques de remise et de gestion automatique des adresses invalides ; votre IP est partagée avec d’autres clients dont la réputation vous pénalise ; ou vous devez séparer le transactionnel du marketing sur des IP distinctes.
En dessous de ce seuil, le vrai levier n’est pas le prestataire, c’est votre réputation d’expéditeur et la qualité de votre liste. Changer de serveur ne répare pas une base d’adresses mal entretenue. Le sujet est traité en détail dans notre guide de la délivrabilité.
Côté développement, si vous envoyez depuis une application, le protocole se manipule rarement à la main : une bibliothèque s’en charge. Notre documentation anglophone donne un exemple d’envoi SMTP authentifié en PHP qui reprend exactement les étapes décrites plus haut.
Questions fréquentes
Que signifie SMTP ?
Simple Mail Transfer Protocol, soit « protocole simple de transfert de courrier ». Il est normalisé par la RFC 5321.
Comment trouver l’adresse de mon serveur SMTP ?
Elle est fournie par votre hébergeur ou votre fournisseur de messagerie, généralement sous la forme smtp.votredomaine.fr ou smtp.nomduprestataire.com. On la retrouve dans les paramètres du compte, à côté du port et du mode de chiffrement.
Le SMTP est-il gratuit ?
Le protocole est un standard ouvert, donc oui. Ce qui est payant, c’est le service : un serveur qui accepte vos envois, maintient sa réputation et garantit un volume. La plupart des hébergements web incluent un accès SMTP dans leur offre.
Quelle différence entre SMTP et SMTPS ?
SMTPS n’est pas un protocole distinct : c’est SMTP encapsulé dans une couche TLS dès l’ouverture de la connexion, sur le port 465. Sur le port 587, on obtient le même niveau de sécurité via STARTTLS, en deux temps.
Pourquoi mes e-mails partent-ils mais n’arrivent-ils pas ?
Parce que l’acceptation par votre serveur sortant (code 250) ne préjuge en rien de la décision du serveur destinataire. Entre les deux interviennent l’authentification de votre domaine, la réputation de l’IP d’envoi et le filtrage de contenu. C’est le sujet du chapitre sur l’authentification plus haut.
Sur le même sujet : configurer un compte IMAP et SMTP
