Serveur SMTP de secours WordPress : continuer d’envoyer malgré une erreur 401, 500 ou un quota dépassé

Serveur SMTP de secours WordPress : le problème posé sur les forums

La question revient souvent sur les forums WordPress.org : le site envoie ses e-mails par Mailgun, Brevo, un autre fournisseur ou un compte SMTP. Un jour, l’envoi échoue. Les messages sont parfois « 401 Forbidden » ou « 450 4.7.1 monthly message limit exceeded ». D’autres fois, le fournisseur répond simplement par une erreur 500. Les formulaires de contact, les commandes et les réinitialisations de mot de passe ne partent plus.

Une personne le résume ainsi sur le forum : l’extension d’envoi échoue, et au lieu de se rabattre sur autre chose, elle bloque tout. Ce qu’on cherche alors, c’est un serveur SMTP de secours pour WordPress : une seconde voie d’envoi, utilisée quand la première refuse.

Pour en arriver là, il faut d’abord savoir pourquoi le serveur principal refuse. Ensuite seulement, on décide si un secours suffit ou si l’erreur doit être corrigée à la source.

Lire l’erreur avant de chercher un secours

Les trois erreurs citées plus haut n’ont pas la même cause. Elles ne se règlent pas non plus de la même manière.

Une erreur 401 signifie que le fournisseur ne reconnaît pas les identifiants : clé d’API révoquée ou recopiée de travers, mot de passe changé, compte suspendu ou domaine pas encore validé chez le fournisseur. Un serveur de secours permet de continuer à envoyer, mais tant que la clé n’est pas corrigée, le serveur principal ne repartira pas.

Un quota dépassé, comme le « 450 4.7.1 monthly message limit exceeded », vient de votre offre chez le fournisseur. Le serveur fonctionne, mais il refuse d’envoyer davantage avant la fin de la période. C’est le cas où un second serveur rend le plus de services, à condition qu’il n’utilise pas le même compte, et donc le même quota.

Une erreur 500 vient le plus souvent du côté du fournisseur, et elle est souvent passagère. Le secours sert alors à ne rien perdre pendant la panne.

Dans nexya, le module Mail tient un journal d’envoi. Pour chaque e-mail qui n’est pas parti, il affiche la cause exacte donnée par le serveur. C’est là qu’on lit le code et le message, au lieu de deviner à partir d’un formulaire qui ne répond plus.

• 401 : identifiants refusés, à corriger chez le fournisseur ou dans la connexion.
• Quota dépassé : limite de l’offre atteinte, un second compte ou un second fournisseur prend le relais.
• 500 : erreur du côté du fournisseur, souvent passagère, le secours évite les pertes.

Ce que fait la version gratuite du module Mail

Le module Mail est gratuit, comme le reste de nexya, et sans limite de nombre de sites. Il s’allume depuis le hub. Tant qu’il est éteint, aucun de ses hooks ne tourne sur le site.

Il propose trois façons d’envoyer : un serveur SMTP, un fournisseur par API, ou un compte Gmail ou Microsoft 365 connecté avec OAuth, sans mot de passe enregistré sur le site. Un e-mail de test vérifie la connexion dès qu’elle est réglée.

Le journal d’envoi donne la cause de chaque échec. Pour une panne isolée, c’est souvent assez : on lit l’erreur, on corrige la clé ou on change d’offre, puis on renvoie un e-mail de test.

La version gratuite ne contient en revanche ni second serveur d’envoi ni alerte en cas d’échec. Ce code n’y est pas du tout, il fait partie de nexya Pro.

Ce qu’ajoute nexya Pro : un second serveur et une alerte

nexya Pro, vendu sur nexya.dev, ajoute au module Mail un second serveur d’envoi et des alertes en cas d’échec. Quand le serveur principal refuse un e-mail, l’envoi bascule sur le serveur de secours, et une alerte vous signale le problème.

Le message part donc quand même, et vous savez qu’il faut regarder le serveur principal. C’est exactement ce que demandent les sujets du forum : ne plus dépendre d’un seul fournisseur, et ne pas découvrir la panne trois jours plus tard par un client qui n’a jamais reçu sa confirmation.

nexya Pro est livré par Freemius après l’achat. Il prend le relais de l’extension gratuite avec les mêmes réglages : la connexion principale déjà configurée reste en place, il n’y a qu’à ajouter la seconde. nexya Pro conserve aussi les journaux plus longtemps, ce qui aide à repérer une panne qui revient.

Un serveur de secours ne remplace pas la correction de l’erreur : il garde le site en état d’envoyer pendant que vous la corrigez.

Mettre en place un serveur d’envoi de secours, étape par étape

1. 1

   Allumer le module Mail

   Dans le hub de nexya, allumez le module Mail. Tant qu’il est éteint, aucun de ses hooks ne tourne sur le site.

   
2. 2

   Lire la cause de l’échec dans le journal

   Ouvrez le journal d’envoi et relevez le code et le message du serveur : 401, quota dépassé ou erreur 500. Corrigez à la source ce qui peut l’être, une clé d’API ou un domaine non validé par exemple.

   
3. 3

   Vérifier la connexion principale

   Contrôlez la méthode d’envoi principale (SMTP, fournisseur API, Gmail ou Microsoft 365 avec OAuth), puis envoyez un e-mail de test pour confirmer qu’elle fonctionne de nouveau.

   
4. 4

   Ajouter le second serveur avec nexya Pro

   Avec nexya Pro, ajoutez un second serveur d’envoi sur un autre compte ou un autre fournisseur. En cas d’échec du principal, l’envoi bascule sur ce secours et une alerte vous prévient. Testez-le aussitôt avec l’e-mail de test.

   

Bien choisir le serveur de secours

Un secours n’est utile que s’il ne tombe pas en même temps que le serveur principal. Quelques règles simples aident à le choisir.

Prenez un autre compte, ou mieux un autre fournisseur. Deux connexions sur le même compte partagent le même quota et les mêmes identifiants : un quota dépassé ou une clé révoquée les bloque toutes les deux.

Variez la méthode si vous le pouvez. Par exemple, une API en principal et un compte Gmail ou Microsoft 365 connecté avec OAuth en secours, ou un SMTP chez votre hébergeur. Les trois méthodes du module Mail peuvent servir dans l’un ou l’autre rôle.

Vérifiez l’adresse d’expédition. Le serveur de secours doit avoir le droit d’envoyer pour votre domaine. Sinon, les e-mails partent mais risquent d’arriver en indésirables. Le module ne vérifie pas les enregistrements SPF, DKIM ou DMARC : c’est à contrôler chez le fournisseur et dans la zone DNS du domaine.

Enfin, testez le secours une fois réglé, avec l’e-mail de test, sans attendre la prochaine panne.

• Un compte ou un fournisseur différent du principal.
• Une méthode différente si possible : API, SMTP ou OAuth.
• Un domaine d’expédition autorisé chez le fournisseur de secours.
• Un e-mail de test envoyé dès la configuration.

Ce que nexya ne fait pas encore

Une limite concerne directement ce cas : on ne peut pas désactiver une connexion sans la supprimer. Si vous voulez mettre le serveur principal de côté le temps de régler un problème de clé, il faut l’effacer, puis le reconfigurer ensuite. Avant de supprimer une connexion, notez donc ses réglages : hôte, port, identifiant, clé ou compte connecté.

Les faits connus du module ne décrivent pas non plus de repli automatique sur la fonction mail() de PHP. Le secours prévu est un second serveur, que vous configurez vous-même dans nexya Pro.

Le module n’a pas non plus de bouton pour renvoyer un e-mail échoué. Le journal dit ce qui n’est pas parti et pourquoi. Le renvoi se fait depuis l’outil d’origine, par exemple en traitant à nouveau la demande reçue par formulaire.