Un email de commande
qui n'arrive pas
ne fait aucun bruit.

Les mélanger sur le même canal d'envoi fait que les plaintes de la newsletter dégradent la délivrabilité des confirmations de commande, autrement dit leur capacité à atteindre la boîte de réception. C'est exactement le mauvais ordre de priorité. La configuration technique passe avant tout le reste, et elle est ingrate parce qu'elle ne se voit pas.

Le domaine doit être authentifié chez le routeur, le service qui expédie vos emails, avec trois enregistrements publiés dans la zone DNS, l'annuaire public de votre nom de domaine : DKIM, une signature qui prouve que l'email vient bien de vous ; SPF, la liste des serveurs autorisés à envoyer en votre nom ; DMARC, la consigne donnée aux messageries sur ce qu'il faut faire des emails suspects. J'insiste sur un DMARC unique : deux enregistrements DMARC invalident la politique, et personne ne s'en aperçoit. Tant que ce n'est pas vert, un email peut partir sans erreur apparente et finir en spam.

Côté PrestaShop, le vrai levier est l'état de commande. Chaque état (paiement accepté, en préparation, expédié, remboursé) peut déclencher son email et son scénario. C'est ce qui permet une relance de panier abandonné qui tient compte du stock réel, ou un email post-achat envoyé le bon nombre de jours après la livraison plutôt qu'après la commande.

Ces deux détails font l'essentiel de l'écart entre un scénario qui rapporte et un scénario qui agace.