En juin 2026, un client de mes clients a arrêté de recevoir ses mises en contact. Pas de message d'erreur. Pas d'alerte. Le site tournait normalement, les visiteurs remplissaient bien le formulaire, et rien n'arrivait dans la boîte mail du restaurant.

Un plugin peut casser vos e-mails sans aucun message d'erreur

La cause : un bug sur WPMasterToolKit, le plugin qui gère entre autres l'envoi SMTP sur plusieurs sites que je maintiens. L'adresse d'expédition configurée dans le module SMTP a été remplacée automatiquement par l'adresse e-mail de l'administrateur du site. Résultat : le serveur SMTP a refusé les envois, parce que l'adresse d'expéditeur ne correspondait plus à celle autorisée sur le compte SMTP.

Aucune notification d'erreur visible depuis l'interface WordPress. Le formulaire de contact affichait toujours « message envoyé » côté visiteur. Le problème ne se voyait que d'un endroit : dans les logs SMTP, ou en constatant qu'aucun mail n'arrivait plus depuis un moment.

Ce que le client a perdu concrètement

Le restaurant concerné reçoit ses demandes de réservation et certaines commandes par formulaire. Pendant la période où le bug est passé inaperçu, ces mises en contact sont parties dans le vide. Je ne peux pas donner de chiffre exact sur le nombre de messages perdus, personne ne le sait avec précision puisqu'ils n'ont jamais été reçus. Ce qui est certain : du chiffre d'affaires est passé à la trappe, et le client n'a rien vu venir avant qu'on ne détecte l'anomalie.

C'est ce point qui rend ce type de panne différent d'un site qui plante. Un site en panne, tout le monde le voit dans les dix minutes. Un site qui n'envoie plus ses e-mails peut fonctionner « normalement » pendant des semaines.

Comment le problème a été détecté et corrigé

Le diagnostic est venu d'une vérification de routine sur les sites sous contrat de maintenance : test d'envoi d'un mail depuis le formulaire de contact, suivi d'une vérification dans les logs du plugin SMTP. L'adresse d'expéditeur ne correspondait plus au compte configuré chez l'hébergeur de mails. Une fois l'adresse remise à la bonne valeur dans le module, les envois ont repris immédiatement, sans autre intervention.

Depuis, ce test d'envoi fait partie des vérifications systématiques sur les sites que je maintiens.

Pourquoi WordPress n'envoie pas d'e-mails par défaut

WordPress utilise une fonction native, wp_mail(), pour tous ses envois : notifications de commande, réinitialisation de mot de passe, formulaires de contact. Cette fonction s'appuie par défaut sur la fonction mail() de PHP, qui délègue l'envoi au serveur d'hébergement.

Le problème : la plupart des hébergeurs mutualisés limitent ou bloquent ces envois pour lutter contre le spam. Résultat, un site fraîchement installé peut sembler fonctionner, jusqu'au jour où on teste vraiment un envoi et où rien n'arrive.

Le cas des sites récupérés sans SMTP jamais configuré

Une bonne partie des sites que je reprends à la suite d'un autre prestataire n'ont jamais eu de SMTP configuré. Le site a été livré, le client l'utilise depuis des mois, et personne n'a testé si les formulaires envoyaient réellement quelque chose. Ça fonctionne parfois par chance, via la fonction mail() par défaut de l'hébergeur, mais de façon peu fiable : mails filtrés en spam, envois retardés, ou silencieusement rejetés.

Symptômes typiques côté client

Le client ne comprend généralement pas ce qui se passe, parce que rien ne s'affiche comme une erreur. Les signes qui reviennent le plus souvent :

• Des formulaires de contact « qui ne servent à rien », le client s'en plaint sans savoir pourquoi
• Des notifications WooCommerce absentes alors que la commande apparaît bien dans l'admin
• Un e-mail de réinitialisation de mot de passe qui n'arrive jamais, découvert au pire moment
• Des mails reçus, mais systématiquement en spam

Configurer un envoi fiable : la méthode utilisée en production

La solution passe toujours par le même principe : ne jamais laisser WordPress envoyer via la fonction mail() par défaut. Il faut lui donner un vrai compte SMTP authentifié, comme n'importe quel client mail classique.

Sur les sites que je gère aujourd'hui, j'utilise le module SMTP intégré à WPMasterToolKit plutôt qu'un plugin dédié comme WP Mail SMTP, que j'utilisais avant. La raison est simple : WPMasterToolKit fait déjà tourner plusieurs autres fonctions sur ces sites (nettoyage, sécurité, optimisations diverses). Ajouter un plugin SMTP séparé revient à charger un plugin de plus pour une fonction que l'outil déjà installé peut couvrir. Moins de plugins actifs, c'est moins de surface de bug et moins de poids au chargement.

Pourquoi un module intégré plutôt qu'un plugin SMTP dédié

Ce choix n'est pas universel. Si vous n'avez pas déjà un outil tout-en-un installé, un plugin SMTP dédié comme WP Mail SMTP reste une option solide et largement éprouvée. Ce qui compte, ce n'est pas la marque du plugin, c'est de configurer un vrai serveur SMTP authentifié à la place de la fonction mail() native.

Les champs à ne jamais laisser en valeur par défaut

Quel que soit l'outil choisi, la configuration repose sur les mêmes champs, à saisir avec les identifiants réels de votre compte mail :

• Serveur SMTP (host) et port, fournis par votre hébergeur de mails
• Adresse e-mail d'expédition, qui doit correspondre exactement au compte SMTP utilisé
• Identifiant et mot de passe du compte mail
• Type de chiffrement (SSL ou TLS selon le port utilisé)

Le point sur lequel je vois le plus d'erreurs : l'adresse d'expédition renseignée dans le plugin doit être identique à celle du compte SMTP authentifié. Une adresse différente, même à première vue anodine (contact@ au lieu de no-reply@), suffit à faire rejeter l'envoi par le serveur.

DNS, SPF, DKIM, DMARC : la couche que tout le monde néglige

Un SMTP bien configuré ne suffit pas toujours. Si les enregistrements DNS du domaine ne sont pas correctement paramétrés, les mails partent, mais atterrissent en spam, ou pire, sont rejetés par certains fournisseurs.

Trois enregistrements à vérifier systématiquement :

• SPF : liste les serveurs autorisés à envoyer des mails pour votre domaine
• DKIM : signe cryptographiquement chaque mail envoyé pour prouver qu'il n'a pas été modifié en route
• DMARC : indique aux serveurs receveurs quoi faire si un mail échoue aux vérifications SPF ou DKIM

Ces réglages ne se font pas dans WordPress. Ils se configurent dans la zone DNS du domaine, chez l'hébergeur ou le registrar. Sur les sites que je gère, ça se passe chez o2switch ou chez Gandi selon où le client a son hébergement ou son nom de domaine.

Comment vérifier rapidement si vos enregistrements sont corrects

La méthode la plus simple : envoyer un mail de test vers une adresse Gmail, ouvrir le mail reçu, afficher l'original (« Afficher l'original » dans Gmail), et vérifier que SPF, DKIM et DMARC apparaissent tous les trois en « PASS ». N'importe quel résultat en « FAIL » ou « NEUTRAL » pointe vers un enregistrement DNS mal configuré ou absent.

Erreur fréquente : DKIM configuré côté hébergeur mais pas repris côté plugin SMTP

Un cas que je croise régulièrement : l'hébergeur mail a bien un DKIM actif pour son propre service d'envoi, mais le plugin SMTP utilisé sur WordPress envoie via un serveur différent (un service tiers, par exemple), qui n'est pas couvert par ce DKIM. Les deux couches doivent correspondre : le serveur qui envoie réellement le mail doit être celui pour lequel le DKIM a été généré.

FAQ

---

Un site WordPress qui n'envoie pas ses e-mails ne montre aucun signe extérieur de panne. C'est justement ce qui le rend dangereux : le problème peut durer des semaines avant d'être repéré, pendant que des demandes de clients partent dans le vide.