Un site WordPress peut très bien afficher des pages sans la moindre erreur visible et, pourtant, n'expédier aucun message à ses utilisateurs. Les formulaires de contact semblent fonctionner, mais aucune notification n'est reçue. Le problème peut apparaître sur n'importe quel type de site, du simple formulaire de contact à la boutique WooCommerce. Mais d'où vient réellement ce blocage ? Voici les principales causes pouvant expliquer l'absence de réception des e-mails.
Par défaut, WordPress utilise la fonction wp_mail(), qui repose généralement sur la configuration d'envoi disponible sur le serveur. Dans de nombreux environnements, cette fonction utilise la fonction mail() de PHP, mais elle peut également être configurée pour fonctionner avec un serveur SMTP. Seulement, la majorité des hébergeurs web ont désactivé ou fortement restreint l'utilisation de la fonction mail() de PHP sur leurs infrastructures mutualisées.
La raison en est que cette fonction est régulièrement détournée par des scripts malveillants pour expédier du spam en masse depuis les environnements d'hébergement. Pour protéger la réputation de leurs adresses IP et éviter leur inscription sur des listes noires, les hébergeurs bloquent donc son exécution. Dans ce cas, l'envoi peut échouer silencieusement ou être refusé par le serveur, sans qu'une alerte apparaisse clairement dans l'administration WordPress.
Le problème passe souvent inaperçu pendant plusieurs jours. Il est donc plus facile de le repérer et d'y remédier avec un bon contrat de maintenance WordPress.
Le protocole SMTP (Simple Mail Transfer Protocol) est le standard utilisé par les services de messagerie pour envoyer des courriels de manière sécurisée. En l'absence d'une configuration SMTP, les messages sont envoyés directement par le serveur web, sans authentification auprès d'un serveur de messagerie dédié. Les filtres des messageries de destination, comme Gmail ou Outlook, peuvent alors les identifier comme suspects.
Par défaut, WordPress n'est pas configuré pour utiliser un serveur SMTP. Cette absence de relais authentifié réduit fortement les chances d'une bonne délivrabilité. Les messageries modernes peuvent alors classer les messages parmi les indésirables ou les refuser.
Pour assurer un envoi plus fiable, le CMS doit être relié à un serveur SMTP externe fourni par un service de messagerie ou un prestataire transactionnel. Ce paramétrage nécessite un hôte, un port, un identifiant et un mot de passe. Les ports 465 (TLS implicite) et 587 (STARTTLS) sont les plus couramment utilisés. Sans ces informations correctement renseignées, la délivrabilité est fortement compromise, même si WordPress affiche un message de confirmation d'envoi.
Un message peut quitter l’hébergement sans aucun problème et ne jamais atteindre la boîte de réception du destinataire. Les filtres anti-spam analysent chaque courriel entrant selon plusieurs critères techniques :
Réputation de l'adresse IP ;
Présence sur une liste noire ;
Cohérence entre le domaine d'envoi et l'expéditeur déclaré ;
Score de spam attribué au contenu.
Quand l'un de ces critères déclenche une alerte, le message peut être automatiquement redirigé vers le dossier des indésirables, voire rejeté directement sans notification. L'expéditeur ne reçoit alors pas toujours d'avis d'échec et le destinataire ne voit aucun message dans sa boîte de réception.
La mise en quarantaine d'un e-mail par un filtre anti-spam ne signifie donc pas nécessairement que le site n'a pas tenté d'envoyer le courriel. Le message peut avoir quitté le site ou le serveur d'envoi sans atteindre sa destination finale. Vérifier le dossier spam de l’utilisateur reste une étape de diagnostic incontournable avant d'envisager une modification du paramétrage.
Les enregistrements DNS de sécurité (SPF, DKIM et DMARC) servent de mécanismes d'authentification permettant aux messageries destinataires de vérifier la légitimité des e-mails envoyés. Le SPF (Sender Policy Framework) indique quels serveurs sont autorisés à envoyer des messages au nom du domaine. Le DKIM (DomainKeys Identified Mail) appose une signature cryptographique sur chaque courriel pour confirmer son intégrité. Le DMARC, quant à lui, définit la politique appliquée lorsque les contrôles SPF ou DKIM échouent.
Lorsque ces enregistrements sont absents ou mal renseignés auprès du fournisseur de nom de domaine, les messageries destinataires ne peuvent pas authentifier l'expéditeur. Le message est alors considéré comme non vérifié. Il peut être rejeté ou redirigé directement vers le dossier spam. Cette situation survient fréquemment après une migration d'hébergeur ou un changement de serveur d'envoi.
La vérification de ces enregistrements se fait directement dans la zone DNS du domaine, accessible depuis l'interface du fournisseur de nom de domaine. Une erreur dans l'enregistrement SPF, une clé DKIM absente ou un DMARC mal configuré peut compromettre la délivrabilité des courriels du site.
Selon sa configuration, WordPress peut utiliser une adresse générique comme wordpress@nomdusite.com. Dans certains cas, cette adresse n'existe pas réellement ou n'a jamais été créée comme véritable boîte de messagerie chez l'hébergeur ou le fournisseur de nom de domaine. Le message est alors envoyé avec une adresse expéditrice fictive. Ce type d'incohérence est fréquemment détecté par les filtres anti-spam.
Autre cas fréquent : l'adresse d'expéditeur appartient à un domaine différent de celui utilisé par le serveur SMTP. Les protocoles SPF et DKIM peuvent détecter cette incohérence. Ce décalage entre l'adresse déclarée et le serveur d’acheminement réel peut provoquer le rejet du courriel côté destinataire.
La configuration doit rester cohérente entre l'adresse d'expéditeur, le domaine utilisé pour l'envoi SMTP et les enregistrements DNS. Toute divergence entre ces éléments peut entraîner un rejet par les systèmes de filtrage des messageries.
WordPress fonctionne grâce à un écosystème d'extensions. Certaines extensions, notamment celles dédiées à la sécurité, au cache ou aux performances, peuvent filtrer certaines requêtes PHP jugées suspectes. Ces restrictions, pensées pour protéger le site, peuvent également interférer avec le processus d'envoi des courriels.
D'autres extensions peuvent modifier le comportement d'envoi des e-mails ou appliquer des restrictions différentes, ce qui peut provoquer des incompatibilités. La compatibilité entre les extensions installées et la version de WordPress en cours d'utilisation joue également un rôle. Un plugin non mis à jour peut contenir des erreurs d'exécution qui bloquent l'envoi. Aucune alerte n'apparaît alors dans l'interface d'administration.
Les plugins de formulaire de contact comme Contact Form 7, WPForms ou Gravity Forms disposent de leurs propres paramètres d'envoi. Parmi ces paramètres figurent les en-têtes (headers) du message, qui définissent l'adresse d'expéditeur, le destinataire, le sujet et le type de contenu du courriel. Une erreur dans ces champs suffit à faire échouer l'envoi, même si le serveur SMTP est correctement configuré par ailleurs.
Une adresse incorrecte, un champ obligatoire mal configuré ou un paramètre d'envoi erroné peuvent empêcher la transmission correcte du message. Le courriel peut alors être généré par le CMS sans parvenir jusqu'à son destinataire. Certains plugins affichent également un message de succès dans l'interface alors que l’expédition a échoué en arrière-plan.
Le paramétrage de l'en-tête From: mérite une attention particulière. Si l'adresse indiquée dans ce champ ne correspond pas au domaine autorisé par le SPF, le courriel peut être rejeté à la réception. Tester l'envoi directement depuis les paramètres du plugin, avec les logs activés, reste une méthode rapide pour localiser l'erreur de configuration.
WordPress intègre un système de tâches planifiées appelé WP-Cron. Il exécute notamment l'envoi de newsletters, les notifications automatiques ou les rappels de commande. Ces tâches ne se déclenchent pas à heure fixe comme un cron système classique, mais à la prochaine visite du site après l'heure prévue.
Ce système présente toutefois une limite. Si le site reçoit peu de visites, ou si WP-Cron est désactivé, certaines tâches peuvent ne jamais être exécutées. Les courriels mis en attente peuvent alors ne jamais être envoyés ou être transmis avec plusieurs heures, voire plusieurs jours de retard. Ce dysfonctionnement passe souvent inaperçu, car les messages instantanés, comme les confirmations de formulaire, arrivent normalement, tandis que les envois différés échouent sans diagnostic apparent.
Une extension de cache ou une configuration serveur particulière peut parfois perturber l'exécution de WP-Cron en limitant les appels nécessaires au déclenchement des tâches planifiées. Dans ce cas, les tâches d'automatisation liées à l’expédition de courriels ne sont pas correctement exécutées. Analyser le journal des tâches WP-Cron via un plugin de diagnostic permet de repérer les files d'attente bloquées et d'identifier les envois en échec.
Dans la majorité des cas, les dysfonctionnements de réception des e-mails proviennent de l'une des causes présentées dans cet article. Un diagnostic méthodique, du serveur d'hébergement jusqu'au paramétrage des plugins, permet d'identifier la source exacte du problème et d'y apporter une correction ciblée.
