Vos e-mails WordPress ne partent pas ? Trouver la cause et réparer l’envoi

Pourquoi les e-mails WordPress ne partent pas

Sur les forums WordPress.org, la même question revient chaque semaine : les e-mails WordPress ne partent pas, ou plus. Les notifications de formulaire n’arrivent pas, les e-mails de confirmation d’une inscription en double opt-in arrivent une fois sur deux, une newsletter programmée ne part jamais. Une vingtaine de sujets en six semaines, avec presque toujours le même point de départ.

Par défaut, WordPress confie ses e-mails à la fonction d’envoi de PHP, donc au serveur de l’hébergeur. Beaucoup d’hébergeurs la limitent ou la coupent. Quand elle fonctionne, le message part souvent sans authentification du domaine expéditeur : les messageries de destination le classent en indésirable ou le refusent sans rien dire.

Le site, lui, ne voit rien. WordPress considère l’e-mail comme transmis, et personne n’est averti de l’échec. C’est pour cela que le problème paraît aléatoire : il ne l’est pas, il est simplement invisible.

Pour en sortir, il faut deux choses. Une route d’envoi fiable, qui passe par un vrai serveur de messagerie. Et un endroit où lire ce qui s’est passé quand un message n’est pas parti.

Envoyer par SMTP ou par une API

Le module Mail de nexya remplace l’envoi par défaut. Vous choisissez une méthode : un serveur SMTP, celui de votre messagerie ou de votre hébergeur, ou un service d’envoi joint par son API, comme Brevo, Mailgun, SendGrid ou Postmark.

Le SMTP convient quand vous avez déjà une boîte professionnelle sur le domaine du site. L’API convient quand le site envoie beaucoup, ou quand l’hébergeur bloque les ports SMTP sortants. Dans les deux cas, chaque e-mail du site emprunte cette route : formulaires, réinitialisation de mot de passe, commandes, confirmations.

Le module Mail fait partie de la version gratuite, sur autant de sites que vous voulez. Comme tout module nexya, il s’allume et s’éteint depuis le hub ; éteint, il n’enregistre rien et aucun de ses crochets ne tourne sur le site.

• SMTP : l’adresse du serveur, le port, l’identifiant et le mot de passe fournis par la messagerie.
• API : la clé fournie par le service d’envoi.
• Dans les deux cas : une adresse d’expédition sur le domaine du site.

Réparer l’envoi des e-mails WordPress en quatre gestes

1. 1

   Choisir la méthode d’envoi

   Allumez le module Mail depuis le hub, puis choisissez SMTP ou API. Saisissez les accès fournis par votre messagerie ou la clé du service d’envoi, et une adresse d’expédition sur le domaine du site.

   
2. 2

   Envoyer un e-mail de test

   Envoyez un e-mail de test à une adresse que vous consultez. S’il arrive, la route fonctionne. S’il n’arrive pas, la cause est déjà dans le journal.

   
3. 3

   Lire la cause dans le journal

   Ouvrez le journal des envois. Chaque message raté y figure avec la raison renvoyée par le serveur : corrigez le réglage concerné ou transmettez-la à l’hébergeur ou au service d’envoi.

   
4. 4

   Protéger les formulaires

   Activez le captcha invisible sur les commentaires, la connexion et les formulaires. Il remplace reCAPTCHA ou Turnstile, sans Google ni Cloudflare et sans case à cocher pour le visiteur.

   

Le journal : la raison exacte de chaque échec

Changer de route ne suffit pas si l’on ne sait pas ce qui se passe ensuite. Le module Mail tient un journal des envois et enregistre chaque envoi raté avec sa cause, telle que le serveur SMTP ou le service d’envoi l’a renvoyée.

C’est ce qui manque dans la plupart des sujets de forum. « Mes e-mails ne partent plus » devient une phrase précise : un identifiant refusé, une adresse d’expédition non autorisée, un quota atteint. On sait alors à qui s’adresser, à l’hébergeur, au service d’envoi ou à la personne qui a changé le mot de passe de la boîte.

Le module permet aussi d’envoyer un e-mail de test. C’est le premier geste à faire après avoir réglé la méthode, et le premier à refaire quand un client signale un formulaire muet : si le test part, la route fonctionne et il faut chercher du côté du formulaire ou du destinataire.

Un e-mail qui échoue sans laisser de trace ne se répare pas. Un e-mail qui échoue avec sa cause se répare en quelques minutes.

Confirmations d’inscription et newsletters

Un e-mail de confirmation en double opt-in est un e-mail comme les autres : s’il passe par la fonction d’envoi de l’hébergeur, il subit les mêmes limites. Une fois le module Mail réglé, il prend la même route que le reste et, s’il échoue, son échec apparaît dans le journal.

Pour les newsletters, nexya Pro ajoute le module Mailya. Il envoie les campagnes depuis votre propre serveur, en arrière-plan, au rythme que ce serveur tient, sans compte tiers à faire valider avant le premier envoi. Son formulaire d’inscription passe par le captcha du module E-mails, une même adresse reçoit au plus un e-mail de confirmation par heure, et une inscription dont le domaine ne peut pas recevoir d’e-mail est refusée.

Une précision honnête : si votre newsletter est gérée par une autre extension et que c’est son planificateur qui se trompe d’heure, nexya ne corrige pas cette extension. Le module Mail garantit la route d’envoi et le journal, pas le calendrier d’un autre outil.

Les formulaires nexya et le captcha invisible

Une bonne partie des e-mails qui ne partent pas viennent de formulaires de contact. Deux causes reviennent : l’envoi lui-même, traité plus haut, et un captcha tiers, reCAPTCHA ou Turnstile, qui bloque la soumission sans message clair.

Le module Mail comprend un captcha invisible, sans Google ni Cloudflare, posé sur les commentaires, la connexion et les formulaires du site. Le visiteur n’a rien à cocher. Il est gratuit, comme le reste du module.

nexya Pro y ajoute ses propres formulaires. Ils partagent une même apparence, avec des listes déroulantes et un calendrier stylés, et s’insèrent par un bloc, un widget Elementor ou un shortcode. Un formulaire peut envoyer plusieurs e-mails, chacun avec ses destinataires, ses copies et ses conditions, ainsi qu’une réponse au visiteur.

Les entrées sont stockées sur le site, exportables en CSV ou en PDF mis en forme, avec une durée de conservation réglable en jours. Si un e-mail de notification échoue, la demande du visiteur n’est donc pas perdue : elle reste dans les entrées, et la cause de l’échec reste dans le journal.

• Plusieurs e-mails par formulaire, avec destinataires, copies et conditions.
• Une réponse envoyée au visiteur.
• Les entrées gardées sur le site, exportables en CSV ou en PDF.

Ce qui est gratuit et ce qui relève de nexya Pro

Pour faire partir les e-mails WordPress et savoir lesquels n’arrivent pas, la version gratuite suffit : envoi par SMTP ou par API, journal des envois avec la cause des échecs, e-mail de test et captcha invisible.

nexya Pro ajoute, pour l’envoi, un second serveur d’envoi et des alertes en cas d’échec : si le serveur principal refuse un message, un autre prend le relais et vous êtes prévenu, au lieu de l’apprendre par un client. Pro apporte aussi Mailya pour les newsletters et les formulaires nexya. La version gratuite ne contient aucun de ces codes ; nexya Pro est livré par Freemius après l’achat et reprend les réglages déjà faits.

Côté confidentialité, l’extension n’envoie rien à un tiers par défaut. Le service SMTP ou API que vous choisissez reçoit évidemment vos e-mails : c’est son rôle.