WP Mail SMTP ou FluentSMTP : choisir les routes de courriel

Choisir un transport à partir des messages que le site émet

Un site WordPress envoie des liens de réinitialisation, des confirmations de formulaire et des messages liés aux commandes. Ces messages peuvent partir du même compte ou de plusieurs expéditeurs. Avant de choisir un plugin, identifiez le service qui accepte de remettre chaque message à son destinataire. L’extension relie WordPress au transport choisi. Le prestataire décide ensuite si le message peut être accepté, selon le compte, le domaine et le volume.

WP Mail SMTP convient si l’équipe veut partir d’un assistant et établir d’abord une connexion principale. La grille Pro inclut les connexions de secours et Smart Routing, qui choisit une connexion selon des conditions. FluentSMTP propose gratuitement plusieurs connexions et un routage par adresse d’expédition. Ce ne sont pas deux moteurs de règles identiques. Un seul expéditeur peut se contenter d’une connexion ; un formulaire et une boutique qui doivent suivre des chemins distincts exigent un relevé plus précis des adresses.

Faites une petite liste de messages avec le composant qui les déclenche, l’adresse d’expédition attendue, l’adresse de réponse et le transport. Une commande peut devoir partir de commandes sur le domaine du site, tandis qu’un formulaire utilise contact. Le fait que les destinataires soient différents ne veut pas dire que deux transports sont nécessaires. Si un seul prestataire accepte les deux expéditeurs et que les volumes sont faibles, commencez avec une seule connexion.

Fixez un résultat que l’équipe saura contrôler. Un test visible dans la boîte n’est qu’une étape. Le résultat attendu comprend aussi l’adresse d’expédition, la réponse, le comportement des messages émis par les plugins et le retour à la configuration précédente en cas d’échec. La configuration retenue doit pouvoir être expliquée à la prochaine personne qui gérera le site.

• Recenser les messages et les expéditeurs.
• Choisir une seule connexion si elle couvre les besoins.
• Identifier les fonctions qui justifient éventuellement une deuxième route.

Préparer un environnement qui sépare le site de la messagerie

Sur une copie protégée, isolez les messages programmés et n’utilisez que des destinataires dont l’équipe contrôle les boîtes. Si la copie reprend une licence ou une clé de transport de production, vérifiez comment éviter que ses messages ou son volume se mélangent à ceux du site actif. Utilisez une connexion de test ou la fonction de simulation lorsqu’elle répond au but de l’essai. Une simulation permet de vérifier un chemin local. Un contrôle de réception exige une boîte que le test est autorisé à joindre.

Faites relever par la personne responsable du domaine les adresses que le fournisseur accepte pour l’envoi. L’adresse From est celle que voit le destinataire comme expéditeur. Reply-To est l’adresse qui reçoit une réponse lorsque le message en indique une. Dans un formulaire, utilisez une adresse du domaine que le transport autorise comme expéditeur et envisagez l’adresse du visiteur comme destination de réponse. Le service choisi peut imposer une adresse précise, même si WordPress permet d’en saisir une autre.

Si le prestataire demande des entrées DNS, préparez les valeurs selon sa documentation. Faites-les vérifier avec les réglages déjà utilisés pour le même domaine. Une entrée d’authentification mal modifiée peut affecter d’autres services que WordPress. Gardez un relevé des entrées et des personnes autorisées à les changer. Les identifiants de connexion restent dans l’outil prévu pour les secrets, à l’écart des captures et des fiches de recette.

Repérez les plugins qui interviennent déjà dans l’envoi WordPress. L’objectif est de mettre un seul plugin de transport en charge du même flux. Une extension de newsletter peut utiliser son propre canal. Testez séparément ce canal si le site l’emploie. Avant de désactiver un ancien transport sur la copie, relevez la méthode utilisée, les adresses forcées et les destinataires de test.

• Préparer une boîte et un compte d’essai.
• Vérifier les expéditeurs autorisés par le fournisseur.
• Conserver la configuration actuelle et protéger les identifiants.

Configurer une connexion principale dans WP Mail SMTP

Installez WP Mail SMTP sur la copie puis ouvrez WP Mail SMTP → Settings. Lancez l’assistant si vous commencez sans configuration. Choisissez le service que vous utilisez réellement. Pour un fournisseur compatible avec un connecteur dédié, suivez son écran d’autorisation. Pour un transport SMTP générique, reprenez les paramètres documentés par le fournisseur, notamment le serveur, le port et la méthode de protection. Ne mélangez pas les valeurs issues de deux services.

Renseignez l’adresse d’expédition autorisée et son nom d’affichage. Décidez si vous voulez forcer cette adresse pour l’ensemble du site. Cette option peut corriger un formulaire qui choisit un expéditeur incompatible, mais elle peut aussi empêcher une autre route qui dépend d’une adresse distincte. Commencez avec une seule page de test. Comparez l’expéditeur prévu par le composant et celui du courriel reçu. Vérifiez que la réponse arrive au bon endroit.

Dans WP Mail SMTP → Tools → Email Test, saisissez l’adresse de test et lancez un envoi. Ouvrez ensuite la boîte. Comparez la réception, l’expéditeur et les indications du plugin. Le test direct contourne le formulaire ou WooCommerce. Effectuez donc ensuite le parcours de la fonction qui déclenche le message, par exemple une soumission de test ou une réinitialisation pour un compte synthétique. Si seul ce parcours échoue, vérifiez le déclenchement dans son composant avant de remplacer la connexion.

Pour un deuxième prestataire dans WP Mail SMTP Pro, créez une connexion additionnelle, puis contrôlez-la avec Email Test. Pour le secours, ouvrez Settings → General → Backup Connection, sélectionnez cette connexion et enregistrez. Pour une route conditionnelle, ouvrez Settings → Smart Routing, activez la fonction, choisissez une connexion et une condition puis enregistrez. Exemple documentaire : From Email Is commandes@example.test pour le transport de la boutique. Remplacez cette adresse d’exemple par l’expéditeur de test autorisé. Le test direct d’une connexion ne démontre ni l’application de cette condition ni le déclenchement du secours.

• Configurer le fournisseur et l’adresse autorisée.
• Envoyer un test puis reproduire un déclenchement WordPress.
• Essayer la seconde connexion avant de régler une règle ou un secours.

Configurer les connexions et les expéditeurs dans FluentSMTP

Sur l’autre copie, activez FluentSMTP puis ouvrez l’assistant de premier réglage. Choisissez un prestataire, enregistrez la connexion et confirmez l’adresse From qui lui est associée. Dans l’écran Settings du plugin, vérifiez la liste Active Email Connections. Identifiez la route marquée Default. Elle sert de chemin pour les messages qui ne correspondent pas à une adresse associée à une autre connexion, selon le comportement documenté.

Pour une adresse distincte, créez la connexion adaptée et indiquez son expéditeur. Vérifiez que le composant émetteur emploie cette adresse. FluentSMTP dirige les messages qui correspondent à l’adresse propre d’une connexion vers celle-ci ; les autres passent par Default. La documentation décrit Fallback lorsque Default échoue. Ne promettez donc pas que le secours reprend automatiquement toute route explicite. Le menu à trois points permet Set as Default ou Set as Fallback ; une connexion ne peut pas porter les deux rôles.

Utilisez Send Test Email dans la barre du plugin puis contrôlez la boîte destinataire. Reproduisez ensuite le parcours réel avec un compte d’essai. Dans Email Logs, rapprochez l’heure, l’expéditeur et la réponse du transport. La documentation indique que Log Emails est activé par défaut, avec une durée configurable dans Delete Logs. Vérifiez les données réellement conservées avant de choisir la durée ou de désactiver la journalisation. Email Simulation empêche la livraison et marque les messages simulés ; ce mode ne fournit donc aucune preuve de réception.

Pour annuler un réglage, remettez la connexion précédente en Default et restaurez l’adresse choisie sur la page de test. Gardez les connexions encore nécessaires tant que le retour n’est pas validé. Selon la documentation, supprimer une connexion fait revenir ses expéditeurs vers Default, ou provoque un échec s’il ne reste aucune connexion. Refaites le parcours du formulaire et celui de la boutique : le changement d’une connexion peut affecter plusieurs composants.

• Créer une connexion principale puis une secondaire si nécessaire.
• Vérifier la route pour chaque adresse et le comportement de secours.
• Rétablir la connexion précédente et refaire les essais au retour arrière.

Interpréter les résultats de test et limiter les doublons

Pour chaque scénario, relevez l’événement, le destinataire, l’heure, l’expéditeur observé et le message reçu. Une action de formulaire qui n’a jamais appelé l’envoi se distingue d’un transport qui a refusé le message. Le journal peut montrer une erreur d’identification, de connexion ou d’adresse. Si le fournisseur l’a accepté sans que le message arrive, consultez les informations du fournisseur et le classement de la boîte avant d’ajouter une autre règle.

Pour le secours, vérifiez ce que le plugin considère comme un échec. Une réponse de succès du fournisseur principal suivie d’un classement dans les indésirables ne déclenche pas nécessairement le secours. Une simulation de panne doit porter sur la copie et ne pas invalider les accès du site actif. Vérifiez qu’un message émis une fois arrive une fois. En cas de duplication, rapprochez l’heure et les identifiants fournis par les journaux plutôt que de répéter l’envoi.

Les deux prestataires peuvent imposer des règles différentes sur le domaine, le nom ou la réponse. Faites un essai pour chaque expéditeur que le secours pourrait reprendre. Une adresse acceptée sur la première connexion n’est pas forcément autorisée sur la seconde. Si le secours doit utiliser une autre adresse, documentez ce changement pour l’équipe et vérifiez la réponse depuis la boîte de test.

Vérifiez aussi le formulaire qui ne doit pas envoyer au visiteur, par exemple un contact interne sans accusé de réception. Une règle de routage n’a pas pour rôle de créer un message qui n’existe pas. Le résultat attendu vient du scénario métier. Ce contrôle évite d’attribuer au transport une différence due au composant qui construit le courriel.

• Comparer le déclenchement, le transport et la réception.
• Tester le secours sur un environnement isolé.
• Rechercher la source d’un doublon avant toute relance.

Chiffrer la licence, le transport et le temps de maintenance

La grille WP Mail SMTP consultée le 4 novembre 2026 affiche Pro pour un site à 49 USD la première année, avec 99 USD comme tarif normal et renouvellement au plein tarif. Si ce tarif reste inchangé, trois années représentent 49 + 99 + 99 = 247 USD, hors taxes et transport. Il s’agit d’une projection conditionnelle, pas d’un prix garanti. FluentSMTP se présente comme entièrement gratuit, sans édition Pro. Une proposition commerciale datée reste nécessaire pour engager une dépense.

Les coûts de messagerie restent distincts. Un fournisseur peut facturer le nombre d’envois, les comptes, le volume ou certaines options de suivi. Pour le site témoin, estimez d’abord les messages ordinaires sur un mois et un pic crédible, par exemple après une campagne. Vérifiez si les messages transactionnels utilisent le même quota que les autres envois. Une extension gratuite peut être associée à un transport payant, tandis qu’une licence Pro ne remplace pas l’abonnement du fournisseur.

Comparez aussi le coût de deux connexions. Le secours est utile si un deuxième fournisseur est déjà autorisé et surveillé. S’il n’est jamais testé et que ses identifiants expirent, il n’apporte pas le résultat attendu. Vérifiez la route sur une boîte de test après une modification du domaine ou de l’expéditeur. Documentez les conditions de la formule qui inclut les connexions supplémentaires et la règle conditionnelle si l’équipe en a besoin.

Pour une configuration à un seul expéditeur, essayez d’abord le socle gratuit avec le fournisseur retenu. Pour une configuration plus large, comparez le coût de licence et la capacité à comprendre les routes. Le critère décisif est que le bon message parte du bon expéditeur et que l’équipe sache retrouver une erreur.

• Séparer licence, abonnement du prestataire et coût du secours.
• Confirmer les fonctions incluses dans l’offre choisie.
• Prévoir une vérification après chaque changement d’expéditeur.

Comparer les limites gratuites et les versions déclarées

Pour le besoin décrit, WP Mail SMTP Lite couvre une connexion et les essais d’envoi avec les services disponibles dans cette édition. La journalisation complète des courriels, le secours et Smart Routing figurent dans Pro. Certains connecteurs sont également payants : la fiche officielle marque notamment Amazon SES, Microsoft One-Click et Zoho Mail comme Pro. Ne déduisez pas de la présence du nom d’un fournisseur que toutes ses méthodes d’authentification sont gratuites. Faites correspondre la méthode voulue, la licence et le compte réellement disponible.

Dans FluentSMTP, le catalogue officiel annonce gratuitement les connexions multiples, le routage par expéditeur, les journaux et le secours. Cela répond au cas simple où contact et commandes utilisent deux adresses distinctes. Si la décision dépend du destinataire, d’un en-tête ou du composant qui produit le courriel, décrivez cette règle avant de choisir : la documentation Smart Routing de WP Mail SMTP expose ces conditions, tandis que le parcours FluentSMTP retenu ici repose sur l’adresse From. Une ressemblance de vocabulaire commercial ne suffit pas à établir une équivalence fonctionnelle.

Les fiches WordPress.org archivées le 3 novembre et recoupées le 4 novembre 2026 déclarent WP Mail SMTP 4.10.3, WordPress 5.5 minimum et PHP 7.4 minimum ; FluentSMTP 2.4.1, WordPress 6.5 minimum et PHP 7.4 minimum. Les deux affichent « testé jusqu’à » WordPress 7.1.4. Ce sont des déclarations de l’éditeur, pas des essais menés pour ce comparatif. Elles ne prouvent pas la compatibilité avec votre combinaison de formulaire, boutique, hébergement et transport.

Relevez les versions du site pilote avant de commencer. Sur la copie, conservez les mêmes extensions de formulaire et de boutique que sur le site prévu, ainsi que les options qui modifient l’expéditeur. Une mise à jour du plugin et un changement de fournisseur réalisés simultanément compliquent l’interprétation d’un échec. Faites varier un seul réglage à la fois et consignez le résultat attendu dans la fiche de recette. Le texte décrit un protocole à exécuter ; aucun message, authentification ou test pratique n’a été réalisé pour cette relecture.

• Rapprocher chaque fonction de l’édition qui la fournit.
• Relever WordPress, PHP et les composants du site pilote.
• Séparer le changement de transport de la mise à jour du plugin.

Basculer un flux puis pouvoir revenir au transport précédent

Avant la bascule, notez le dernier envoi de référence et conservez la configuration précédente dans un espace protégé. Désactivez le plugin de transport concurrent pour le même flux selon la méthode validée sur la copie. Appliquez la connexion principale, puis contrôlez un message représentatif du site. Vérifiez le fournisseur et la boîte avant d’activer des règles supplémentaires. Si le site doit gérer plusieurs composants, reprenez chaque parcours dans un ordre connu.

En cas d’échec, suspendez la modification et restaurez le transport précédent. Notez les messages qui ont été émis pendant l’essai avant de les relancer. Une commande ou une demande de réinitialisation peut avoir été transmise malgré une erreur de suivi. La décision de renvoyer doit s’appuyer sur la trace du transport et le contexte du message. Ne rediffusez pas en bloc tous les courriels de la période.

Gardez une fiche d’exploitation avec les adresses autorisées, la route principale et celle de secours, les composants testés et l’emplacement des journaux. L’équipe peut ensuite vérifier une règle à la fois. Si le prestataire change, comparez le domaine, l’expéditeur et le traitement des réponses avant de retirer les anciens accès. Cette préparation rend la prochaine migration aussi vérifiable que la première.

• Valider un flux avant d’étendre les routes.
• Rapprocher les envois avant toute reprise.
• Conserver une fiche de configuration exploitable par l’équipe.

Vérifier l’adresse de réponse après un changement d’expéditeur

Sur la copie, faites remplir le formulaire avec une adresse de test différente de l’adresse d’expédition. Une fois le message reçu, utilisez la commande Répondre de la boîte. Contrôlez l’adresse proposée avant de valider. Si elle correspond à la boîte de la boutique alors que l’équipe attend une réponse au visiteur, ouvrez les réglages de notification du formulaire et vérifiez son champ Reply-To. Gardez l’adresse autorisée par le fournisseur dans le champ From. Les deux valeurs peuvent être différentes.

Refaites le contrôle depuis le message de commande. Dans ce second scénario, la réponse peut devoir arriver au service chargé du suivi. Une règle générale qui force l’expéditeur peut être souhaitée pour garder le domaine validé, mais le formulaire et la boutique peuvent garder leurs adresses de réponse distinctes. Comparez les deux messages après activation d’une route de secours. Si un prestataire réécrit les champs, notez ce qui change et décidez si le secours peut prendre en charge ce flux.

Dans le dossier de recette, notez le composant qui fixe From, celui qui fixe Reply-To et la connexion qui envoie. Si un utilisateur signale ensuite que ses réponses arrivent à la mauvaise boîte, vous saurez quel réglage contrôler avant de toucher à la licence ou au DNS. Cette séparation est particulièrement utile quand un plugin de formulaires et un service de boutique partagent le même WordPress.

• Comparer la réponse à un formulaire et à un message de commande.
• Identifier le composant qui fixe chaque adresse.
• Vérifier les deux adresses après modification du transport.

Restaurer uniquement les réglages du flux qui a régressé

Prenons une boutique dont le formulaire fonctionne après la bascule, mais dont les confirmations de commande utilisent le mauvais expéditeur. Arrêtez l’ajout de nouvelles règles. Conservez l’identifiant de la commande de démonstration, l’heure et la trace du transport. Comparez d’abord le champ From construit par la boutique, l’option qui force l’expéditeur et la condition de routage. Restaurez la valeur précédemment notée pour ce seul flux. Un retour complet de la base effacerait potentiellement des commandes ou des modifications arrivées entre-temps sans expliquer la régression.

Si la panne touche tous les messages, revenez à l’ancien plugin de transport selon le parcours répété sur la copie : désactivez le nouveau transport, réactivez l’ancien, remettez sa connexion connue et contrôlez un test puis un déclenchement réel de démonstration. Conservez les réglages du nouveau plugin pour l’analyse au lieu de le désinstaller immédiatement. Les accès du fournisseur doivent encore être valides ; supprimer une clé avant la fin de la recette peut rendre le retour prévu impossible.

Le contrôle final porte sur deux cas positifs et un cas négatif. Le formulaire doit joindre la boîte interne avec la réponse dirigée vers l’adresse de test ; la commande doit arriver une seule fois avec son expéditeur prévu ; un message qui ne correspond pas à la règle doit rester sur la connexion principale ou par défaut. Notez les observations seulement lorsque ces essais auront été exécutés. Pour un message déjà accepté par le prestataire, décidez d’un éventuel renvoi au cas par cas, en tenant compte de sa validité et de son effet métier.

• Restaurer la règle, l’expéditeur ou la connexion identifiés.
• Conserver les commandes et données arrivées pendant la bascule.
• Valider les deux flux et le cas sans correspondance avant de fermer l’incident.

Pour aller plus loin

• Comparer la famille des plugins de courriel et newsletter
• Diagnostiquer un courriel de réinitialisation absent