← RFC Reference

Comment SMTP Fonctionne Réellement

Une explication complète d'une transaction SMTP — de la recherche DNS à la livraison finale. Si vous envoyez des e-mails par programmation, c'est le modèle mental dont vous avez besoin.

Vue d'ensemble

SMTP — le Simple Mail Transfer Protocol — est le protocole qui achemine les e-mails sur Internet. Défini dans RFC 5321, il est la base de la messagerie depuis 1982 (la RFC 821 originale). Malgré des décennies d'extensions, la transaction de base est toujours une courte conversation textuelle synchrone entre deux serveurs sur le port TCP 25.

Chaque livraison d'e-mail suit la même séquence :

1. Recherche DNS — trouver le serveur de messagerie du destinataire
2. Connexion TCP — se connecter au port 25 (ou 465/587 pour la soumission)
3. Bannière et EHLO — échanger les identités et les capacités
4. STARTTLS — passer à une connexion chiffrée (généralement)
5. AUTH — s'authentifier si vous soumettez (port 587)
6. Enveloppe — MAIL FROM et RCPT TO
7. DATA — transmettre les en-têtes et le corps du message
8. QUIT — fermer la connexion

Étape 1 : DNS — Trouver le serveur de messagerie

Avant toute conversation SMTP, le serveur expéditeur doit découvrir où livrer le message. Il interroge le DNS pour les enregistrements MX du domaine du destinataire.

Le nombre est la priorité (plus bas = préféré). L'expéditeur essaie d'abord mx1.example.com. S'il est inaccessible ou retourne une erreur temporaire, l'expéditeur bascule vers mx2.example.com.

S'il n'existe pas d'enregistrements MX, l'expéditeur bascule vers l'enregistrement A ou AAAA du domaine — mais c'est un dernier recours. S'il existe un enregistrement Null MX explicite (0 .), le domaine n'accepte pas de mail du tout. Voir DNS et routage de messagerie pour l'algorithme complet.

Étape 2 : Connexion TCP et bannière

L'expéditeur ouvre une connexion TCP au port 25 de l'hôte MX. Le serveur récepteur parle en premier avec une bannière 220 :

Le code de statut 220 signifie « service prêt ». Si le serveur est surchargé, il peut répondre avec 421 (service indisponible) et fermer la connexion. L'expéditeur devrait réessayer plus tard.

Pour la soumission de messages (un client de messagerie d'utilisateur envoyant via son fournisseur), la connexion se fait au port 587 (RFC 6409) ou au port 465 (TLS implicite, RFC 8314) au lieu du port 25.

Étape 3 : EHLO — Annoncer les capacités

L'expéditeur se présente avec EHLO (Extended HELO), en fournissant son propre nom d'hôte. Le serveur répond avec ses extensions supportées :

Chaque ligne 250- annonce une extension. La dernière ligne utilise 250 (espace, pas tiret) pour signaler la fin. Extensions clés :

• SIZE — taille maximale du message en octets
• STARTTLS — le serveur supporte la mise à niveau vers TLS (RFC 3207)
• AUTH — mécanismes d'authentification supportés (RFC 4954)
• PIPELINING — l'expéditeur peut regrouper les commandes sans attendre (RFC 2920)
• ENHANCEDSTATUSCODES — codes de statut étendus comme 5.1.1 (RFC 3463)
• 8BITMIME — le transfert de contenu 8 bits est supporté
• SMTPUTF8 — adresses e-mail internationalisées (RFC 6531)

La commande héritée HELO (sans le « E ») ignore complètement les extensions. Elle n'est presque jamais utilisée en pratique aujourd'hui.

Étape 4 : STARTTLS — Passer au chiffrement

Si le serveur a annoncé STARTTLS, l'expéditeur émet la commande pour mettre à niveau la connexion :

Après STARTTLS, l'expéditeur doit envoyer EHLO à nouveau. Le serveur peut annoncer différentes extensions sur la connexion chiffrée (par exemple, AUTH n'est généralement annoncé qu'après l'établissement de TLS).

Sur le port 465, TLS est implicite — la connexion est chiffrée dès le premier octet, et aucune étape STARTTLS n'est nécessaire.

Sans TLS, toute la conversation SMTP — y compris les mots de passe et le contenu du message — est envoyée en texte clair. La meilleure pratique moderne est toujours d'utiliser TLS. Voir MTA-STS et DANE pour les mécanismes qui l'imposent.

Étape 5 : AUTH — Authentification (soumission uniquement)

Quand un client de messagerie soumet un message via le port 587, il s'authentifie en utilisant SMTP AUTH (RFC 4954) :

La chaîne Base64 encode \0username\0password. C'est pourquoi TLS est critique — sans lui, les identifiants voyagent en clair.

La livraison serveur-à-serveur sur le port 25 n'utilise pas AUTH. Au lieu de cela, le serveur récepteur s'appuie sur l'adresse IP de l'expéditeur, les enregistrements SPF, les signatures DKIM et autres mécanismes d'authentification pour vérifier le message. Voir Authentification des e-mails expliquée.

Étape 6 : L'enveloppe — MAIL FROM et RCPT TO

L'enveloppe est séparée des en-têtes du message. Elle indique au serveur récepteur qui envoie le message et qui devrait le recevoir :

Détails clés :

• MAIL FROM spécifie le chemin de retour (également appelé l'expéditeur d'enveloppe ou adresse de rebond). C'est où vont les DSN (messages de rebond). Il peut différer de l'en-tête From:.
• RCPT TO spécifie chaque destinataire. Vous pouvez avoir plusieurs commandes RCPT TO pour un message.
• Le paramètre optionnel SIZE= permet au serveur de rejeter les messages surdimensionnés au préalable.
• Un MAIL FROM:<> (chemin de retour vide) est utilisé pour les messages de rebond eux-mêmes, pour éviter les boucles infinies de rebonds.

Chaque commande reçoit une réponse individuelle. Un 250 signifie accepté. Un 550 sur RCPT TO signifie que la boîte aux lettres n'existe pas. Un 452 signifie que le serveur est temporairement incapable d'accepter ce destinataire. L'expéditeur doit gérer chaque réponse individuellement — certains destinataires peuvent être acceptés tandis que d'autres sont rejetés.

Étape 7 : DATA — Envoyer le message

La commande DATA commence la transmission du message :

Le message inclut à la fois les en-têtes et le corps, séparés par une ligne vide. Le message se termine par une ligne contenant uniquement un point unique (.) — la convention « dot-stuffing ». Toute ligne dans le corps du message qui commence par un point a un point supplémentaire ajouté lors de la transmission et supprimé à la réception.

La réponse 250 après DATA signifie que le message a été accepté pour livraison. Il ne signifie pas que le message a été livré à la boîte aux lettres du destinataire. Le serveur récepteur peut encore le rejeter lors du filtrage du contenu, ou générer un rebond plus tard.

L'ID de file d'attente (par exemple, 4F3A21C8) est inestimable pour le débogage. Enregistrez-le.

Étape 8 : QUIT

L'expéditeur ferme la session. La connexion TCP est fermée. Si l'expéditeur a d'autres messages pour le même serveur, il peut émettre un autre MAIL FROM au lieu de QUIT pour réutiliser la connexion.

Codes de réponse SMTP

Chaque réponse SMTP commence par un code à trois chiffres. Le premier chiffre vous indique la catégorie :

Codes courants que vous rencontrerez :

• 220 — Service prêt (bannière)
• 250 — Action demandée terminée
• 354 — Commencer l'entrée du message
• 421 — Service indisponible, fermeture de la connexion (réessayer plus tard)
• 450 — Boîte aux lettres temporairement indisponible (greylisting, limitation de débit)
• 451 — Action demandée abandonnée en raison d'une erreur locale
• 452 — Stockage insuffisant
• 550 — Boîte aux lettres introuvable / action non effectuée
• 551 — Utilisateur non local ; veuillez essayer une adresse de transfert
• 552 — Taille du message dépasse la limite
• 553 — Nom de boîte aux lettres non autorisé
• 554 — Transaction échouée (souvent utilisée pour le rejet de politique)

Avec ENHANCEDSTATUSCODES, le serveur ajoute un code plus spécifique comme 5.1.1 (mauvaise boîte aux lettres de destination). Voir Comprendre les rebonds de messagerie pour une ventilation complète.

Une transaction complète

Voici une session SMTP entière de la connexion à la fermeture, annotée :

Soumission vs. relais

SMTP remplit deux rôles distincts :

• Soumission (port 587 ou 465) : Un client de messagerie envoie un nouveau message à son serveur de messagerie. L'authentification est requise. Le serveur prend la responsabilité de le livrer.
• Relais (port 25) : Un serveur de messagerie livre un message à un autre. Pas d'authentification — l'autorisation provient du DNS (enregistrements MX) et de la vérification de l'expéditeur (SPF, DKIM).

Un relais ouvert — un serveur qui accepte les e-mails de n'importe qui à n'importe qui — est le péché cardinal de la configuration des e-mails. Les spammeurs exploitent les relais ouverts immédiatement. Chaque serveur de messagerie moderne doit restreindre le relais aux utilisateurs authentifiés ou aux expéditeurs connus.

Qu'est-ce qui peut mal tourner

Connexion refusée ou expirée

L'hôte MX est en panne ou pare-feu. La file d'attente de l'expéditeur réessaie avec backoff exponentiel, en basculant entre les enregistrements MX de priorité inférieure. Après la période de réessai (généralement 4-5 jours), le message rebondit.

Greylisting

Le serveur récepteur retourne 450 pour la première tentative d'un expéditeur inconnu. Les serveurs légitimes réessaient ; les spammeurs ne le font généralement pas. Votre message sera retardé de quelques minutes mais finira par arriver.

Rejeté à RCPT TO

Une réponse 550 5.1.1 User unknown signifie que la boîte aux lettres n'existe pas. C'est un rebond dur. Supprimez l'adresse de votre liste immédiatement.

Rejeté à DATA

Le serveur peut accepter l'enveloppe mais rejeter le contenu. Raisons courantes : message trop volumineux, contenu signalé comme spam, ou vérifications d'authentification échouées (SPF/DKIM/DMARC). La réponse vient après le point final.

Accepté puis rejeté

Le serveur retourne 250 pour DATA mais génère ensuite un DSN (message de rebond) parce que la boîte aux lettres était pleine, le filtrage du contenu l'a rejeté, ou une erreur interne s'est produite. C'est le cas le plus difficile à gérer — vous ne le découvrez que via le message de rebond envoyé à l'adresse MAIL FROM.

Défaillances TLS

Si la négociation STARTTLS échoue, la plupart des serveurs reviennent au texte brut. C'est un risque de sécurité — un attaquant actif peut supprimer TLS. MTA-STS et DANE évitent cette rétrogradation.

Points clés

• SMTP est un protocole synchrone basé sur du texte. Chaque commande reçoit un code de réponse.
• L'enveloppe (MAIL FROM / RCPT TO) est séparée des en-têtes du message (From: / To:). Ils peuvent différer.
• Un 250 après DATA signifie « accepté pour livraison », pas « livré à la boîte de réception ».
• Les erreurs 4xx sont temporaires — réessayez. Les erreurs 5xx sont permanentes — ne réessayez pas.
• Toujours utiliser TLS. L'imposer avec MTA-STS ou DANE.
• Enregistrez les ID de file d'attente des réponses du serveur pour le débogage.

Lectures complémentaires

Related RFCs