Les e-mails de notification de nouvelle commande n’arrivaient pas dans la boîte Gmail d’un administrateur (pas même dans les spams, ils n’arrivaient pas du tout), et le plus frustrant était que la fonction wp_mail() de WordPress indiquait un succès à chaque tentative, ce qui écartait les suspects habituels : un appel défectueux à la fonction d’envoi, un conflit de plugins ou une panne du serveur.
Pourquoi « il dit que c’est envoyé » ne signifie pas « c’est arrivé »
Quand wp_mail() renvoie true, cela confirme seulement que le message a bien été confié au service d’envoi local du serveur ; cela ne dit rien de ce qui se passe ensuite, notamment si le serveur de réception (Gmail, ici) l’a accepté ou l’a silencieusement rejeté.
L’en-tête qui cachait le vrai problème
La vraie cause se trouvait dans les en-têtes du message : l’adresse d’expéditeur « From » configurée dans WooCommerce était une adresse @gmail.com, alors que le message était physiquement envoyé par le service de messagerie du serveur d’hébergement, et non par Google. Les enregistrements SPF (Sender Policy Framework) de Gmail n’autorisent que l’infrastructure de Google à envoyer des e-mails prétendant venir d’une adresse @gmail.com. Un message qui prétend venir de Gmail mais part d’un autre serveur échoue immédiatement à ce contrôle, et les protections anti-spam de Gmail considèrent un échec SPF sur un message qui usurpe l’une de leurs adresses comme un fort signal d’usurpation, surtout quand le destinataire est lui aussi une adresse Gmail.
Résultat : le message était rejeté ou filtré comme spam bien avant d’atteindre une boîte de réception, et c’est exactement pour cela qu’il n’apparaissait même pas dans les spams.
La correction en une ligne
Le domaine de la boutique disposait déjà d’un enregistrement SPF valide qui autorisait les serveurs de messagerie de son hébergeur ; il n’était simplement pas utilisé, puisque l’adresse d’expéditeur pointait vers Gmail. Remplacer l’adresse « From » des e-mails WooCommerce par une adresse sur un domaine pour lequel le serveur d’envoi est réellement autorisé (orders@[storedomain].com) a réglé le problème immédiatement : un e-mail de commande test est arrivé en boîte de réception en moins d’une minute, sans nouveau plugin, sans relais SMTP et sans modification DNS.
Points clés
- « La fonction a renvoyé un succès » et « l’e-mail a été délivré » sont deux affirmations différentes : diagnostiquer la délivrabilité exige de vérifier l’authentification, pas seulement l’appel d’envoi.
- Utiliser une adresse Gmail comme expéditeur quand le message ne part pas des serveurs de Google est un moyen quasi certain d’échouer au SPF et d’être filtré sans bruit.
- Vérifiez l’enregistrement SPF existant du domaine avant d’installer un nouveau plugin SMTP : l’autorisation existe souvent déjà et n’est simplement pas utilisée.
À lire aussi : ce que couvre vraiment la maintenance de site web, une erreur 403 intermittente causée par la durée du cache.
Vous rencontrez une limite similaire dans votre administration WooCommerce ou WordPress ? Parlons-en : ArtinTech Solution conçoit exactement ce type d’outils sur mesure pour les boutiques.