WooCommerce a deux pannes qui se ressemblent trait pour trait vu du client, et le correctif de l’une ne fait rien pour l’autre : soit la boutique n’a jamais envoyé l’e-mail, soit elle l’a envoyé depuis un serveur web que rien n’authentifie. Ce guide sépare les deux cas grâce au journal des e-mails transactionnels de WooCommerce, puis traite l’adresse From par défaut qui colle une adresse Gmail personnelle sur vos reçus, la raison pour laquelle l’enregistrement SPF de votre domaine ne couvre pas votre serveur web, et ce qu’un expéditeur SMTP change réellement. Vous passez ensuite une seule vraie commande de test vers une adresse de test Unspam, et vous lisez ce que la boîte de réception a vu.
La documentation de WooCommerce consacrée aux prestataires SMTP décrit ce qui se passe ensuite : comme WordPress n’est pas un serveur de messagerie, il délègue la tâche à PHP, qui va alors chercher un serveur de messagerie local sur votre serveur web pour expédier le message.
L’adresse From, sous WooCommerce > Settings > Emails, reprend par défaut l’adresse de l’administrateur du site définie dans Settings > General, qui sur la plupart des boutiques est une adresse personnelle datant du jour de l’installation (le nom From, lui, reprend le titre du site). La documentation de WooCommerce est directe sur la conséquence : utiliser une adresse sur un domaine public en @gmail.com ou @yahoo.com risque fort d’envoyer les e-mails dans les spams ou de les faire bloquer. Son guide d’authentification cite le retrait d’une adresse Gmail de l’en-tête From parmi les exigences expéditeur entrées en vigueur le 1er février 2024. Remplacez-la par une adresse sur le domaine où tourne votre boutique.
WooCommerce définit Pending payment comme une commande reçue sans paiement effectué, et sa FAQ e-mail précise qu’aucun e-mail n’est déclenché pour les commandes qui restent dans cet état. Quand une passerelle de paiement n’arrive pas à rappeler votre site, les commandes s’empilent en Pending payment et les clients ne reçoivent rien, ce qui est indiscernable d’un problème de spam vu de l’extérieur. Contrôlez l’état de la commande avant de toucher au DNS.
La plupart des boutiques publient quelque chose comme v=spf1 include:_spf.google.com ~all, pour des boîtes Google Workspace ou Microsoft 365. Le serveur web ne figure pas dans cette liste : un reçu portant From: orders@yourstore.com, envoyé par PHP depuis l’IP de l’hébergement, échoue donc à SPF pour votre domaine. Sans signature DKIM non plus, DMARC n’a aucun identifiant aligné sur lequel s’appuyer. Ajouter l’IP de l’hébergement à votre enregistrement SPF n’est pas le correctif : une IP mutualisée autoriserait alors tous les autres sites de la machine à envoyer en votre nom.
Les conseils SMTP de WooCommerce indiquent que les environnements mutualisés et virtuels ne sont en général pas optimaux pour envoyer des e-mails, et son guide d’authentification demande aux commerçants de vérifier auprès de leur hébergeur si le courrier de la boutique est authentifié, plutôt que de le supposer.
La liste des notifications sous WooCommerce > Settings > Emails comprend maintenant Abandoned cart recovery et Review request à côté des e-mails de commande, et les deux sont désactivées par défaut : Review request exige d’activer Customer review request (beta) sous WooCommerce > Settings > Advanced > Features, et les e-mails de panier abandonné sont arrivés avec WooCommerce 11.0 (4 août 2026) comme fonctionnalité expérimentale, à activer au préalable. Activez l’une ou l’autre et vos messages marketing partent par le même chemin non authentifié, depuis le même domaine, que vos réinitialisations de mot de passe. Les fournisseurs de messagerie notent le domaine et non le type de message : les plaintes gagnées par les relances de panier sont donc payées par un courrier transactionnel dont personne ne se plaint.
WooCommerce ne signe rien. Il remet le message fini à wp_mail(), PHP le passe au transport de messagerie présent sur le serveur web, et l’authentification devient une propriété de la route plutôt que de WooCommerce. Deux réglages décident de tout le reste : l’adresse From sous WooCommerce > Settings > Emails, et le fait d’avoir placé, ou non, un expéditeur SMTP authentifié devant PHP.
| enregistrement | par défaut | le problème | la solution |
|---|---|---|---|
| SPF | Votre domaine porte presque certainement un enregistrement SPF pour votre fournisseur de messagerie, et celui-ci n’inclut pas le serveur qui fait tourner votre boutique. | Le courrier envoyé par PHP part d’une IP que votre SPF n’autorise pas, donc SPF échoue pour le domaine From. Si votre hébergeur réécrit l’expéditeur d’enveloppe vers une adresse sur son propre domaine, SPF peut passer pour ce domaine-là sans pour autant s’aligner sur votre en-tête From, ce qui reste un échec DMARC dans les deux cas. | Envoyez par un prestataire SMTP authentifié et publiez l’include qu’il vous donne, par exemple v=spf1 include:_spf.google.com include:sendgrid.net ~all. Gardez exactement un enregistrement TXT SPF sur le domaine, parce que deux s’invalident mutuellement, et n’ajoutez jamais l’IP d’un hébergement mutualisé. |
| DKIM | Rien dans la boutique ne signe. Ni WordPress ni WooCommerce ne détient de clé de signature, donc toute signature doit venir du serveur de messagerie de votre hébergeur, et WooCommerce demande aux commerçants de lui confirmer si le courrier de la boutique est authentifié, plutôt que de le supposer. | Sans signature DKIM et sans SPF aligné, rien dans le message ne le rattache à votre domaine. Le guide d’authentification de WooCommerce rappelle que tout expéditeur a besoin de SPF ou de DKIM, et que ceux qui envoient 5 000 messages par jour ou plus vers Gmail ont besoin des deux, confirmés par DMARC. | DKIM vient du service d’envoi : choisissez donc un expéditeur SMTP, terminez sa vérification de domaine et publiez les enregistrements de sélecteur qu’il émet (en général des CNAME). Vérifier une seule adresse e-mail chez le prestataire n’équivaut pas à vérifier le domaine. Confirmez sur un envoi réel que la valeur d= de DKIM est bien le domaine de votre boutique, et non celui du prestataire. |
| DMARC | La plupart des boutiques WooCommerce ne publient aucun enregistrement DMARC, et la boutique envoie sans. | Publier p=quarantine ou p=reject avant d’avoir une route authentifiée transforme vos propres confirmations de commande en spam, puisqu’elles n’ont rien d’aligné à faire valoir. Laisser DMARC entièrement désactivé signifie à l’inverse que vous n’apprendrez jamais lesquels de vos expéditeurs (boutique, messagerie, application de facturation, outil de newsletter) échouent. | Publiez v=DMARC1; p=none; rua=mailto:dmarc@yourstore.com sur _dmarc.yourstore.com, lisez les rapports jusqu’à ce que le courrier de la boutique montre un pass aligné, puis durcissez. WooCommerce demande aux commerçants de confirmer SPF, DKIM et DMARC auprès de leur hébergeur ou de leur prestataire e-mail, plutôt que de les supposer configurés. |
| SMTP sender | Non configuré. WooCommerce appelle wp_mail(), qui appelle PHP, qui utilise le transport de messagerie que le serveur web se trouve fournir. | C’est la pièce qui vit en dehors du DNS et qui décide des trois autres lignes. Sans relais authentifié, il n’existe aucune clé pour signer et aucune IP qui vaille la peine d’être autorisée : aucune modification DNS ne produira donc un pass aligné. | Installez une extension SMTP qui redirige wp_mail() vers un prestataire. La liste des prestataires disposant d’une extension WordPress.org que publie WooCommerce comprend MailPoet (5 000 e-mails par mois gratuits, 500 destinataires uniques), Mailjet (6 000 par mois gratuits), Brevo (300 par jour gratuits) et WP Offload SES Lite sur Amazon SES. WooCommerce indique aussi que Gmail peut faire l’affaire, mais prévient que Gmail désactivera votre compte si vous écrivez à plus de 500 destinataires uniques en 24 heures, en comptant à la fois vos propres envois Gmail et tout ce que votre site expédie. |
Une fois ces enregistrements mis à jour, vérifiez qu’ils passent avec les outils gratuits d’Unspam : SPF checker, DKIM checker et DMARC checker.
WooCommerce propose un bouton Send a test email sur l’écran d’édition des e-mails, et il rend de vrais services pour contrôler la mise en page. Ce n’est pas un test de délivrabilité : la documentation développeur précise que l’aperçu n’utilise pas les données réelles de la base et construit à la place une commande fictive, des produits fictifs et une adresse fictive. Il saute aussi le changement d’état de commande qui déclenche l’e-mail en production. Pour apprendre quoi que ce soit de réel, passez une vraie commande adressée à une adresse de test Unspam.
Lancez un test antispam ou un test de placement en boîte de réception dans Unspam et copiez l’adresse de test qu’il génère. Un test de placement en boîte de réception génère aussi un ID de test. Collez-le dans l’objet ou dans le corps du message avant l’envoi, sinon le message arrive dans les boîtes de test sans jamais être rattaché à votre test. Dans WooCommerce, l’endroit propre pour le placer est WooCommerce > Settings > Emails : ouvrez la notification que vous testez, puis ajoutez l’ID de test au champ Subject ou déposez-le dans Additional content. Retirez-le une fois le test terminé.
Commandez sur votre propre boutique, ou créez la commande depuis l’administration WordPress, en utilisant l’adresse de test Unspam comme e-mail de facturation du client. Prenez un vrai produit, une vraie devise et un vrai mode de livraison, parce que le tableau de commande, les totaux et les liens font partie de ce qui est noté. Ne remplacez pas cette étape par Send a test email : ce bouton rend une commande fictive et ne vous apprend rien sur le message que reçoit un client.
Pending payment ne déclenche rien, par conception. Passez la commande en Processing pour déclencher la notification Processing order, ou en Completed pour la notification Completed order. La notification administrateur New order part sur la même transition, vers les destinataires listés sur son propre écran de réglages : si c’est cet e-mail que vous cherchez, ajoutez plutôt l’adresse de test à son champ Recipient(s).
Allez dans WooCommerce > Status > Logs et ouvrez la source transactional-emails, ajoutée dans WooCommerce 10.9. Chaque tentative y est consignée en Sent, Failed, Disabled ou Skipped. WooCommerce définit Sent comme le fait d’avoir remis l’e-mail au système de messagerie de votre site avec succès : tout ce qui manque ensuite relève de la délivrabilité, et non de la preuve que le client a reçu le message. Failed, Disabled ou Skipped veut dire qu’il n’est jamais parti, et aucun changement DNS n’y fera rien. Si vous ne voyez aucune entrée du tout, regardez WooCommerce > Status > Logs > Settings : le journal suit le seuil de niveau de votre boutique, qui peut masquer les entrées INFO et NOTICE.
Contrôlez le score de spam, puis le bloc d’authentification : DKIM doit être présent et signer avec le domaine de votre boutique, SPF doit passer et s’aligner, et DMARC doit afficher un pass aligné. Lisez ensuite le placement en boîte de réception par fournisseur, les prévisualisations dans les clients de messagerie, mode sombre compris, et la heatmap d’eye-tracking. L’assistant de correction par IA signale ce qu’il faut changer avant la prochaine vraie commande.
Le même test affiche votre campagne dans plus de 50 clients de messagerie réels, dont Gmail, Outlook, Apple Mail, iPhone et Android, chacun en mode clair et en mode sombre, grâce aux prévisualisations dans les clients de messagerie, pour confirmer le placement et le rendu en une seule passe.
L’aperçu de l’e-mail et son bouton Send a test email construisent une commande fictive, des produits fictifs, des variations fictives et une adresse fictive. La documentation développeur de WooCommerce le dit sans détour : il n’utilise pas les données réelles de la base. Comme le message emprunte tout de même votre vraie route d’envoi, un échec d’authentification qu’il révèle est bien réel, mais un test qui paraît propre ne prouve rien sur le contenu, les totaux ou les liens que recevrait un client.
Le nom From et l’adresse From sous WooCommerce > Settings > Emails s’appliquent aux e-mails qu’envoie WooCommerce. Le courrier du cœur de WordPress et celui des autres extensions retombent sur l’expéditeur par défaut de WordPress, à savoir wordpress@ suivi du domaine de votre site. Vos reçus peuvent donc partir en orders@yourstore.com pendant qu’une notification du cœur ou un message de formulaire de contact part en wordpress@yourstore.com, et les fournisseurs de messagerie construisent deux réputations séparées.
WooCommerce peut sortir les e-mails transactionnels de la requête de validation de commande pour les mettre en file. Cela s’appelle Deferred emails, sous WooCommerce > Settings > Advanced > Features, désactivé par défaut, et WooCommerce le décrit comme l’envoi des e-mails transactionnels de façon asynchrone via Action Scheduler au lieu de la requête en cours ; du code peut aussi le forcer avec le filtre woocommerce_defer_transactional_emails. WooCommerce documente Action Scheduler comme reposant sur WP-Cron, lui-même dépendant du trafic du site. Sur une boutique calme, le reçu attend le prochain visiteur. Regardez WooCommerce > Status > Scheduled Actions pour repérer les actions en retard.
Rediriger wp_mail() vers un prestataire fait passer votre courrier du serveur web à un relais authentifié, et cela règle en général le cas « rien n’arrive ». Cela ne signe pas automatiquement pour votre domaine. Tant que vous n’avez pas terminé la vérification de domaine chez le prestataire et publié ses enregistrements de sélecteur, le message est signé avec le domaine du prestataire, votre en-tête From annonce toujours yourstore.com, et DMARC échoue exactement comme avant, simplement depuis une meilleure IP.
Les problèmes de délivrabilité que les expéditeurs WooCommerce rencontrent le plus souvent, chacun avec la solution qui le règle.
La notification administrateur, c’est le domaine de votre boutique qui écrit au domaine de votre boutique. WooCommerce l’envoie en orders@yourstore.com vers un destinataire chez yourstore.com, par PHP sur le serveur web, sans signature DKIM et depuis une IP que votre enregistrement SPF n’autorise pas. Un message non authentifié qui se présente comme un expéditeur interne est traité bien plus durement que le même message arrivant sur un domaine sans lien, et certains fournisseurs le retiennent à la passerelle au lieu de le ranger dans le dossier spam, ce qui explique que vous ne le trouviez nulle part. Le courrier client passe de justesse, le courrier administrateur non.
La solution Placez un expéditeur SMTP authentifié devant wp_mail(), terminez la vérification de domaine chez le prestataire, publiez les enregistrements de sélecteur DKIM et ajoutez son include à votre unique enregistrement TXT SPF. En attendant, comme solution provisoire, changez le champ Recipient(s) sous WooCommerce > Settings > Emails > New order pour une adresse sur un autre domaine, afin de voir au moins arriver les commandes. Passez ensuite une vraie commande de test vers une adresse de test Unspam, confirmez que la valeur d= de DKIM est le domaine de votre boutique, puis remettez le destinataire d’origine.
Comme PHP remet le message à un serveur de messagerie local et que le journal de WooCommerce consigne seulement qu’il a remis l’e-mail au système de messagerie avec succès, votre journal affiche Sent et il n’y a aucun bounce à lire nulle part.
La solution Sortez complètement du chemin d’envoi par PHP. Faites passer wp_mail() par un prestataire SMTP authentifié, terminez la vérification de domaine pour que le message porte une signature DKIM sur le domaine de votre boutique, et ajoutez l’include SPF du prestataire. La deuxième chose que le prestataire vous apporte, c’est un suivi des bounces et des suppressions : les abandons silencieux cessent d’être invisibles. Lancez ensuite un test de placement en boîte de réception et confirmez que le message atteint bien une boîte de test Outlook, et pas seulement une boîte Gmail.
Reset password fait partie des notifications listées sous WooCommerce > Settings > Emails, donc elle peut être désactivée comme n’importe quelle autre, et elle emprunte la même route non authentifiée que le reste. C’est aussi la pire à perdre, parce que c’est le seul e-mail que le client attend activement et qu’aucune commande dans votre administration ne vient vous signaler l’échec. Une notification désactivée, un destinataire manquant et un message filtré se ressemblent tous, vus de la boutique.
La solution Ouvrez WooCommerce > Status > Logs et filtrez sur la source transactional-emails. Disabled signifie que la notification est désactivée sous WooCommerce > Settings > Emails > Reset password, Skipped qu’une condition préalable manquait, un destinataire par exemple, Failed que le service de messagerie a renvoyé une erreur, et Sent que WooCommerce l’a bien remis et qu’il a été filtré en aval. Si rien n’est consigné du tout, regardez d’où la réinitialisation a été demandée : WooCommerce prévient que les e-mails de réinitialisation de mot de passe de WordPress et les autres e-mails d’administration WordPress peuvent ne pas apparaître dans ce journal, et renvoie plutôt aux journaux de votre prestataire SMTP. Corrigez d’abord la route avec un expéditeur SMTP qui signe pour votre domaine, puis retestez en demandant une réinitialisation pour un compte dont l’adresse e-mail est une adresse de test Unspam.
SMTP a réglé le problème d’envoi, pas le problème d’identité. Le prestataire relaie désormais votre courrier depuis une IP réputée sous son propre Return-Path, donc SPF passe face au domaine du prestataire. Tant que la vérification de domaine n’est pas terminée, le message est signé en DKIM avec le domaine du prestataire et non avec le vôtre. Votre en-tête From annonce toujours yourstore.com, rien ne s’aligne dessus, et DMARC échoue exactement comme avant, simplement depuis une meilleure infrastructure.
La solution Dans le tableau de bord du prestataire, vérifiez le domaine plutôt qu’une seule adresse d’expéditeur, et publiez tous les enregistrements DKIM qu’il émet. Envoyez un vrai e-mail de commande vers une adresse de test et lisez la valeur d= de DKIM : si c’est encore le domaine du prestataire, la vérification est incomplète. Gardez un seul enregistrement TXT SPF en y ajoutant l’include du prestataire, par exemple v=spf1 include:_spf.google.com include:sendgrid.net ~all, plutôt que de publier un second enregistrement SPF, ce qui les invalide tous les deux.
C’est la file des e-mails différés. WooCommerce peut sortir les e-mails transactionnels de la requête de validation de commande pour que le client n’attende pas le serveur de messagerie : c’est la fonctionnalité Deferred emails sous WooCommerce > Settings > Advanced > Features, désactivée par défaut, et du code peut aussi la forcer avec le filtre woocommerce_defer_transactional_emails. La file tourne sur Action Scheduler, et WooCommerce documente Action Scheduler comme reposant sur WP-Cron, lui-même dépendant du trafic du site. Une boutique qui passe une nuit calme n’a aucun visiteur pour déclencher la file, donc le reçu attend le suivant.
La solution Ouvrez WooCommerce > Status > Scheduled Actions et cherchez les actions en retard ; une pile d’actions vieilles de plus d’un jour le confirme. Le conseil de WooCommerce est de mettre en place une tâche cron côté serveur qui exécute WP-Cron indépendamment et contourne la dépendance au trafic, ce qui règle les délais de toutes les tâches planifiées de la boutique, pas seulement des e-mails. Si le tunnel de commande était déjà lent avant le report, la cause est en général le saut vers le serveur de messagerie effectué à l’intérieur de la requête, et passer à un prestataire SMTP le retire aussi.
Ouvrez WooCommerce > Status > Logs et sélectionnez la source transactional-emails, ajoutée dans WooCommerce 10.9. Chaque tentative y est consignée en Sent, Failed, Disabled ou Skipped. Sent veut dire que le message a quitté votre site, donc le problème relève de la délivrabilité. Failed, Disabled ou Skipped veut dire qu’il n’est jamais parti, et aucun changement DNS n’y fera rien. WooCommerce précise aussi que le journal confirme seulement que wp_mail() a signalé un succès, pas que quelqu’un a reçu le message.
Au-delà d’une boutique de loisir, oui. La documentation de WooCommerce indique que les environnements mutualisés et virtuels ne sont en général pas optimaux pour envoyer des e-mails, et son guide d’authentification demande aux commerçants de confirmer auprès de leur hébergeur si le courrier de la boutique est authentifié en SPF, DKIM et DMARC. C’est un expéditeur SMTP authentifié qui vous donne une clé DKIM pour votre domaine, une IP avec une réputation et un journal de bounces que vous pouvez lire. Plusieurs des prestataires listés par WooCommerce proposent une offre gratuite qui suffit à une petite boutique.
Commencez par le champ Recipient(s) sous WooCommerce > Settings > Emails > New order, qui reprend par défaut l’adresse de l’administrateur du site définie dans Settings > General, puis cherchez une entrée transactional-emails dans WooCommerce > Status > Logs. Si le journal indique Sent et que le destinataire est sur le domaine de votre boutique, vous avez sous les yeux votre domaine qui écrit à votre domaine : un message non authentifié qui se présente comme un expéditeur interne a la forme d’une tentative d’hameçonnage et se fait filtrer bien plus durement que le même message arrivant sur un domaine sans lien, et certains fournisseurs l’arrêtent à la passerelle, si bien qu’il n’est pas non plus dans votre dossier spam. Corriger DKIM et SPF sur la route d’envoi règle les deux sens à la fois.
L’état de la commande, pas votre DNS. WooCommerce définit Pending payment comme une commande reçue sans paiement effectué, et sa FAQ e-mail précise qu’aucun e-mail n’est déclenché tant qu’une commande y reste. Les commandes calent dans cet état quand la passerelle de paiement n’arrive pas à recontacter votre site. Cherchez d’abord Pending payment ou Failed, regardez ensuite WooCommerce > Status > Logs, et seulement après commencez à examiner l’authentification.
Non. Unspam ne s’intègre ni à WooCommerce, ni à WordPress, ni à l’API d’aucune plateforme, et ne se connecte jamais à votre boutique. Il y a deux points de contact : une adresse de test à laquelle vous écrivez, et des identifiants SMTP que vous fournissez pour les tests automatiques. Pour WooCommerce, cela veut dire passer une vraie commande avec l’adresse de test comme e-mail de facturation, seul moyen de tester exactement le message que reçoit un client.
Envoyez le courrier transactionnel depuis le domaine de votre boutique, parce que c’est celui auquel le client vient de confier sa carte et celui que ses filtres ont appris à associer à l’achat. Si vous menez aussi des campagnes, gardez le marketing de masse sur un sous-domaine distinct, pour qu’un mauvais envoi ne puisse pas entraîner les reçus avec lui. Dans les deux cas, l’adresse From doit être sur un domaine que vous maîtrisez : WooCommerce prévient qu’une adresse en @gmail.com ou @yahoo.com dans le champ From risque fort de partir dans les spams ou d’être bloquée.
Les informations sur la plateforme WooCommerce ont été vérifiées à partir de la documentation publique en août 2026 et ont pu changer depuis. WooCommerce est une marque de son propriétaire respectif. Unspam n’est ni affilié à WooCommerce ni approuvé par WooCommerce.
