Serveurs d'envoi d'e-mails : un guide pour une meilleure délivrabilité

Vous envoyez une campagne importante. Il peut s’agir d’une mise à jour de produit, d’un suivi de recrutement, d’une annonce pour des donateurs ou d’une séquence commerciale. Vous cliquez sur envoyer, vous regardez la barre de progression se terminer, puis l’incertitude s’installe.

Les e-mails sont-ils arrivés ? Ont-ils atterri dans la boîte de réception, ou ont-ils été poussés dans les spams, retardés ou rejetés avant que quiconque ne les voie ?

Cette anxiété est généralement attribuée au contenu, aux objets des e-mails ou à la qualité de la liste. Ces éléments comptent. Mais il existe un autre élément travaillant en coulisses auquel de nombreux utilisateurs professionnels ne pensent jamais jusqu’à ce qu’un problème survienne : le serveur d’envoi d’e-mails.

Si vous utilisez Gmail, Outlook, Apple Mail, un CRM, un formulaire de site web ou un outil de publipostage, vos messages ont toujours besoin d’un système qui prend votre e-mail, le vérifie, l’achemine et le transmet au fournisseur de messagerie du destinataire. Si cette configuration est incorrecte, même un e-mail parfaitement rédigé peut disparaître.

Une remarque avant de rechercher des outils dans ce domaine. Mail Merge for Gmail est un nom de produit très descriptif, il est donc facile de le confondre avec d’autres outils de publipostage pour Gmail. Si vous consultez des informations en ligne, vérifiez bien que la page fait référence à ce produit spécifique et non à un concurrent portant un nom similaire.

Pourquoi vos e-mails disparaissent

Un responsable marketing envoie une annonce client le lundi matin. À l’heure du déjeuner, les réponses sont plus faibles que prévu. Dans l’après-midi, quelques clients disent ne jamais l’avoir reçue. Quelqu’un vérifie les spams. Une autre personne transfère une capture d’écran d’un avis de non-remise. Soudain, ce qui ressemblait à un problème d’engagement se transforme en problème de livraison.

C’est généralement là que le serveur d’envoi d’e-mails entre en scène.

Votre serveur d’envoi est le système responsable de prendre le message que vous avez rédigé et d’essayer de le livrer au fournisseur de messagerie du destinataire. Si le serveur est mal configuré, non approuvé, bloqué ou s’il manque des signaux d’authentification clés, le côté réception devient suspicieux. Cette suspicion se manifeste souvent par un placement en spam, des messages rejetés ou un filtrage silencieux.

La partie déroutante

La plupart des utilisateurs pensent que “je l’ai envoyé depuis Gmail” ou “je l’ai envoyé depuis mon application de messagerie” résume toute l’histoire. Ce n’est pas le cas. Votre application n’est que l’interface. Le transfert réel se produit via l’infrastructure du serveur.

Une façon simple de voir les choses est la suivante :

• Votre application de messagerie est le bureau d’écriture.
• Le serveur d’envoi est le guichet de la poste.
• Le fournisseur de réception décide s’il doit accepter, inspecter ou rejeter le courrier.

Si le guichet de la poste ne peut pas prouver qui vous êtes, utilise le mauvais itinéraire ou semble suspect, votre message ne circule pas correctement.

Règle pratique : Si les e-mails disparaissent sans erreur claire, ne commencez pas par réécrire le message. Commencez par vérifier le chemin d’envoi.

C’est pourquoi le travail de délivrabilité commence souvent par la confiance technique, et non par des changements créatifs. La réputation de votre domaine, vos enregistrements d’authentification et les paramètres de votre serveur influencent tous la façon dont les fournisseurs traitent votre courrier, comme une communication commerciale légitime ou une usurpation d’identité potentielle. Si vous souhaitez une introduction utile sur cette couche de confiance, ce guide sur la réputation de l’expéditeur d’e-mails mérite d’être lu.

Ce que cela signifie dans la réalité

Lorsque les gens parlent de “délivrabilité des e-mails”, ils font généralement référence à une chaîne de décisions :

1. Le serveur de réception peut-il se connecter à votre serveur d’envoi ?
2. Votre serveur semble-t-il légitime ?
3. Votre domaine correspond-il à ses enregistrements d’authentification ?
4. Le contenu semble-t-il suffisamment sûr pour être accepté ?

Le serveur d’envoi d’e-mails se situe au début de cette chaîne. S’il est bien configuré, tout ce qui suit devient plus facile. S’il est mal configuré, vos campagnes commencent avec un handicap.

Qu’est-ce qu’un serveur d’envoi d’e-mails

Considérez un serveur d’envoi d’e-mails comme le bureau de poste numérique de votre e-mail. Vous rédigez le message dans Gmail, Outlook, Apple Mail ou une autre application, mais cette application a toujours besoin d’un système d’envoi de confiance pour acheminer le message vers l’internet.

Ce système d’envoi suit le protocole SMTP, abréviation de Simple Mail Transfer Protocol. Selon l’explication des serveurs de messagerie de Mailtrap, les serveurs d’envoi d’e-mails reposent sur le SMTP, où la communication entre les serveurs de messagerie se produit principalement sur le port TCP 25, tandis que la soumission authentifiée des clients utilise le port 587 ou le port 465, assurant une transmission sécurisée via le chiffrement TLS.

Un visuel aide :

Le voyage en cinq étapes

Voici ce qui se passe après avoir cliqué sur envoyer :

1. Vous créez le message
   Votre application de messagerie regroupe l’objet, le corps du message, les destinataires et les pièces jointes.

2. Votre application se connecte au serveur d’envoi
   C’est le premier transfert. Votre appareil ou logiciel soumet le message au serveur d’envoi.

3. Le serveur vérifie les bases
   Le système vérifie que le message est correctement formé et prêt pour le transfert.

4. Le serveur trouve le fournisseur du destinataire
   Il recherche où le courrier pour ce domaine doit aller et achemine le message vers l’extérieur.

5. Le côté réception évalue le message
   Le fournisseur du destinataire décide s’il doit l’accepter, le filtrer, le mettre en quarantaine ou le rejeter.

Voici une courte présentation si vous préférez la vidéo :

Deux tâches se déroulent en coulisses

Le chemin d’envoi implique généralement deux rôles qui semblent techniques mais sont faciles à comprendre.

Le MSA gère la soumission

Le Mail Submission Agent, ou MSA, est le premier point de contrôle. Il accepte le message de l’utilisateur ou de l’application. La validation initiale se produit à ce stade. Le système vérifie le formatage et l’intégrité des pièces jointes avant que le message ne soit transmis.

Vous pouvez considérer le MSA comme l’employé au guichet de la poste. Il s’assure que le colis est correctement étiqueté avant qu’il n’entre dans le flux postal.

Le MTA gère la livraison

Le Mail Transfer Agent, ou MTA, est la partie qui achemine le message vers le système de messagerie du destinataire. Il communique avec d’autres serveurs de messagerie et tente de terminer le transfert.

Cela ressemble davantage au réseau de livraison derrière le guichet. Les camions, les itinéraires, les transferts et le tri des destinations se produisent tous ici.

Si la configuration SPF, DKIM ou DMARC du domaine d’envoi ne correspond pas, le système de réception peut rejeter le message avant qu’une personne ne le voie.

Pourquoi les ports sont importants

De nombreux utilisateurs non techniques se retrouvent souvent bloqués. Ils entendent “SMTP utilise le port 25” et supposent que c’est le paramètre qu’ils devraient toujours utiliser. En pratique, ce n’est pas ainsi que fonctionne l’envoi client.

• Le port 25 est principalement destiné au relais de serveur à serveur.
• Le port 587 est couramment utilisé pour la soumission authentifiée des clients.
• Le port 465 est également utilisé pour la soumission sécurisée dans de nombreuses configurations.

Si vous saisissez des paramètres de courrier sortant dans une application de messagerie, un plugin ou un logiciel professionnel, vous travaillez généralement dans la partie soumission client du processus, et non dans la couche de relais serveur.

Types de serveurs d’envoi d’e-mails

Tous les serveurs d’envoi d’e-mails ne sont pas conçus pour la même tâche. Une petite entreprise est généralement confrontée à trois choix. Utiliser le serveur par défaut de votre fournisseur de messagerie, configurer votre propre serveur ou envoyer via un service de relais SMTP dédié.

La bonne option dépend de ce que vous envoyez, du contrôle dont vous avez besoin et de si votre équipe peut gérer le risque de délivrabilité.

Serveurs des fournisseurs

C’est l’option la plus familière. Si votre entreprise utilise Gmail ou Microsoft 365, vous utilisez déjà un environnement d’envoi géré par le fournisseur. Cela signifie que l’infrastructure, la sécurité et la maintenance du serveur sont gérées pour vous.

Pour la plupart des utilisateurs professionnels, c’est le chemin le plus simple car :

• La configuration est plus légère. Vous utilisez les paramètres SMTP standard du fournisseur.
• La confiance est plus forte. Les grands fournisseurs exploitent une infrastructure d’envoi mature.
• La maintenance est moindre. Votre équipe n’a pas besoin de gérer un serveur de messagerie.

C’est souvent la solution la mieux adaptée pour la communication professionnelle normale, la prospection personnalisée et l’envoi de campagnes modérées depuis un compte professionnel.

Serveurs auto-hébergés

Gérer votre propre serveur SMTP semble attrayant car cela donne l’impression d’un contrôle total. En réalité, cela crée souvent un casse-tête de délivrabilité.

Des données vérifiées montrent que les relais SMTP auto-hébergés à partir d’adresses IP résidentielles ou de VPS non configurés sont rapidement mis sur liste noire, 80 % échouant aux vérifications de base des enregistrements PTR, tandis que l’utilisation de services SMTP tiers authentifiés avec un alignement approprié donne des taux de livraison supérieurs à 95 %.

Cet écart est important car les fournisseurs de boîtes de réception se soucient moins de savoir si vous “possédez” le serveur que de savoir s’ils lui font confiance.

Pourquoi l’auto-hébergement échoue pour de nombreuses équipes

Une configuration auto-hébergée peut échouer de plusieurs manières :

• Mauvais historique de réputation. Une IP fraîche ou peu fiable ne semble pas automatiquement crédible.
• DNS inverse et alignement manquants. Les serveurs de réception s’attendent à ce que les vérifications d’identité technique correspondent.
• Charge opérationnelle. Quelqu’un doit surveiller l’authentification, les règles de relais et la prévention des abus.

Un serveur SMTP auto-hébergé peut toujours fonctionner pour des e-mails d’application limités ou un usage interne. C’est simplement rarement le chemin facile que les gens attendent, surtout pour les campagnes.

Posséder le serveur de messagerie ne garantit pas le contrôle de la délivrabilité. Le fournisseur de réception prend toujours la décision finale de confiance.

Services de relais SMTP dédiés

La troisième catégorie est un service spécialisé conçu pour envoyer des e-mails de manière fiable en votre nom. Ces outils se concentrent sur l’authentification, la gestion de la réputation, la visibilité de la livraison et la conformité aux politiques.

Cette option est logique lorsque votre équipe a besoin de plus de flexibilité d’envoi qu’une boîte aux lettres standard ne peut confortablement supporter, mais ne souhaite pas exploiter une infrastructure de messagerie à partir de zéro.

Voici le compromis en termes simples :

Option	Idéal pour	Force principale	Risque principal
Serveur fournisseur	E-mail professionnel quotidien	Simplicité et confiance	Limites d’envoi du fournisseur
Serveur auto-hébergé	Équipes techniques avec cas d’usage restreints	Contrôle total de l’infrastructure	Risque de réputation et de rejet
Relais SMTP dédié	Envoi à plus haut volume ou opérationnel	Outils de délivrabilité gérés	Complexité de plateforme ajoutée

Ce que la plupart des petites entreprises devraient faire

Si vous êtes une petite entreprise, une startup, une équipe de recrutement ou un organisateur d’événements, le défaut le plus sûr est généralement d’utiliser le serveur de confiance fourni avec votre fournisseur de messagerie, à moins que votre volume ou votre flux de travail ne nécessite clairement un relais dédié.

Cela évite le piège courant de construire une configuration d’envoi qui fonctionne techniquement mais qui est peu performante dans des scénarios pratiques.

Paramètres de configuration courants et exemples

Lorsqu’une application demande des “paramètres de serveur de courrier sortant”, elle demande les détails nécessaires pour se connecter au service SMTP de votre fournisseur. Les champs peuvent sembler intimidants, mais chacun a un objectif simple.

Selon le guide de configuration Gmail SMTP de Heimdal, les services SMTP cloud de niveau entreprise comme Gmail utilisent smtp.gmail.com avec le port 465 (SSL) ou le port 587 (TLS), et une configuration SSL/TLS appropriée améliore la délivrabilité en chiffrant la transmission.

Ce que signifie chaque champ

Nom du serveur

C’est l’adresse du serveur de courrier sortant. Il indique à votre application où envoyer l’e-mail pour soumission.

Pour Gmail, c’est smtp.gmail.com.

Port

Le port est la porte spécifique que votre application utilise pour se connecter. Ici, de nombreuses configurations échouent.

Pour Gmail, les choix courants sont :

• 465 pour SSL
• 587 pour TLS

Authentification

Cela signifie que votre application doit se connecter avec un compte de messagerie valide avant de pouvoir envoyer. Cela empêche votre appareil ou votre site web d’agir comme un relais ouvert.

SSL ou TLS

Ces couches de sécurité chiffrent la connexion pendant que le message est soumis. En termes simples, elles aident à prévenir l’interception et à réduire les problèmes de confiance lors de l’envoi.

Paramètres courants du serveur de courrier sortant

Fournisseur	Serveur SMTP	Port	Nécessite SSL/TLS	Nécessite Authentification
Gmail / Google Workspace	smtp.gmail.com	465 ou 587	Oui	Oui
Microsoft 365 / Outlook.com	Utilisez le serveur SMTP publié par votre fournisseur	Généralement paramètres de soumission sécurisés	Oui	Oui
Apple iCloud Mail	Utilisez le serveur SMTP publié par votre fournisseur	Généralement paramètres de soumission sécurisés	Oui	Oui

Comme les détails spécifiques aux fournisseurs peuvent changer, confirmez toujours le nom exact du serveur et la méthode de soumission acceptée dans la documentation du compte de la boîte aux lettres que vous configurez.

Un exemple en langage clair

Disons que vous connectez un formulaire de site web ou un client de messagerie de bureau à un compte Gmail.

Vous saisissez généralement :

• Serveur SMTP : smtp.gmail.com
• Nom d’utilisateur : votre adresse Gmail complète
• Mot de passe : votre mot de passe de compte ou méthode spécifique à l’application, selon la sécurité du compte
• Port : 587 ou 465
• Chiffrement : TLS ou SSL

Si l’application vous donne les deux options SSL et TLS, faites correspondre le port à la méthode de sécurité prise en charge par le fournisseur.

L’erreur la plus courante n’est pas le nom du serveur. C’est le choix de la mauvaise combinaison port et sécurité.

Une vérification rapide de la configuration

Avant de blâmer votre contenu, confirmez ces bases :

• Le serveur correspond au fournisseur. Ne mélangez pas les identifiants Gmail avec l’hôte SMTP d’un autre fournisseur.
• Le port correspond au type de chiffrement. Une inadéquation provoque souvent des échecs de connexion.
• L’authentification est activée. La plupart des fournisseurs ne relaient pas le courrier provenant de clients non authentifiés.
• Le nom d’utilisateur est complet. De nombreux services exigent l’adresse e-mail complète, pas seulement la partie avant le symbole @.

Ces quatre vérifications résolvent un nombre surprenant de problèmes de type “ça ne veut pas envoyer”.

Sécuriser votre envoi pour une meilleure délivrabilité

Si le SMTP est le camion de livraison, l’authentification est le contrôle d’identité au quai de chargement. Sans cela, les fournisseurs de réception doivent deviner si votre e-mail est légitime. Ils n’aiment pas deviner.

C’est pourquoi SPF, DKIM et DMARC sont si importants. Ensemble, ils agissent comme un système de passeport numérique pour votre e-mail.

Considérez cela comme un système de passeport

Un fournisseur de messagerie de réception veut répondre à trois questions :

1. Ce serveur était-il autorisé à envoyer pour ce domaine ?
2. Le message a-t-il été modifié en cours de route ?
3. Que devons-nous faire si les vérifications échouent ?

C’est à ces questions que ces enregistrements aident à répondre.

SPF est la vérification de l’adresse de retour

SPF indique au côté réception quels serveurs sont autorisés à envoyer au nom de votre domaine.

Si votre domaine indique que seuls certains expéditeurs sont valides, et que votre message provient d’ailleurs, cette inadéquation suscite la suspicion. SPF revient à vérifier si l’adresse de retour sur l’enveloppe appartient à un lieu d’expédition approuvé.

DKIM est le sceau d’inviolabilité

DKIM ajoute une signature qui aide à prouver que le message n’a pas été modifié pendant le transit et qu’il provient réellement d’un expéditeur approuvé.

C’est similaire à un sceau de cire sur un document. Si le sceau est vérifié, le destinataire peut faire confiance à l’intégrité du message avec plus d’assurance.

DMARC est la politique à la douane

DMARC indique aux fournisseurs de réception quoi faire lorsque les vérifications SPF ou DKIM échouent. Cela peut signifier surveiller, mettre en quarantaine ou rejeter le courrier suspect selon la politique en place.

C’est le livre de règles qui lie le système ensemble.

Pour une présentation plus approfondie du fonctionnement de ces vérifications en pratique, lisez ce guide sur l’authentification des e-mails.

Pourquoi cela affecte le placement en boîte de réception

L’authentification n’est pas juste une case à cocher de sécurité. Elle façonne directement la confiance.

Lorsque votre domaine et votre système d’envoi s’alignent correctement :

• Les fournisseurs de réception voient une identité cohérente
• L’usurpation d’identité est plus difficile
• Les filtres anti-spam ont moins de raisons de douter du message

Lorsqu’ils ne s’alignent pas, même des campagnes légitimes peuvent être signalées.

Deux autres éléments que les gens oublient

Chiffrement pendant la soumission

TLS est important car il protège la connexion entre votre application et le serveur d’envoi. Cela ne garantit pas magiquement le placement en boîte de réception, mais il soutient un chemin d’envoi plus fiable.

Rythme d’envoi et limites des fournisseurs

Même un compte bien authentifié peut rencontrer des problèmes s’il envoie trop agressivement pour le type de compte. Les fournisseurs attendent des modèles normaux. Si votre comportement d’envoi semble soudainement risqué, la confiance peut chuter.

Les fonctionnalités natives de publipostage Gmail ont également leur propre contrainte de débit. Selon l’analyse de GMass sur le publipostage intégré de Gmail, le publipostage Gmail natif limite la capacité d’envoi sortant à environ 75 % de la limite d’envoi quotidienne totale du compte.

Les enregistrements de sécurité prouvent l’identité. Le comportement d’envoi prouve le jugement. Vous avez besoin des deux.

Comment les outils de publipostage utilisent les serveurs d’envoi

Beaucoup de gens supposent qu’un outil de publipostage envoie via un serveur mystère séparé. Dans de nombreux flux de travail basés sur Gmail, ce n’est pas ainsi que cela fonctionne.

Au lieu de cela, l’outil utilise le chemin d’envoi de votre compte Google existant. Cela signifie que le serveur d’envoi en coulisses est lié au compte Gmail ou Google Workspace que vous utilisez déjà, plutôt qu’à un serveur autonome inconnu que vous devez gérer vous-même.

C’est important car le message conserve le contexte de votre identité d’expéditeur établie. Pour les utilisateurs professionnels, c’est généralement un meilleur point de départ que d’essayer de construire une configuration SMTP personnalisée à partir de zéro pour une prospection de routine.

L’avantage pratique

Disons qu’un responsable RH envoie des suivis d’entretien depuis un compte Google Workspace. Ou qu’un community manager envoie des rappels d’événements via Gmail. L’outil de publipostage aide à personnaliser et à organiser ces messages, mais la couche de confiance provient toujours du compte sous-jacent et de la configuration du domaine.

Cela simplifie les choses :

• Pas de serveur séparé à configurer
• Pas de réputation de relais supplémentaire à construire à partir de zéro
• Pas besoin de maintenir une infrastructure de messagerie

Le compromis est que le volume d’envoi reste lié aux règles de Google. Des données vérifiées indiquent que les serveurs d’envoi d’e-mails pour les outils de publipostage basés sur Gmail sont soumis aux plafonds quotidiens de Google de 1 500 destinataires par jour pour les comptes personnels standard et 2 000 pour les comptes Google Workspace premium, comme discuté dans cette discussion communautaire sur les limites de publipostage Gmail.

Le point clé à retenir

Les outils de publipostage peuvent rendre l’envoi plus efficace, plus personnalisé et plus facile à suivre. Mais ils n’effacent pas les fondamentaux. Vos résultats dépendent toujours de la réputation de votre compte, de la qualité de votre configuration d’authentification et de si votre volume d’envoi reste dans ce que le fournisseur attend.

Une liste de contrôle pour le dépannage des problèmes d’envoi

Lorsque l’envoi échoue, l’approche courante est de passer directement à la réécriture de l’e-mail. C’est généralement la mauvaise première étape. Commencez par le symptôme, puis faites-le correspondre à la cause probable au niveau du serveur.

Si vous obtenez une connexion refusée

La première chose à vérifier est le port.

Des données vérifiées indiquent que la confusion entre le port 25 et le port 587 cause 60 % des échecs SMTP sortants pour les utilisateurs non techniques, car le port 25 est souvent bloqué par les FAI, tandis que le port 587 avec STARTTLS est requis par les ESP modernes pour la soumission authentifiée.

Essayez cette liste de contrôle rapide :

• Vérifiez le paramètre de port. Si votre application utilise le port 25 pour la soumission client, passez au 587 si votre fournisseur le prend en charge.
• Faites correspondre la sécurité au port. Utilisez la méthode de chiffrement attendue par votre fournisseur avec ce port.
• Confirmez que vous configurez la soumission, pas le relais. La plupart des applications professionnelles ont besoin de paramètres de soumission authentifiés.

Si vous voyez une authentification échouée

Cela signifie généralement que l’application n’a pas pu prouver qu’elle avait l’autorisation d’envoyer via le compte.

Regardez ces éléments :

• Vérifiez le nom d’utilisateur. Utilisez l’adresse e-mail complète si le fournisseur l’exige.
• Revérifiez la méthode de mot de passe. Certains fournisseurs exigent un flux de connexion d’application spécifique.
• Assurez-vous que l’authentification est activée. Si l’application a une case à cocher pour l’authentification SMTP, elle devrait généralement être activée.

Si les messages sont rejetés comme spam

Un message rejeté pointe souvent vers des signaux de confiance, pas seulement vers le libellé.

Utilisez cet ordre :

1. Vérifiez l’alignement SPF, DKIM et DMARC
2. Confirmez que le domaine From correspond à votre configuration d’envoi
3. Examinez votre comportement d’envoi récent

Si le placement en spam est devenu un problème récurrent, ce guide sur comment empêcher les e-mails d’aller dans les spams est une étape pratique suivante.

Si vous atteignez une limite d’envoi

Ce n’est pas un bug du serveur. C’est généralement une limite de politique du fournisseur.

À ce stade, vos options sont opérationnelles, pas techniques :

• Réduisez le volume quotidien
• Divisez l’envoi entre les flux de travail professionnels approuvés
• Choisissez des outils et des plateformes adaptés à votre cas d’usage

Si votre équipe décide si une plateforme dédiée serait mieux adaptée pour des campagnes plus importantes, ce récapitulatif qui vous aide à comparer les meilleures plateformes de marketing par e-mail peut aider à définir les compromis.

Commencez par le chemin d’envoi, pas par le contenu de l’e-mail. La plupart des échecs de livraison laissent des indices dans la configuration.

---

Si vous souhaitez envoyer des campagnes personnalisées via votre compte Google existant sans gérer vous-même l’infrastructure SMTP, Mail Merge for Gmail est conçu pour ce flux de travail. Il permet aux équipes d’envoyer des messages personnalisés depuis Gmail en utilisant les données de Google Sheets, de suivre les ouvertures et les clics, de gérer les désabonnements et de garder les rapports visibles dans la feuille de calcul que votre équipe utilise déjà.