E-mails Woo / Presta qui tombent en spam

✉️ Ce n'est pas « le template qui est moche »

Un HTML lourd n'aide pas, mais le premier filtre, c'est qui envoie. Un From `[email protected]` avec un site `boutique.fr`, sans alignement SPF/DKIM, part à la poubelle. Gmail et Yahoo exigent SPF, DKIM et DMARC depuis février 2024, Microsoft depuis mai 2025. Les boutiques « ça marchait en 2019 » le découvrent d'un coup.

Woo et Presta génèrent le mail. Ils ne sont pas un service d'envoi (ESP). Leur boulot s'arrête au contenu. Le transport, c'est SMTP / API (Brevo, un SMTP pro, Amazon SES…). On sépare les deux.

🔐 SPF, DKIM, DMARC : le trio

Le domaine d'envoi doit autoriser le serveur (SPF), signer (DKIM), et déclarer une politique (DMARC, même `none` au début). Le From visible et le Return-Path doivent être cohérents. Un plugin Woo qui change le From sans toucher au DNS empire les choses.

On ne « met » pas DKIM au hasard. On suit l'ESP. On vérifie avec un en-tête, pas avec un ressenti.

• From = une adresse du domaine (pas noreply@gmail)
• SPF inclut le SMTP réel
• DKIM qui passe le check
• DMARC au moins en surveillance

🚚 SMTP, pas mail() PHP

Le `mail()` du mutualisé n'a plus de réputation. Un SMTP authentifié (ou une API) a une IP dédiée ou un pool propre. Les files : on n'envoie pas 400 mails de newsletter par le même canal que les commandes. La newsletter a un article dédié : on ne l'envoie plus depuis wp-admin.

Presta : module SMTP + mails. Woo : un seul plugin mail, pas trois. Les doublons créent deux From.

📝 Contenu qui aide (un peu)

Une vraie version texte, un sujet clair (« Votre commande 1042 »), moins d'images cassées, un lien de désinscription seulement sur le marketing. Les e-mails transactionnels n'ont pas à ressembler à une promo. Plus c'est promo, plus le filtre doute.

Les PJ PDF trop lourdes : parfois on remplace la pièce jointe par un lien vers le compte client. Moins de pièces, plus d'arrivées.

Un mail de commande doit être ennuyeux et fiable. Pas créatif.

📋 Logs et TMA

On lit les bounces, on a un log d'envoi. « Je n'ai rien reçu » se vérifie : envoyé ? accepté ? classé spam ? Sans log, on se dispute. Avec log, on corrige.

Après chaque changement de DNS, on reteste les trois boîtes. C'est dans le forfait TMA boutique, pas un mystère.

✅ Ordre de vérification d'un mail qui part en spam

On teste d'abord un envoi réel vers trois boîtes différentes, puis on lit les en-têtes du message. L'expéditeur, l'authentification du domaine et le contenu se vérifient dans cet ordre.

Sauvegarde de la configuration DNS avant modification, accès à votre nom chez le registraire. Puis 24 à 72 h de suivi des envois. Sans ce suivi, un correctif qui marche pour Gmail peut encore échouer ailleurs.

• Envoi test vers trois boîtes différentes
• Copie de la boutique avec boîte piégée
• Un enregistrement DNS modifié à la fois
• Contrôle humain puis 24 h de suivi des envois

📌 Ce que je refuse sur ce sujet

Je refuse de contourner le problème avec un plugin d'envoi de plus. Je refuse de modifier le DNS sans l'avoir sauvegardé. Je refuse de promettre « 100 % en boîte de réception ».

Je refuse aussi de me taire : si le vrai sujet est la réputation de l'expéditeur ou un fournisseur d'envoi inadapté, je le dis. Ce texte n'est pas un prétexte pour vendre un service d'envoi.

🧭 Questions fréquentes

Faut-il corriger tout de suite ? Oui si des clients ne reçoivent plus leurs confirmations de commande. Sinon, vérifiez l'authentification du domaine avant la prochaine opération d'envoi.

Peut-on tester l'envoi sans copie de la boutique ? On peut envoyer un e-mail de test depuis la production, mais pas changer le serveur d'envoi à l'aveugle. Je règle d'abord sur une copie avec une boîte piégée, puis j'applique.

Combien de temps ? Une à deux heures pour diagnostiquer, plus le délai de propagation des changements DNS (jusqu'à 48 h). Un correctif « en dix minutes » ignore souvent ce délai.