PrestaShop n'envoie plus d'emails : le diagnostic complet

Une panne silencieuse et coûteuse

Quand PrestaShop n'envoie plus d'emails, rien ne casse visiblement. Les commandes passent, le back-office fonctionne. Mais le client ne reçoit pas sa confirmation, appelle le service client, et la confiance s'effrite. Beaucoup de marchands découvrent le problème plusieurs semaines après son apparition.

Le diagnostic se mène en quatre niveaux, du plus simple au plus technique. Ne sautez pas d'étape : la cause est souvent au niveau 1.

Niveau 1 : la configuration PrestaShop

Rendez-vous dans Paramètres avancés > E-mail.

Le piège numéro un se lit directement en base :

SELECT name, value FROM ps_configuration WHERE name LIKE 'PS_MAIL%';

Le paramètre PS_MAIL_METHOD prend trois valeurs : 1 pour la fonction mail de PHP, 2 pour SMTP, et 3 pour désactivé. La valeur 3 est la cause la plus fréquente des « aucun email ne part ». Elle est parfois positionnée par un module, ou pendant une phase de recette, puis oubliée.

Vérifiez ensuite l'adresse d'expédition. Elle doit appartenir à votre domaine. Une boutique qui expédie depuis une adresse Gmail ou Yahoo voit ses messages rejetés par la majorité des serveurs de réception.

Utilisez enfin le bouton de test d'envoi présent sur cette page : il donne un message d'erreur brut bien plus utile qu'un test depuis le tunnel de commande.

Niveau 2 : la régression SMTP de PrestaShop 9

Ce cas mérite une section à lui seul, car il touche des boutiques dont la configuration n'a pas bougé.

PrestaShop 9 a remplacé Swift Mailer par Symfony Mailer, et le chiffrement SSL a été retiré de la couche d'abstraction : seuls TLS ou aucun chiffrement restent proposés. Conséquence observée : la chaîne de connexion est construite en ssl://serveur:587 là où la version 8 utilisait tcp://serveur:587.

Or le port 587 attend du STARTTLS, c'est-à-dire une connexion en clair qui bascule ensuite en chiffré, et non du SSL implicite. Le serveur répond alors une erreur du type :

SSL operation failed with code 1
error:0A00010B:SSL routines::wrong version number

Ce message, très déroutant, ne signale pas un problème de certificat mais une incompatibilité de protocole.

Le contournement immédiat consiste à basculer sur le port 465 en SSL, qui fonctionne correctement. Si votre fournisseur ne propose pas le 465, l'alternative est de passer par un service d'envoi transactionnel disposant d'un module dédié.

Si vos emails ont cessé de partir exactement au moment d'une montée en version 9, c'est la première piste à explorer.

Niveau 3 : l'authentification du domaine

Vos emails partent, mais n'arrivent pas. C'est un autre problème, et c'est aujourd'hui le plus courant.

Les fournisseurs de messagerie exigent trois enregistrements DNS :

• SPF : autorise le serveur qui expédie pour votre domaine. Attention à la limite de dix résolutions DNS, vite atteinte quand on cumule plusieurs services.
• DKIM : signe cryptographiquement les messages. Il se configure côté service d'envoi, qui fournit la clé publique à publier.
• DMARC : indique la conduite à tenir en cas d'échec des deux précédents. Commencez en politique none pour observer, puis durcissez.

Un domaine sans DKIM voit une part importante de ses messages classés en indésirable, sans aucune erreur côté serveur. Vérifiez l'état de vos enregistrements avec un outil de test, et lisez les en-têtes d'un message reçu : ils indiquent le résultat de chaque contrôle.

Niveau 4 : la file d'envoi et les logs

PrestaShop conserve un historique des messages envoyés :

SELECT recipient, subject, date_add FROM ps_mail ORDER BY date_add DESC LIMIT 20;

Si des lignes récentes apparaissent, PrestaShop a bien tenté l'envoi : le problème est en aval, côté serveur d'envoi ou réception. Si la table est vide, le problème est en amont, dans la configuration ou dans le déclenchement du hook.

Consultez également var/logs/ et le journal d'erreurs PHP de l'hébergeur. Une erreur de connexion SMTP y apparaît généralement en clair.

Cas particulier : les emails déclenchés par une tâche planifiée (relances, rapports) échouent parfois alors que les emails transactionnels fonctionnent. La cause est presque toujours la tâche planifiée elle-même, pas l'envoi. Voyez notre article sur les crons qui ne s'exécutent pas.

Le réglage recommandé

Pour une boutique en production, la fonction mail de PHP est à proscrire : elle expédie depuis l'IP mutualisée de l'hébergeur, dont la réputation ne dépend pas de vous.

La configuration robuste consiste à utiliser un service d'envoi transactionnel dédié, en SMTP authentifié, avec SPF et DKIM correctement publiés, et une surveillance du taux de délivrabilité. Le coût est marginal ; l'écart de fiabilité est considérable.

Vos clients ne reçoivent plus rien ?

Nous diagnostiquons la chaîne d'envoi complète, de la configuration PrestaShop à l'authentification du domaine. Diagnostic gratuit, réponse sous 1h — voir le dépannage PrestaShop.