Améliorer la délivrabilité des e-mails WordPress et WooCommerce

Une commande est validée, le paiement passe, le client ne reçoit rien. Un utilisateur demande un nouveau mot de passe, l’e-mail finit dans les indésirables. Une notification WooCommerce apparaît comme envoyée dans les journaux du site alors qu’elle n’a jamais atteint personne.

Trois symptômes différents, une seule cause dans la grande majorité des cas : le site envoie ses e-mails avec la configuration par défaut de son serveur web.

Il faut commencer par accepter quelque chose d’un peu désagréable :

Quand WordPress affiche qu’un e-mail est parti, il ne dit pas qu’il est arrivé. La fonction wp_mail() confirme uniquement que la méthode d’envoi a accepté la demande. Tout ce qui se passe après lui échappe.

Cet article explique comment construire une chaîne d’envoi fiable pour les mails : confirmations de commande WooCommerce, formulaires de contact, créations de compte, réinitialisations de mot de passe, notifications administratives, renouvellements et relances d’abonnement.

Quatre éléments doivent être en place : un service d’envoi spécialisé, un domaine correctement authentifié, une configuration WordPress propre, et un suivi des erreurs et de la réputation. Il en manque presque toujours au moins un, et aucun ne compense l’absence des autres.

1. Ce que fait WordPress par défaut

WordPress passe par wp_mail(), qui s’appuie sur la bibliothèque PHPMailer. En configuration standard, PHPMailer utilise la fonction mail() de PHP et l’agent de transport disponible sur la machine. L’acheminement dépend donc entièrement du serveur qui héberge le site.

Or un serveur web est configuré pour servir des pages, exécuter du PHP, interroger une base de données et gérer des fichiers. Personne ne l’a préparé à gérer la réputation d’une adresse IP d’envoi, à traiter les rebonds, à absorber les plaintes pour spam, à signer les messages en DKIM, à respecter les limites de Gmail, d’Outlook ou de Yahoo, ni à réessayer proprement quand un envoi échoue.

Il fait le travail d’un serveur de messagerie sans en avoir les moyens, et surtout sans que personne ne le surveille.

« Envoyé » et « reçu » sont deux choses différentes

Entre la génération du message et sa lecture, il y a cinq étapes distinctes :

1. WordPress a généré le message.
2. Le serveur ou le prestataire l’a accepté.
3. Le serveur du destinataire l’a reçu.
4. Le message a été classé dans la boîte principale, dans les promotions, ou dans les spams.
5. Le destinataire l’a vu.

WordPress ne peut confirmer que la première, et éventuellement l’acceptation technique de la demande. Le reste se joue ailleurs, sans lui.

Les symptômes d’une chaîne cassée

• E-mails absents sans aucune erreur visible dans l’administration.
• Messages systématiquement classés en spam.
• Réception aléatoire selon les fournisseurs : les Gmail passent, les Outlook non.
• Délais de plusieurs heures.
• Confirmations WooCommerce jamais reçues par les clients.
• Réinitialisations de mot de passe impossibles.
• Aucune trace exploitable dans WordPress.
• Adresse d’expéditeur réécrite par le serveur, ou signalée comme suspecte.

Si plusieurs de ces symptômes vous parlent, ce n’est pas WooCommerce qu’il faut déboguer.

2. utiliser un serveur Mail dédié

Pour un site professionnel, et à plus forte raison pour une boutique, les e-mails ne devraient pas être remis directement par le serveur web. WordPress doit passer le relais à un service spécialisé, soit par une connexion SMTP authentifiée, soit par l’API du prestataire.

En SMTP, WordPress se connecte au serveur du prestataire avec une adresse, un port, un identifiant, un mot de passe ou une clé, et une connexion chiffrée.

En API, le plugin transmet les messages par requête HTTP. La seconde méthode est presque toujours préférable : l’authentification est plus facile à isoler, les erreurs remontent avec du détail, il n’y a aucune dépendance aux ports SMTP de l’hébergeur, et les journaux du prestataire deviennent directement exploitables.

Cette histoire de ports n’a rien de théorique. WP Mail SMTP indique que ses intégrations API continuent de fonctionner là où les ports SMTP sont bloqués par l’hébergeur. Sur un mutualisé verrouillé, c’est souvent ce qui sépare une configuration qui marche d’une configuration qui échoue en silence.

L’autre principe, c’est de ne pas faire reposer le site et l’acheminement de ses e-mails sur la même infrastructure. Cette séparation évite que la réputation de l’IP du serveur web contamine les e-mails, délègue les files d’attente et les nouvelles tentatives, fournit des journaux précis, permet de suivre les rebonds et les blocages, autorise un changement d’hébergement sans reconstruire toute la chaîne mail, et limite les dégâts si le site est compromis.

À noter quand même : le service d’envoi peut vivre sur une infrastructure distincte tout en utilisant votre domaine d’expéditeur. On sépare le transport technique, pas l’identité visible par le destinataire.

3. Choisir un prestataire d’e-mails transactionnels

Le prix arrive loin dans la liste des critères. Avant de comparer les tarifs, regardez le volume autorisé (mensuel ou journalier), la réputation du réseau d’envoi, la présence d’une API en plus du SMTP, la qualité des journaux, la gestion des rebonds et des plaintes, les webhooks, le support de SPF et DKIM avec la procédure de vérification de domaine, la localisation des données, la facilité d’intégration avec WordPress, le coût au-delà du quota gratuit, et la possibilité de gérer plusieurs domaines ou plusieurs projets sur un même compte.

Brevo

Solution française, avec relais SMTP, API transactionnelle, journaux d’envoi, gestion de modèles, statistiques et fonctionnalités marketing.

L’offre gratuite annonce aujourd’hui 300 e-mails par jour, sans limite sur le nombre de contacts stockés. Trois précisions comptent : le quota est journalier, il n’est pas reportable, et il est partagé avec les envois marketing si vous utilisez le même compte.

Bon choix pour un site vitrine, une petite boutique WooCommerce, une entreprise qui veut démarrer sans engagement, ou un client qui tient à un acteur français. La limite est facile à anticiper : une campagne, un pic de commandes, un import de clients ou une boutique qui envoie six notifications par commande, et les 300 messages quotidiens sont consommés avant midi.

Resend

Orienté développeurs et intégration par API : API d’envoi, relais SMTP, gestion des domaines, journaux, événements et webhooks, validation de SPF et DKIM. Resend précise qu’un domaine correctement vérifié sur sa plateforme passe déjà les contrôles SPF et DKIM, DMARC venant ensuite s’appuyer dessus.

Pertinent sur les projets sur mesure, les architectures où plusieurs applications cohabitent, et les sites dont l’envoi doit s’intégrer à des workflows techniques.

Le reste du marché

Postmark, Mailgun, Amazon SES, SendGrid, Mailjet, SMTP2GO, ou Scaleway Transactional Email pour rester sur un acteur européen. Toutes ces solutions fonctionnent, avec des positionnements différents.

Un comparatif tarifaire serait périmé dans six mois. Une lecture par usage vieillit mieux :

4. L’alternative open source : Postal

Postal est une plateforme d’acheminement d’e-mails open source, conçue pour être installée sur sa propre infrastructure. Le projet se présente comme une alternative autohébergée à SendGrid, Mailgun ou Postmark, avec interface d’administration, identifiants SMTP, journaux, files d’attente, webhooks, et gestion de plusieurs serveurs et domaines.

Le logiciel ne coûte rien. Le reste, si : serveur, sauvegardes, stockage, temps d’administration, adresses IP supplémentaires, surveillance de la réputation. Autohéberger, c’est prendre en charge l’installation, les mises à jour, la sécurisation, les certificats, les DNS, la réputation des IP, les files d’attente, les rebonds, les listes de blocage, les abus et comptes compromis, plus les éventuelles restrictions du fournisseur de serveur.

La documentation de Postal le dit sans détour : l’administrateur reste responsable de la configuration DNS, de la maintenance et des mises à jour. Côté ressources, elle recommande un serveur dédié avec au minimum 2 cœurs, 4 Go de RAM et environ 25 Go de disque, à revoir selon le volume.

Le point qui fait vraiment mal, c’est la réputation. Installer un serveur SMTP ne suffit pas à être délivré. Il faut une IP propre, un reverse DNS cohérent, un nom d’hôte valide, SPF, DKIM, DMARC, un warmup progressif de l’IP, un taux de rebond faible, un taux de plainte faible, un traitement rapide des adresses invalides et une veille sur les listes de blocage.

Postal a du sens pour une agence ou une organisation qui a du volume, des compétences système, une politique de maintenance et du temps à consacrer à la supervision. Pour un site WordPress isolé, un prestataire managé sera plus simple, et surtout plus prévisible.

5. Les plugins pour connecter WordPress au prestataire

Le plugin SMTP intercepte les e-mails générés par wp_mail() et les transmet au service choisi. Selon le plugin, il ajoute un test d’envoi, des journaux, des alertes, la gestion de plusieurs connexions, une connexion de secours, la réécriture de l’adresse d’expédition, et des messages d’erreur enfin lisibles.

FluentSMTP se connecte à Brevo, Amazon SES, Mailgun, Postmark et à d’autres services SMTP ou API. Il est gratuit, avec journaux d’e-mails, connexions multiples, tests d’envoi et une interface qui va droit au but. C’est celui ci que nous utilisons pour la plupart des sites de nos clients.

SureMail propose des connexions vers différents prestataires, avec journalisation et gestion de l’envoi. Attention au nom au moment de chercher dans le dépôt : SureMail, pas « SureSMTP ».

WP Mail SMTP, Post SMTP et SMTP Mailer font le même travail. Post SMTP annonce par exemple des intégrations avec Brevo, Microsoft 365, Amazon SES, Postmark, Mailgun et SendGrid.

Dans tous les cas, quand une intégration API dédiée existe, préférez-la au mode générique « autre SMTP ». La configuration est plus claire, les erreurs plus précises, la dépendance à l’hébergement plus faible, et les événements remontent mieux.

6. L’adresse d’expéditeur

Elle doit appartenir au domaine du site. Donc pas [email protected], pas [email protected], pas l’adresse d’un autre domaine, et surtout pas le [email protected] que génère l’installation par défaut.
Une adresse du type  commandes@[votresite].fr ou notifications@[votresite].fr fait l’affaire.

Envoyer depuis une adresse Gmail via un serveur qui n’est pas Google, c’est se placer volontairement en échec d’alignement DMARC. Les grands fournisseurs sanctionnent ce cas depuis des années.

Pensez aussi à séparer expéditeur et adresse de réponse :

From: [email protected] Reply-To: [email protected]

L’adresse d’envoi peut rester technique, tandis que les réponses arrivent dans une boîte réellement consultée. Ça évite de perdre des demandes clients dans une boîte que personne n’ouvre.

Sur les infrastructures plus avancées, un sous-domaine dédié (mail.exemple.fr, transactionnel.exemple.fr, notify.exemple.fr) simplifie la configuration DNS, l’identification des flux, la gestion de la réputation et le changement de prestataire. Il ne garantit rien à lui seul : ce qu’il apporte, c’est de l’organisation et de l’isolation technique.

7. Authentifier le domaine

Sans SPF, DKIM et DMARC, tout ce qui précède reste fragile.

SPF : qui a le droit d’envoyer

Sender Policy Framework permet au propriétaire d’un domaine de déclarer quels serveurs sont autorisés à envoyer pour ce domaine.

v=spf1 include:spf.brevo.com ~all

SPF se publie dans un enregistrement DNS de type TXT. Un domaine ne doit avoir qu’une seule politique, consolidée. Si un autre service existe déjà, on ne crée pas un second enregistrement : on réunit tous les prestataires dans la même ligne. SPF porte sur le domaine de l’enveloppe technique, pas sur l’adresse visible par le destinataire.

L’erreur la plus fréquente, et de très loin, consiste à publier deux enregistrements :

v=spf1 include:_spf.google.com ~allv=spf1 include:spf.brevo.com ~all

Ce qu’il faut écrire :

v=spf1 include:_spf.google.com include:spf.brevo.com ~all

Reprenez toujours la valeur exacte depuis la documentation du prestataire. Et gardez un œil sur la limite de 10 résolutions DNS : à force d’empiler les include:, on la dépasse, et SPF échoue sans le moindre avertissement.

DKIM : signer les messages

DomainKeys Identified Mail ajoute une signature cryptographique. Le serveur destinataire peut ainsi vérifier que le message est bien associé au domaine annoncé, que certaines parties n’ont pas été modifiées, et que la signature correspond à une clé publique publiée dans les DNS. Les prestataires fournissent un ou plusieurs enregistrements TXT ou CNAME à ajouter.

SPF dit qui peut envoyer, DKIM prouve l’intégrité du message. Les deux se complètent, aucun ne remplace l’autre.

DMARC : la politique du domaine

DMARC s’appuie sur SPF et DKIM pour vérifier que le domaine visible dans le champ From est aligné avec les mécanismes d’authentification. Un SPF qui passe techniquement mais ne correspond pas au domaine affiché fait échouer DMARC quand même.

v=DMARC1; p=none; rua=mailto:[email protected]

Trois politiques :

• p=none : on observe, rien n’est bloqué.
• p=quarantine : les messages non conformes peuvent partir en quarantaine ou en spam.
• p=reject : les messages non conformes peuvent être refusés.

Le déploiement se fait par étapes. Configurer SPF et DKIM, publier DMARC en p=none, analyser les rapports, recenser tous les services légitimes qui envoient pour le domaine, corriger les défauts d’alignement, passer en quarantine, puis envisager reject quand tous les flux sont maîtrisés.

Passer directement en p=reject sans avoir lu un seul rapport, c’est la meilleure façon de bloquer ses propres factures, son CRM ou sa plateforme de signature électronique. Resend rappelle d’ailleurs que DMARC dépend du bon fonctionnement préalable de SPF et DKIM.

Pourquoi ce n’est plus optionnel

Les grands fournisseurs ont sérieusement durci le ton. Google et Yahoo imposent aux expéditeurs de volume, au-delà d’environ 5 000 messages par jour vers des adresses personnelles, l’usage conjoint de SPF, DKIM et d’une politique DMARC, un mécanisme de désinscription en un clic pour les communications concernées, et un taux de plaintes maintenu sous 0,3 %. L’application s’est renforcée depuis fin 2025 : on parle maintenant de rejets définitifs, plus de simples ralentissements.

Même sur un site qui envoie dix messages par semaine, ces enregistrements améliorent l’identification de l’expéditeur, protègent contre l’usurpation et rendent les échecs diagnosticables. Il n’y a aucun argument sérieux pour s’en passer.

Les autres enregistrements

Sur une infrastructure autohébergée, prévoyez un enregistrement A pour le serveur d’envoi, un reverse DNS (PTR), un nom d’hôte cohérent, éventuellement un domaine de suivi, les MX nécessaires à la gestion des rebonds, et tout ce que réclame la documentation. Sur une solution managée, la plupart de ces éléments sont pris en charge ou fournis sous forme de CNAME.

8. Séparer transactionnel et marketing

Un e-mail transactionnel est déclenché par une action : confirmation de commande, facture, création de compte, réinitialisation de mot de passe, changement de statut, renouvellement d’abonnement, alerte administrateur. Il doit être prioritaire et fiable.

Le marketing, ce sont les newsletters, promotions, relances commerciales, annonces et campagnes automatisées. Plus de volume, plus de désinscriptions, plus de plaintes potentielles, un engagement beaucoup plus variable.

Une campagne mal ciblée ne devrait jamais pouvoir dégrader la délivrabilité des confirmations de commande. La séparation passe par des sous-domaines différents, des flux distincts chez le prestataire, des adresses d’expéditeur distinctes, plusieurs clés API, ou plusieurs connexions configurées dans le plugin.

9. Configurer WooCommerce

Passez en revue chaque notification : nouvelle commande, commande annulée, commande échouée, commande en attente, commande en cours, commande terminée, commande remboursée, nouvelle note client, nouveau compte, réinitialisation de mot de passe.

Avec WooCommerce Subscriptions, ajoutez le renouvellement, l’échec de renouvellement, la suspension, l’expiration, l’annulation et les rappels. Ce sont les moins testés, et ceux dont l’absence coûte le plus cher.

Vérifiez ensuite les destinataires administratifs. Ils pointent encore très souvent vers une ancienne adresse, celle de l’administrateur d’origine, une boîte pleine, ou une redirection cassée. Sur un site repris d’un précédent prestataire, commencez par là.

Imposez une identité d’expédition unique, pour éviter que chaque plugin y aille avec son propre nom et son propre domaine :

Nom : Boutique ExempleAdresse : [email protected]

Testez enfin les contenus : sujet, adresse de réponse, liens, images, rendu mobile, variables WooCommerce, pièces jointes, poids du message, affichage en mode sombre. Une facture PDF de trois mégaoctets pose autant de problèmes qu’un SPF absent.

10. Journaliser les envois

Sans journal, vous ne savez rien. Ni si WordPress a généré le message, ni si le plugin l’a transmis, ni si le prestataire l’a accepté, ni si le serveur distant l’a rejeté, ni si l’adresse était invalide, ni si le destinataire s’est désabonné, ni si le message a rebondi.

WordPress expose bien un événement wp_mail_failed lorsqu’une exception PHPMailer est interceptée, mais un plugin de journalisation rend cette information nettement plus utilisable.

Un journal correct contient la date et l’heure, le destinataire, le sujet, l’expéditeur, le statut, le prestataire utilisé, le message d’erreur, l’identifiant du message, le nombre de tentatives, l’événement de rebond, et le résultat de la connexion secondaire s’il y en a une.

Reste une question qu’on oublie systématiquement : ces journaux contiennent des adresses, des noms, des données de commande, des liens de réinitialisation, parfois le corps complet des messages. Limitez la durée de conservation, contrôlez les accès, ne journalisez pas le contenu intégral sans raison, excluez ce qui peut l’être, et documentez le traitement. Un journal activé « au cas où » et oublié depuis deux ans sur une boutique, c’est une base de données personnelles à part entière.

11. Gérer les échecs

Les causes classiques : clé API révoquée, quota dépassé, domaine non vérifié, erreur DNS, port SMTP bloqué, mot de passe modifié, adresse destinataire invalide, domaine temporairement bloqué, incident chez le prestataire, site compromis et suspendu, limite d’envoi atteinte.

Certains plugins permettent de configurer une connexion principale et une connexion de secours. Brevo en principal, Amazon SES ou Postmark en repli, par exemple. Une condition : le basculement doit conserver la même identité d’expéditeur, un SPF valide, une signature DKIM correcte et l’alignement DMARC. Sinon le secours se fait rejeter à son tour, et vous avez créé un problème de plus.

Prévoyez des alertes quand un e-mail échoue, quand le quota approche de sa limite, quand la clé API n’est plus valide, quand le taux de rebond grimpe, quand le prestataire suspend le compte, quand le domaine n’est plus authentifié. Une chaîne d’envoi tombe sans bruit. Sans alerte, on l’apprend par un client au téléphone.

12. Tester pour de vrai

Le bouton de test du plugin confirme trois choses : WordPress joint le prestataire, les identifiants sont acceptés, le message a été traité. Il ne dit absolument rien du placement dans la boîte de réception.

Envoyez donc vers Gmail, Outlook ou Microsoft 365, Yahoo, Proton Mail, et vers une adresse professionnelle protégée par un antispam d’entreprise. Dans les en-têtes reçus, vérifiez SPF=pass, DKIM=pass, DMARC=pass, le domaine signé, l’adresse de retour, et le serveur qui a réellement transmis le message. Sur Gmail, « Afficher l’original » donne tout ça en dix secondes.

Puis testez les vrais parcours : formulaire de contact, création de compte, réinitialisation de mot de passe, commande complète, commande échouée, remboursement, renouvellement d’abonnement, notification administrateur. C’est fastidieux. C’est aussi la seule façon de savoir.

13. La délivrabilité ne se limite pas à un  serveur mail

Avec SPF, DKIM et DMARC parfaitement configurés, un message peut encore finir en spam. Entrent aussi en jeu la réputation du domaine, celle de l’IP, une hausse brutale de volume, le taux de plaintes, le taux de rebond, le contenu du message, la qualité de la liste, la présence de liens raccourcis ou suspects, un domaine de liens différent du domaine expéditeur, des pièces jointes inhabituelles, un engagement faible, un site ou un compte compromis.

La répartition des rôles tient en trois lignes :

• SMTP assure le transport.
• SPF, DKIM et DMARC assurent l’authentification.
• La réputation et la qualité des envois déterminent le placement final.

Installer un plugin SMTP ne règle qu’une partie du problème, et pas la plus difficile. Le reste, c’est le choix du prestataire, l’identité d’expéditeur, l’authentification du domaine, des tests sur de vrais scénarios, des journaux, des alertes, et de la maintenance dans le temps.

Chez Heave, nous configurons et supervisons l’envoi des e-mails WordPress et WooCommerce : choix du prestataire, authentification du domaine, connexion SMTP ou API, tests transactionnels, journalisation, surveillance des erreurs. L’objectif n’est pas que WordPress affiche « e-mail envoyé ». C’est que le message arrive.