Un formulaire qui envoie « sans erreur », mais dont l’e-mail n’arrive jamais, est un grand classique sur WordPress. Même chose pour WooCommerce : confirmations de commande, factures ou réinitialisations de mot de passe qui finissent en spam (ou n’arrivent pas). La bonne nouvelle : la majorité des cas se règle avec une base propre côté e-mail, en particulier SPF, DKIM et DMARC.
Sources officielles : WordPress – wp_mail(), WordPress – Mail (configuration serveur), RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC).
1) Comprendre le probleme : « envoye » ne veut pas dire « recu »
Sur WordPress, beaucoup d’envois reposent sur wp_mail(). Un retour « OK » signifie surtout que la requete d’envoi a ete traitee, pas que le message est arrive en boite de reception. Le point est mentionne dans la reference officielle de wp_mail().
Ensuite, tout se joue sur l’infrastructure : quelle machine envoie, avec quel domaine, et avec quelles preuves d’authenticite.
2) SPF : autoriser vos serveurs a envoyer pour votre domaine
SPF indique quels serveurs ont le droit d’envoyer des e-mails pour votre domaine. Techniquement, cela se fait via un enregistrement DNS de type TXT. Reference : RFC 7208.
- Verifier qu’il existe un SPF pour votre domaine (TXT).
- Eviter plusieurs SPF concurrents : un SPF doit rester unique et lisible.
- Inclure les bons expéditeurs (messagerie, outil marketing, serveur SMTP, etc.).
Point pratique : beaucoup de soucis viennent d’un SPF incomplet (un outil envoie, mais n’est pas declare), ou d’un SPF duplique (deux TXT differents avec « v=spf1 »).
3) DKIM : signer les e-mails pour prouver l’integrite
DKIM ajoute une signature cryptographique aux messages. Le recepteur peut verifier que le message n’a pas ete modifie et qu’il provient d’un domaine autorise. Reference : RFC 6376.
- Activer DKIM dans votre fournisseur e-mail (il fournit une cle publique).
- Publier la cle publique dans le DNS (souvent un TXT avec un selecteur).
- Verifier que les messages sortants contiennent bien une signature DKIM.
Sans DKIM, une partie des fournisseurs devient plus stricte, surtout pour des e-mails transactionnels repetitifs.
4) DMARC : definir une politique et recevoir des rapports
DMARC s’appuie sur SPF et DKIM pour indiquer au recepteur quoi faire si un message echoue les controles (laisser passer, mettre en quarantaine, rejeter). Reference : RFC 7489.
- Publier un enregistrement TXT sur
_dmarc.votredomaine.tld. - Demarrer prudemment (policy « none ») pour observer sans bloquer.
- Monter progressivement (quarantine, puis reject) une fois SPF et DKIM stables.
DMARC est souvent la cle pour limiter l’usurpation et stabiliser la reputation du domaine, a condition que SPF et DKIM soient coherents.
5) WordPress et WooCommerce : check-list courte (fiable)
- Adresse « From » : utiliser une adresse du meme domaine que votre site (ex. [email protected]), pas une adresse gratuite externe.
- Envoi : privilegier un envoi authentifie (SMTP ou service equivalent) plutot qu’un envoi « local » fragile, selon les recommandations d’administration WordPress : Mail (WordPress).
- SPF/DKIM/DMARC : valider la base DNS avant de chercher des « rustines » dans WordPress.
- Tests : faire un test complet WooCommerce (commande, paiement, e-mails) et un test formulaire (envoi + reception).
6) Erreurs frequentes (et comment les eviter)
- SPF duplique : deux TXT differents avec « v=spf1 ». A corriger en fusionnant.
- DKIM non active : le DNS est publie, mais l’envoi ne signe pas (option non active cote fournisseur).
- DMARC trop strict trop vite : passer en « reject » sans avoir aligne tous les expéditeurs declare des rejets legitimes.
- Adresse d’expedition incoherente : « From » et domaine d’envoi ne correspondent pas, ce qui degrade l’authentification.
FAQ (delivrabilite e-mail) pour la Suisse romande
Pourquoi les e-mails de mon formulaire WordPress n’arrivent pas a Geneve ou Lausanne ?
La ville n’est generalement pas la cause. Les blocages viennent plutot de l’authentification (SPF, DKIM, DMARC), de la reputation du domaine, ou d’un envoi non authentifie. Commencer par valider SPF/DKIM/DMARC et l’envoi cote serveur, comme decrit par WordPress et les RFC.
Pourquoi WooCommerce n’envoie pas les confirmations de commande ?
Deux cas reviennent souvent : l’e-mail est bien genere mais bloque ensuite (delivrabilite), ou l’envoi serveur est mal configure. La reference WordPress sur l’environnement e-mail aide a cadrer le point serveur : Mail (WordPress). Pour le « genere mais pas recu », SPF/DKIM/DMARC sont prioritaires.
Dois-je activer DMARC si je n’ai qu’un petit site vitrine ?
Oui, c’est souvent utile, au minimum en mode observation (« none »). Cela permet de voir quels services envoient pour votre domaine et de renforcer progressivement la protection, selon la RFC 7489.
Un SPF suffit-il sans DKIM ?
SPF aide, mais DKIM apporte une preuve complementaire (signature) et DMARC coordonne le tout. L’ensemble est plus robuste que SPF seul, surtout pour des e-mails transactionnels.
Besoin de stabiliser les e-mails WordPress et WooCommerce ?
Pour diagnostiquer la delivrabilite, corriger SPF/DKIM/DMARC, fiabiliser l’envoi et tester les e-mails transactionnels (y compris en contexte local Suisse romande), contactez clickclick.ch.
