Sur WordPress et WooCommerce, les e-mails transactionnels (mot de passe, confirmation de commande, facture, notification admin) sont critiques. Pourtant, un site peut « envoyer » un e-mail sans garantie qu’il arrive réellement en boîte de réception. Cela se voit souvent quand des clients à Lausanne, Nyon, Vevey (Vaud), Genève, Carouge (Genève), Fribourg, Bulle (Fribourg), Sion, Martigny (Valais), Neuchâtel, La Chaux-de-Fonds (Neuchâtel), Delémont et Porrentruy (Jura) ne reçoivent pas les confirmations, ou les trouvent dans les indésirables.
Sources officielles utiles : WordPress – wp_mail(), WooCommerce – Réglages des e-mails, Google – Email sender guidelines (Gmail), Google – Email sender guidelines FAQ, IETF RFC 7208 (SPF), IETF RFC 6376 (DKIM), IETF RFC 7489 (DMARC), Microsoft – Outlook: exigences pour expéditeurs à grand volume.
1) Pourquoi « ça s’envoie » mais « ça n’arrive pas »
WordPress envoie des e-mails via wp_mail(). Un point important est explicitement mentionné : un retour « true » signifie seulement que la demande d’envoi a été traitée sans erreur, pas que le destinataire a bien reçu l’e-mail. Autrement dit, le problème se situe souvent après l’envoi (filtrage anti-spam, réputation, DNS e-mail, authentification).
2) Les 3 piliers à mettre en place : SPF, DKIM et DMARC
Pour la majorité des cas, la délivrabilité s’améliore fortement quand le domaine d’envoi est correctement authentifié dans le DNS :
- SPF : autorise quels serveurs ont le droit d’envoyer pour votre domaine.
- DKIM : signe cryptographiquement les messages pour prouver qu’ils n’ont pas été altérés et lier l’e-mail à votre domaine.
- DMARC : définit une politique et des rapports, en s’appuyant sur SPF et DKIM, pour réduire l’usurpation et cadrer la réception.
Google a renforcé ses exigences pour Gmail (notamment pour les expéditeurs à grand volume) autour de SPF, DKIM et DMARC. Microsoft a aussi annoncé des exigences plus strictes pour Outlook.com sur les expéditeurs à grand volume. Même si votre boutique n’envoie pas des milliers d’e-mails par jour, appliquer ces bonnes pratiques évite des blocages progressifs.
3) Etape par etape : une configuration simple et robuste
A) Choisir une identité d’envoi cohérente
- Utiliser une adresse « From » sur votre domaine (ex. [email protected]), pas une adresse générique du serveur.
- Garder une cohérence entre l’adresse d’envoi et le domaine réellement autorisé par SPF/DKIM.
B) Publier les enregistrements DNS (SPF, DKIM, DMARC)
Les valeurs exactes dépendent du service qui envoie vos e-mails (SMTP, service transactionnel, hébergeur e-mail). Ci-dessous, une forme typique, à adapter avec les éléments fournis par votre prestataire :
# SPF (TXT sur le domaine)
v=spf1 include:VOTRE_PRESTATAIRE -all
# DKIM (TXT sur un sous-domaine "selector._domainkey")
v=DKIM1; k=rsa; p=VOTRE_CLE_PUBLIQUE
# DMARC (TXT sur _dmarc.votre-domaine.ch)
v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=sBon réflexe : commencer avec p=none (surveillance), puis durcir ensuite si tout est stable. L’objectif est d’éviter de bloquer par erreur un flux légitime (facturation, support, formulaires).
C) Régler WooCommerce (nom et adresse expéditeur)
WooCommerce permet de configurer les informations d’expéditeur et les modèles d’e-mails. Vérifiez au minimum : nom de l’expéditeur, adresse d’envoi, et cohérence des e-mails transactionnels (commande, remboursement, compte client).
D) Tester avec un scénario réel
- Créer une commande test (paiement test si possible) et vérifier : e-mail client + e-mail admin.
- Déclencher un « mot de passe oublié » et vérifier la réception.
- Tester sur 2 ou 3 fournisseurs (Gmail, Outlook/Hotmail, Proton) si disponible.
4) Erreurs fréquentes (et rapides à corriger)
- Deux SPF : un domaine ne doit publier qu’un seul enregistrement SPF (sinon, échec ou comportement imprévisible).
- DKIM mal publié : mauvais sélecteur, clé tronquée, ou enregistrement sur le mauvais sous-domaine.
- From non aligné : vous envoyez avec une adresse, mais SPF/DKIM authentifient un autre domaine.
- Relais non autorisé : le serveur WordPress envoie directement sans être dans le SPF du domaine.
5) Suivre la qualité d’envoi (sans se compliquer)
Si vous envoyez en volume vers Gmail, Google recommande de surveiller les taux de spam et de rester sous des seuils annoncés dans ses guidelines. Même à faible volume, un pic de plaintes (ou des messages trop « marketing » envoyés comme transactionnel) peut dégrader la délivrabilité.
FAQ délivrabilité e-mails WordPress et WooCommerce
Pourquoi mes e-mails WooCommerce arrivent en indésirables chez Outlook ou Gmail ?
Les causes typiques sont l’absence (ou l’erreur) d’authentification SPF/DKIM/DMARC, une incohérence du domaine d’envoi, ou une réputation faible du serveur expéditeur. Stabiliser le domaine et envoyer via un service correctement authentifié règle souvent une grande partie du problème.
Est-ce que wp_mail() suffit pour une boutique ?
wp_mail() est l’interface d’envoi côté WordPress, mais ne garantit pas la délivrabilité. Pour une boutique, l’enjeu est surtout l’infrastructure d’envoi et l’authentification du domaine.
Dois-je activer DMARC si je n’envoie pas beaucoup d’e-mails ?
Oui, au minimum avec une politique de surveillance (p=none). Cela clarifie vos intentions aux destinataires et vous donne des rapports utiles pour détecter des envois illégitimes.
Quand passer de p=none a une politique plus stricte ?
Après une période stable, quand vous avez identifié tous les services qui envoient pour votre domaine (site, support, facturation, outils marketing). Ensuite, une montée progressive vers p=quarantine puis p=reject se décide au cas par cas.
Besoin de fiabiliser les e-mails transactionnels de votre site ?
Pour diagnostiquer la cause (DNS, expéditeur, WooCommerce), corriger SPF/DKIM/DMARC, puis tester de bout en bout (commande, mot de passe, admin), contactez clickclick.ch.
