Comprendre le protocole SMTP : comment un email circule entre serveurs

SMTP est l’un des protocoles les plus importants de l’email.

Il intervient quand un message quitte une application, passe par un serveur sortant, puis rejoint le serveur du destinataire.

On le voit rarement directement, mais il explique beaucoup de problèmes concrets : emails bloqués, erreurs de relais, rejets 550, authentification absente, TLS mal négocié ou messages acceptés par un serveur mais jamais visibles en boîte de réception.

À quoi sert SMTP ?

SMTP signifie Simple Mail Transfer Protocol.

Son rôle est de transporter un email d’un serveur à un autre.

Il ne sert pas à lire les messages dans une boîte mail. Pour consulter les emails, on parle plutôt d’IMAP, POP ou d’une interface webmail.

SMTP répond à une autre question :

Comment un message est-il transmis depuis l’expéditeur jusqu’au serveur qui reçoit le domaine destinataire ?

Dans une chaîne email classique, SMTP intervient à plusieurs endroits :

• entre une application et son serveur d’envoi ;
• entre un serveur d’envoi et un serveur relais ;
• entre le serveur expéditeur et le serveur destinataire ;
• parfois entre plusieurs passerelles de sécurité avant la boîte finale.

Chaque étape peut accepter, refuser, filtrer ou retarder le message.

Le trajet d’un email

Quand vous envoyez un email, le message ne part pas directement dans la boîte du destinataire.

Il suit généralement plusieurs étapes.

1. Le client email, le CRM, le site web ou l’outil marketing soumet le message à un serveur SMTP.
2. Le serveur sortant vérifie si l’expéditeur a le droit d’envoyer.
3. Il cherche les enregistrements MX du domaine destinataire.
4. Il ouvre une connexion SMTP vers le serveur indiqué par ces MX.
5. Le serveur destinataire répond, vérifie le message, puis l’accepte ou le refuse.
6. Si le message est accepté, il peut encore passer par des filtres internes avant d’arriver en boîte de réception.

Ce dernier point est important : un message accepté en SMTP n’est pas forcément affiché en boîte principale.

Il peut être classé en spam, mis en quarantaine, redirigé, supprimé par une règle ou retenu par une passerelle de sécurité.

SMTP fonctionne comme une conversation

SMTP n’est pas magique. C’est une conversation structurée entre deux serveurs.

Un serveur se présente, annonce l’expéditeur, annonce le destinataire, transmet le contenu, puis attend une réponse.

Une conversation simplifiée ressemble à ceci :

EHLO mail.exemple.fr
MAIL FROM:<contact@exemple.fr>
RCPT TO:<client@destination.fr>
DATA
Subject: Test

Bonjour,
.
QUIT

À chaque étape, le serveur destinataire répond avec un code :

• 250 pour dire que l’étape est acceptée ;
• 421, 450 ou 451 pour signaler un problème temporaire ;
• 550, 553 ou 554 pour refuser le message ou une adresse.

C’est pour cela que les logs SMTP sont précieux. Ils montrent à quel moment la conversation échoue.

Les commandes SMTP les plus utiles à connaître

Il n’est pas nécessaire de mémoriser toute la norme SMTP pour diagnostiquer un problème.

Mais quelques commandes reviennent souvent :

Commande	Rôle
EHLO	Le serveur expéditeur se présente et annonce qu’il supporte les extensions SMTP modernes.
MAIL FROM	Définit l’expéditeur d’enveloppe, utilisé notamment par SPF et les bounces.
RCPT TO	Indique le destinataire que le serveur doit accepter ou refuser.
DATA	Lance la transmission du contenu du message.
STARTTLS	Demande à chiffrer la connexion avec TLS quand le serveur le permet.
AUTH	Authentifie un utilisateur ou une application sur un serveur de soumission.
QUIT	Termine proprement la session SMTP.

La différence entre l’expéditeur visible et l’expéditeur d’enveloppe mérite une attention particulière.

Le From visible par l’utilisateur n’est pas toujours le même que le MAIL FROM utilisé pendant la transaction SMTP.

Cette différence explique beaucoup de sujets SPF, DMARC, bounces et alignement.

Les ports SMTP : 25, 465 et 587

SMTP peut utiliser plusieurs ports selon le contexte.

Les plus courants :

• 25 : transport entre serveurs SMTP, notamment de MX à MX ;
• 587 : soumission authentifiée par un client, une application ou un outil d’envoi ;
• 465 : soumission SMTP avec TLS implicite dès l’ouverture de la connexion.

Dans une entreprise, le port 587 est souvent le plus propre pour une application qui doit envoyer via Microsoft 365, Google Workspace ou un relais SMTP authentifié.

Le port 25 reste central pour le transport entre serveurs, mais il est souvent bloqué ou filtré sur des connexions grand public pour limiter le spam.

TLS ne suffit pas à rendre un email fiable

TLS protège la connexion entre deux serveurs quand il est négocié correctement.

C’est important, mais ce n’est qu’une partie de la sécurité email.

Un message peut être transmis avec TLS et malgré tout :

• venir d’un domaine mal authentifié ;
• échouer SPF ;
• ne pas être signé en DKIM ;
• échouer DMARC ;
• être envoyé depuis une IP de mauvaise réputation ;
• contenir un lien ou une pièce jointe bloquée ;
• être refusé par la politique du destinataire.

SMTP transporte le message. Il ne garantit pas à lui seul que le message est légitime, attendu ou bien classé.

SMTP, SPF, DKIM et DMARC : qui fait quoi ?

SMTP transporte le message.

SPF, DKIM et DMARC aident les serveurs destinataires à décider si ce message est cohérent avec le domaine qui l’envoie.

En résumé :

• SMTP organise la transmission du message ;
• SPF vérifie si le serveur expéditeur est autorisé pour le domaine d’enveloppe ;
• DKIM vérifie une signature cryptographique ajoutée au message ;
• DMARC vérifie l’alignement avec le domaine visible et indique une politique.

Ces mécanismes ne remplacent pas SMTP. Ils s’ajoutent à la réception pour évaluer la confiance.

Quand un email est refusé, il faut donc distinguer le transport SMTP du verdict de sécurité.

Pourquoi un serveur SMTP refuse un message

Un refus SMTP peut venir de nombreuses causes.

Les plus fréquentes :

• adresse destinataire inexistante ;
• boîte pleine ou désactivée ;
• domaine destinataire mal configuré ;
• serveur temporairement indisponible ;
• expéditeur non authentifié ;
• relais interdit ;
• SPF, DKIM ou DMARC en échec ;
• IP ou domaine avec mauvaise réputation ;
• contenu jugé suspect ;
• volume trop élevé vers un même fournisseur.

Le code d’erreur indique la famille du problème.

Un 550 5.1.1 pointe souvent vers une adresse invalide. Un 550 5.7.1 ou 554 pointe plutôt vers une règle de sécurité, de réputation ou de politique antispam.

Ce que SMTP ne fait pas

SMTP est essentiel, mais il ne fait pas tout.

Il ne choisit pas à lui seul si un message arrive en boîte principale, en spam ou en quarantaine.

Il ne prouve pas non plus que l’expéditeur visible est légitime.

Il ne maintient pas une base de contacts propre.

Il ne compense pas une mauvaise réputation.

Il ne corrige pas une configuration DNS incohérente.

Le protocole transporte. Les fournisseurs de messagerie évaluent ensuite beaucoup d’autres signaux.

Comment diagnostiquer un problème SMTP

La méthode utile consiste à partir des faits visibles.

À vérifier en priorité :

1. le message d’erreur complet ;
2. le code SMTP principal et le sous-code ;
3. le domaine destinataire touché ;
4. le serveur ou l’outil qui envoie ;
5. le MAIL FROM et le From visible ;
6. les enregistrements MX, SPF, DKIM et DMARC ;
7. la présence ou non de TLS ;
8. la réputation de l’IP et du domaine ;
9. le volume envoyé juste avant l’erreur ;
10. les logs du relais SMTP ou de la plateforme d’envoi.

L’objectif n’est pas de tout modifier.

L’objectif est de comprendre où la conversation SMTP échoue : connexion, authentification, destinataire, contenu, politique ou réputation.

Conclusion

SMTP est la colonne de transport de l’email.

Il permet à un message de passer d’un serveur à un autre, avec une conversation claire : présentation, expéditeur, destinataire, contenu, réponse.

Comprendre SMTP aide à lire les erreurs, distinguer un problème temporaire d’un refus définitif, et éviter les corrections au hasard.

Pour une messagerie fiable, SMTP doit ensuite être accompagné d’une configuration propre : DNS cohérent, SPF, DKIM, DMARC, TLS, authentification, suivi des erreurs et réputation maîtrisée.