MTA : le serveur qui transporte le courrier d'un domaine à l'autre

Un MTA (Mail Transfer Agent) est le logiciel serveur qui reçoit un message en SMTP et le transmet au serveur suivant jusqu'à la boîte aux lettres du destinataire. C'est la pièce centrale de toute infrastructure d'envoi : c'est lui qui parle aux routeurs, qui subit leurs limitations et qui produit les journaux permettant de comprendre ce qui se passe.

Ce qu'est un MTA, et ce qu'il n'est pas#

La chaîne de traitement d'un email fait intervenir trois familles de logiciels :

• le MUA (Mail User Agent) est le client de messagerie : Thunderbird, Outlook, l'interface web d'un fournisseur, ou l'application qui génère des emails transactionnels ;
• le MTA (Mail Transfer Agent) accepte le message en SMTP, décide de la route à suivre, le place en file d'attente et le livre au MTA du domaine destinataire ;
• le MDA (Mail Delivery Agent) dépose le message dans la boîte aux lettres finale, où le MUA viendra le lire en IMAP ou POP.

Un MTA est donc un relais. Il peut relayer en sortie (le serveur d'envoi d'une entreprise ou d'un fournisseur d'emailing) ou en entrée (le serveur désigné par l'enregistrement MX d'un domaine). Un même logiciel assure souvent les deux rôles.

Comment un MTA achemine un message#

Pour chaque destinataire, le MTA sortant procède en quatre étapes :

1. Il extrait le domaine de l'adresse (exemple.fr dans marie@exemple.fr).
2. Il interroge le DNS pour obtenir les enregistrements MX de ce domaine, triés par priorité.
3. Il ouvre une connexion TCP sur le port 25 vers le MX de priorité la plus basse, négocie STARTTLS si le serveur le propose, puis envoie EHLO, MAIL FROM, RCPT TO et DATA.
4. Il interprète la réponse : un code 250 signifie que le message est accepté, un code 4xx qu'il faut réessayer plus tard, un code 5xx que le message est définitivement refusé.

Exemple de dialogue abrégé :

S: 220 mx1.exemple.fr ESMTP
C: EHLO smtp-out.expediteur.com
S: 250-mx1.exemple.fr
S: 250-STARTTLS
S: 250 SIZE 52428800
C: MAIL FROM:<newsletter@expediteur.com>
S: 250 2.1.0 Ok
C: RCPT TO:<marie@exemple.fr>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
S: 250 2.0.0 Ok: queued as 4F3A2B1C

En cas de refus temporaire (421, 450, 451), le MTA conserve le message en file d'attente et réessaie selon un calendrier croissant, en général pendant deux à cinq jours avant de renvoyer un message de non-remise (bounce) à l'expéditeur.

Logiciels courants#

Les MTA les plus répandus sont Postfix, Exim et Sendmail en logiciel libre, Microsoft Exchange en entreprise, et des produits commerciaux orientés gros volumes comme PowerMTA, KumoMTA, Halon ou MailerQ. Les fournisseurs d'emailing exploitent presque toujours leur propre parc de MTA, invisible pour leurs clients, mais c'est bien le nom d'hôte de ces machines qui apparaît dans les en-têtes Received du message final.

Du côté réception, les grands fournisseurs de boîtes aux lettres (Google, Microsoft, Yahoo, Orange, Free…) exploitent des MTA entrants capables d'absorber des millions de connexions par heure et qui appliquent, au moment même de la session SMTP, leurs règles de réputation.

Ce qu'un MTA sortant doit respecter#

Un MTA bien configuré présente aux routeurs une identité cohérente :

• Le nom annoncé dans EHLO est un nom d'hôte pleinement qualifié qui existe réellement dans le DNS.
• L'adresse IP d'envoi dispose d'un enregistrement PTR, et ce PTR résout en retour vers la même adresse (voir la page sur les MX et le reverse DNS).
• Le MTA présente un certificat TLS valide et accepte STARTTLS en entrée comme en sortie.
• Les messages sont signés DKIM avant de quitter le serveur, et l'adresse MAIL FROM appartient à un domaine couvert par SPF.
• Le MTA respecte les limites de connexions simultanées et de messages par connexion propres à chaque routeur, et ralentit de lui-même lorsqu'il reçoit des codes 4xx.

Les exigences publiées en 2024 par Google et Yahoo pour les expéditeurs en volume rendent plusieurs de ces points obligatoires : reverse DNS valide, TLS, authentification SPF ou DKIM, et un taux de plaintes maintenu sous 0,3 %.

Ce qu'il faut surveiller dans les journaux#

Les journaux (logs) du MTA sont la source la plus fiable pour diagnostiquer un problème de délivrabilité. Chaque tentative de livraison y laisse une ligne avec le destinataire, le MX contacté, le code de réponse et son texte. Une ligne Postfix typique :

Oct  1 09:14:22 smtp-out postfix/smtp[18233]: 4F3A2B1C: to=<marie@exemple.fr>,
  relay=mx1.exemple.fr[203.0.113.10]:25, delay=0.42, status=sent (250 2.0.0 Ok)

Les indicateurs à suivre en continu :

• la part de réponses 4xx et 5xx par routeur destinataire ;
• les textes de refus, qui contiennent souvent un code d'erreur propre au routeur et une adresse de documentation ;
• la taille de la file d'attente et l'âge du message le plus ancien ;
• le temps de livraison moyen par destination, dont la dégradation annonce souvent un ralentissement imposé par le routeur.

Erreurs fréquentes#

• Annoncer dans EHLO un nom générique (localhost, mail, le nom interne de la machine) qui ne correspond à aucune entrée DNS.
• Laisser le MTA relayer sans authentification pour tout le réseau local, ce qui en fait un relais ouvert exploité en quelques heures.
• Ignorer les codes 4xx et continuer à envoyer au même rythme, ce qui transforme un ralentissement temporaire en blocage.
• Ne pas traiter les bounces : les adresses invalides restent dans les listes et le taux d'erreurs grimpe à chaque campagne.
• Ne pas conserver les journaux assez longtemps pour reconstituer l'historique d'un incident.

Pour aller plus loin#

L'analyse des journaux d'un parc de MTA, destination par destination et code de réponse par code de réponse, demande un outillage dédié dès que le volume dépasse quelques milliers de messages par jour. Postmastery propose une approche de surveillance des logs MTA et de la réputation d'un domaine qui prolonge ce guide côté exploitation.