PrestaShop n’envoie plus d’emails

Les problèmes d’emails représentent environ un ticket de support PrestaShop sur cinq. Et à chaque fois, le réflexe du marchand est le même : « PrestaShop est en panne. » La réalité est un peu plus nuancée. Dans 70 % des cas, PrestaShop a bien envoyé l’email et c’est après que ça coince.

Dans cet article, on va voir ensemble comment diagnostiquer un problème d’email sur PrestaShop en 5 minutes, quelles sont les 10 causes les plus fréquentes, et comment les résoudre une par une. Que vous soyez sur PrestaShop 1.6, 1.7, 8 ou 9.

⚠️ Ce qu’on ne traite PAS ici
Les problèmes de boîte mail (« je ne reçois plus rien sur Outlook », « mon Gmail est plein »). Ça, c’est un sujet d’hébergement ou de messagerie — Contactez votre hébergeur, Google Workspace ou Microsoft 365 selon votre cas

Si vous ne souhaitez dépanner directement votre boutique, utilisez ce simulateur pour être redirigé directement au bon endroit dans l’article et déboguer vos emails PrestaShop.

Quels emails passent réellement par PrestaShop ?

Avant de chercher pourquoi vos emails ne partent pas, il faut comprendre ce que PrestaShop envoie. Parce que la plupart des marchands pensent que PrestaShop gère « les emails ». En réalité, il gère des dizaines de types d’emails différents, déclenchés par des événements différents, via des modules différents. Et chacun peut casser indépendamment des autres.

Les emails côté client

Votre client reçoit (ou devrait recevoir) un email à chaque étape clé :

• création de compte ;
• confirmation de commande ;
• changement de statut (« en préparation », « expédié », « livré », « remboursé ») ;
• mot de passe oublié ;
• retour en stock d’un produit suivi.
• l’email de suivi de colis (envoyé quand vous renseignez un numéro de tracking et passez la commande en « Expédié ») ;
• l’email de confirmation d’inscription newsletter (le double opt-in exigé par le RGPD). Si ce dernier ne part pas, vos clients cliquent « S’inscrire », ne reçoivent rien, et abandonnent. Vous pensez que personne ne s’inscrit à votre newsletter et c’est l’email de confirmation qui est bloqué.

Ce qu’on voit chez nos clients : la confirmation de commande est de loin l’email le plus sensible. Si celui-là ne part pas, le client panique et vous aussi.

Les emails côté marchand

Vous, en tant que marchand, vous recevez aussi des emails :

• notification de nouvelle commande ;
• alerte rupture de stock ;
• messages du formulaire de contact ;
• messages privés sur une commande (quand vous ajoutez un commentaire visible par le client dans le détail d’une commande).

Tous ces emails passent par le module Mail Alerts (ps_emailalerts). Mon conseil : vérifiez que la case « Nouvelle commande » est cochée dans la configuration du module. On voit régulièrement des marchands qui ne reçoivent pas leurs propres notifications simplement parce que cette case n’a jamais été activée.

Les emails déclenchés par des modules tiers

Et puis il y a les modules :

• panier abandonné (ps_reminder) ;
• relance Brevo ;
• newsletter ;
• facture PDF envoyée en pièce jointe.

Chacun de ces modules a son propre système d’envoi et peut entrer en conflit avec la configuration email native de PrestaShop.

Au passage : ça vaut aussi le coup de préciser que certains modules de paiement (Stripe, PayPal) envoient leurs propres emails de confirmation en doublon de ceux de PrestaShop, ce qui peut faire croire à un bug alors que c’est juste deux systèmes qui tournent en parallèle.

Les emails programmés (cron)

C’est le flux qu’on oublie le plus souvent. Certains emails ne sont pas envoyés en temps réel. Ils sont déclenchés par une tâche cron (un programme qui tourne à intervalles réguliers sur votre serveur). C’est le cas :

• des relances panier abandonné (le module ps_reminder utilise cron.php) ;
• des newsletters en masse ;
• et de certaines relances marketing.

Le problème : si la tâche cron n’est pas configurée chez votre hébergeur, ces emails ne partent jamais et personne ne s’en aperçoit. Il n’y a aucune erreur visible dans PrestaShop.

Le module est installé, configuré, tout semble en place. Mais si le cron ne tourne pas, rien ne se passe.

Pour vérifier : demandez à votre hébergeur si des tâches cron sont actives sur votre compte, ou allez dans cPanel → Tâches Cron. Si la liste est vide et que vous utilisez un module de relance par exemple → voilà pourquoi vos relances panier ne partent pas.

L’email test

Paramètres avancés → E-mail → « Envoyer un e-mail de test ».

C’est votre premier outil de diagnostic. Mais attention, ce test peut réussir alors que les emails opérationnels ne partent pas. On y reviendra.

Au passage : si le test fonctionne mais que vos confirmations de commande ne partent pas, le problème n’est probablement pas votre configuration SMTP. C’est ailleurs, module mailalerts non coché, statut de commande sans envoi de mail activé, ou templates email manquants dans le dossier /mails/fr/.

Les 3 méthodes d’envoi d’emails PrestaShop

Dans le back-office, allez dans Paramètres avancés → E-mail. Vous y trouverez 3 options (plus une quatrième qu’on aimerait ne jamais voir) :

Méthode 1 (obsolète) : la fonction mail() de PHP

C’était le défaut sur les versions antérieures à PS 1.7.7. Simple : PrestaShop demande à PHP d’envoyer l’email directement depuis le serveur. Aucun identifiant à renseigner, ça marche « tout seul ».

Sauf que de plus en plus d’hébergeurs désactivent cette fonction pour des raisons de sécurité. Les spammeurs l’adorent.

Et quand elle fonctionne, les emails partent sans authentification, ce qui veut dire qu’ils arrivent souvent en spam. Ou pas du tout.

Méthode 2 (par défaut) : le mode sendmail (/usr/sbin/sendmail)

C’est le mode d’envoi par défaut depuis PrestaShop 1.7.7. Techniquement, il utilise le binaire sendmail du serveur pour envoyer les messages.

Ça fonctionne sur la plupart des hébergements Linux. Mais comme pour mail(), il n’y a pas d’authentification, le serveur envoie « en son nom » sans prouver qu’il a le droit de le faire.

Résultat : les filtres anti-spam se méfient.

Méthode 3 (recommandée) : SMTP est le plus fiable pour envoyer des emails PrestaShop

SMTP (Simple Mail Transfer Protocol), c’est l’option où vous renseignez un vrai serveur de messagerie, un identifiant, un mot de passe, un port et un type de chiffrement.

L’email transite par un compte email authentifié. C’est la seule méthode qui vous donne une chance sérieuse d’arriver dans la boîte de réception de vos clients.

Le problème : la configuration change selon chaque hébergeur. Et c’est là que les ennuis commencent (on en parle dans les causes d’erreur).

Ce que personne ne vous dit : l’envoi est synchrone

PrestaShop envoie les emails de manière synchrone, c’est-à-dire pendant le processus qui est en cours.

Exemple d’email synchrone
Quand votre client valide sa commande, PrestaShop envoie la confirmation d’email avant d’afficher la page de confirmation.

Si votre serveur SMTP met 3-5 secondes à répondre, le client attend sur une page blanche. Sur un SMTP saturé ou mal configuré, ça peut même provoquer un timeout et le client pense que sa commande n’est pas passée.

C’est l’une des raisons pour lesquelles les services d’envoi via API (comme Brevo) sont plus fiables : l’API répond instantanément, l’email est mis en file d’attente côté Brevo et envoyé en arrière-plan. Votre client n’attend pas.

Au passage, si votre boutique PrestaShop est lente au moment du paiement, un SMTP qui traîne peut en être la cause.

Quid de l’option « Ne jamais envoyer d’e-mails »

Oui, cette option existe. Elle est prévue pour les phases de test. Et oui, on la retrouve activée sur des boutiques en production.

Soit après une mise à jour qui a réinitialisé les paramètres, soit parce que quelqu’un l’a cochée pour « tester un truc » et a oublié de la remettre.

C’est la cause la plus bête au monde des problèmes d’envoi d’email sur PrestaShop et on la voit chaque mois.

Prérequis que tout le monde oublie avant d’envoyer des emails PrestaShop

Chez certains hébergeurs (OVH, Ionos), si vous n’avez pas créé d’adresse email dans votre espace d’hébergement, la fonction mail() ne se déclenchera même pas sur le serveur.

Il faut au minimum une boîte mail active sur le domaine. Même si vous ne l’utilisez pas pour lire vos emails.

SwiftMailer vs Symfony Mailer : ce qui change entre PS 8 et PS 9

PrestaShop 1.7 et 8 utilisent SwiftMailer pour envoyer les emails.

PrestaShop 9 est passé à Symfony Mailer (un composant plus moderne), mais qui a introduit des bugs de régression.

On en reparle dans les causes d’email (spoiler : le port 587 ne fonctionne plus sur PS 9).

Le diagnostic en 5 minutes

Vous avez un problème d’email ?

Avant d’appeler votre hébergeur, votre prestataire ou de poster sur un forum, faites ces 5 vérifications. Dans cet ordre. En 5 minutes, vous saurez où chercher.

Étape 1 : Vérifier les logs PrestaShop

Allez dans Paramètres avancés → E-mail. En haut de la page, vous avez la liste de tous les emails envoyés par PrestaShop : destinataire, modèle utilisé, langue, objet, heure d’envoi.

Si l’email apparaît dans cette liste → PrestaShop l’a bien envoyé. Le problème est en aval : délivrabilité, spam, DNS, hébergeur qui bloque.

Si l’email n’apparaît pas → le problème est dans PrestaShop lui-même : configuration, module, hook.

Ce qu’on voit chez nos clients : dans la majorité des cas, l’email est dans les logs. Le marchand pense que rien n’est parti — en fait, c’est le serveur destinataire qui a refusé ou filtré le message.

Étape 2 : Vérifier le réglage « Ne jamais envoyer »

Sur la même page, regardez quelle option est sélectionnée. Si c’est « Ne jamais envoyer d’e-mails » — voilà votre problème. Passez sur sendmail ou SMTP, sauvegardez, testez.

Oui, c’est basique. Oui, c’est la première chose à vérifier.

Étape 3 : Envoyer un email test

Toujours sur la même page, en bas : « Envoyer un e-mail de test à ». Entrez votre adresse, cliquez.

Si le test échoue avec un message d’erreur → votre configuration est incorrecte (méthode d’envoi, serveur SMTP, port, mot de passe, chiffrement). Direction la section « causes » pour identifier le problème.

Si le test réussit mais que les emails opérationnels ne partent pas → le problème est ailleurs. Vérifiez le module Mail Alerts (cause 6), les statuts de commande (certains n’ont pas l’envoi de mail activé), et les templates dans /mails/fr/.

Étape 4 : Tester la délivrabilité avec mail-tester.com

Allez sur mail-tester.com. Le site vous donne une adresse email temporaire. Copiez cette adresse et utilisez-la comme destinataire du test email PrestaShop. Puis retournez sur mail-tester et cliquez « Vérifiez le score ».

Vous obtenez une note sur 10 avec le détail :

• Est-ce que SPF est configuré ? DKIM ? DMARC ?
• Est-ce que votre IP est sur une liste noire ?
• Est-ce que le contenu déclenche un filtre anti-spam ?

C’est le test à faire avant tout le reste. Si votre score est en dessous de 5/10, inutile de chercher un bug dans PrestaShop — votre infrastructure email est mal configurée.

Étape 5 : Vérifier les enregistrements DNS (SPF/DKIM/DMARC)

Allez sur notre simulateur ci-dessous. Entrez votre nom de domaine. Vérifiez :

1. SPF : un enregistrement TXT qui liste les serveurs autorisés à envoyer des emails pour votre domaine. S’il est absent, les serveurs destinataires n’ont aucun moyen de vérifier que votre email est légitime.
2. DKIM : une signature cryptographique qui prouve que l’email n’a pas été modifié en transit. PrestaShop 8 a ajouté le support DKIM natif dans les paramètres email — mais il faut aussi configurer l’enregistrement DNS chez votre hébergeur.
3. DMARC : la politique qui dit aux serveurs destinataires quoi faire si SPF ou DKIM échouent. Depuis 2024, c’est obligatoire pour les expéditeurs en volume.

Si ces trois enregistrements sont absents → c’est très probablement votre problème principal. On en parle en détail dans la cause n°1.

Les 10 causes les plus fréquentes et comment les résoudre

On les a classées de la plus fréquente à la plus rare, en se basant sur nos tickets de support et sur tout ce qu’on a pu trouver dans les forums PrestaShop FR, EN, DE, ES et IT, sur GitHub, et dans les bases de connaissances des hébergeurs.

Sur les dépannages email qu’on réalise, la cause n°1 est l’absence de SPF/DKIM (environ 35 % des cas). La cause n°2 est une mauvaise configuration SMTP — souvent après un changement d’hébergeur ou une MAJ. Les « bugs absurdes » (cause 10) représentent moins de 5 % des cas, mais ils font perdre le plus de temps parce que personne ne pense à les chercher.

Chaque cause = un symptôme, une explication et une résolution.

Cause 1 : SPF, DKIM et DMARC absents ou mal configurés

Symptôme : Le test email fonctionne (ou semble fonctionner). Les emails apparaissent dans les logs PrestaShop. Mais vos clients ne les reçoivent pas ou les trouvent dans leurs spams.

Explication : Depuis février 2024, Gmail et Yahoo exigent que chaque email entrant soit authentifié par SPF, DKIM et, pour les expéditeurs en volume, DMARC. En novembre 2025, Gmail est passé au rejet permanent : les emails non conformes ne sont plus envoyés en spam — ils sont rejetés. Le client ne reçoit rien du tout. Pas d’erreur côté PrestaShop. Microsoft Outlook a suivi en mai 2025 avec le même comportement.

En 2026, 93 % des expéditeurs ont un enregistrement SPF. 90 % ont DKIM. Mais seulement 64 % ont DMARC. Si vous êtes dans le tiers qui n’a pas de DMARC, vos emails sont sur du temps emprunté.

Résolution : Connectez-vous à l’espace DNS de votre hébergeur (ou de votre registrar de domaine). Ajoutez ou vérifiez :

• SPF : un enregistrement TXT du type v=spf1 include:votre-hebergeur.fr ~all
• DKIM : un enregistrement TXT avec votre clé publique (votre hébergeur vous la fournit)
• DMARC : un enregistrement TXT du type v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr

Si vous utilisez un service d’envoi tiers comme Brevo, il faut ajouter leurs serveurs dans votre SPF et configurer le DKIM via leur interface. Chaque service fournit une documentation pas à pas.

Mon conseil : commencez par p=none pour DMARC (mode observation). Attendez 2-4 semaines pour voir les rapports. Puis passez progressivement à p=quarantine puis p=reject.

Cause 2 : Mauvaise configuration SMTP

Symptôme : Le message d’erreur « Erreur : veuillez vérifier votre configuration » s’affiche quand vous envoyez un email test. Ou bien le test fonctionne mais les emails opérationnels échouent silencieusement.

Explication : La configuration SMTP varie selon chaque hébergeur. Un port ou un type de chiffrement incorrect suffit à tout bloquer.

Résolution : Voici les paramètres SMTP par hébergeur qu’on utilise au quotidien :

Au passage : le piège classique sur Gmail, c’est que depuis 2024, les « mots de passe d’application moins sécurisés » n’existent plus. Il faut aller dans les paramètres de sécurité Google, activer la validation en 2 étapes, puis générer un mot de passe d’application de 16 caractères. C’est ce mot de passe qu’il faut mettre dans PrestaShop et pas votre mot de passe Gmail habituel.

Cause 3 : Le bug PrestaShop 9 : Symfony Mailer casse le port 587

Symptôme : Vous migrez de PS 8 à PS 9. Du jour au lendemain, vos emails ne partent plus. Le test affiche « succès » mais aucun email n’arrive. Ou bien : les emails internes (vers votre propre domaine) arrivent, mais les emails vers Gmail, Outlook ou Yahoo n’arrivent jamais.

Explication : PS 9 a remplacé SwiftMailer par Symfony Mailer. Le problème : le port 587 (TLS/STARTTLS) ne fonctionne plus correctement avec Symfony Mailer. C’est un bug de régression classé « Major » sur GitHub (issue #36663). Un second bug (issue #39171) fait que les emails vers des domaines externes ne sont jamais reçus malgré l’absence de message d’erreur.

Résolution : Passez du port 587 (TLS) au port 465 (SSL). Si votre hébergeur ne propose que le port 587, c’est plus compliqué. Vous devrez soit attendre le correctif PrestaShop, soit passer par un service d’envoi tiers (Brevo, Mailgun) qui contourne le problème en utilisant l’API au lieu du SMTP natif.

Ah si : si vous êtes sur PS 8 et que tout fonctionne, ne paniquez pas. Ce bug ne vous concerne pas. Mais gardez-le en tête le jour où vous migrerez vers PS 9.

Cause 4 : L’hébergeur bloque ou limite l’envoi

Symptôme : Les emails partent par vagues. Certains arrivent, d’autres non. Ou bien tout s’arrête du jour au lendemain sans que vous ayez touché à la configuration.

Explication : Chaque hébergeur a ses propres limites :

• o2switch : limitation à 30 emails par minute. Si vous changez le statut de 40 commandes en même temps, les 10 derniers emails ne partiront pas. Pas d’erreur dans PrestaShop.
• OVH mutualisé : un client à nous a envoyé 15 emails avec des pièces jointes lourdes. OVH a classé son compte comme « spam » et a bloqué tout le service email. Il a fallu contacter le support pour débloquer. Aucune notification côté marchand.
• Ionos mutualisé : la fonction SMTP n’est tout simplement pas disponible. Si vous essayez de configurer le SMTP avec les paramètres Ionos en mutualisé, ça ne marchera jamais. Solution : passer par un service tiers.
• Gmail : limite de 99 emails par jour. Pour un marchand à 100+ commandes quotidiennes, ça ne passe pas.
• WHM/cPanel : il existe une option « SMTP Restrictions » qui bloque les connexions SMTP sortantes pour tous les utilisateurs sauf root. Elle peut être activée sans que le marchand le sache. Tous les emails SMTP échouent silencieusement.

Résolution : Contactez votre hébergeur pour connaître vos limites d’envoi. Si vous êtes sur un hébergement mutualisé avec des restrictions fortes, la solution long terme est de passer par un service d’envoi dédié (on en parle plus bas). CYBERIAL propose également un service d’hébergement ultra performant et optimisé pour le CMS PrestaShop.

Cause 5 : Le module Contact Form n’est pas configuré

Symptôme : Le formulaire de contact fonctionne (le client voit « Votre message a bien été envoyé »). Mais vous ne recevez rien dans votre boîte mail. Les messages apparaissent uniquement dans le back-office, sous SAV → Service client.

Explication : Dans PrestaShop 1.7 et versions suivantes, le module Contact Form a une option « Recevoir les messages des clients par e-mail » qui est désactivée par défaut. Le marchand ne la voit pas. Il pense que le formulaire est cassé alors qu’il fonctionne et il manque juste la notification email.

Résolution : Back-office → Modules → Contact Form → Configurer. Activez « Recevoir les messages des clients par e-mail ». Sauvegardez. C’est tout.

Cause 6 : Le module Mail Alerts est mal configuré ou écrasé

Symptôme : Le client reçoit sa confirmation de commande mais vous, en tant que marchand, vous ne recevez rien. Ou l’inverse. Ou bien les confirmations de commande ne partent plus du tout alors que les autres emails (mot de passe oublié, création de compte) fonctionnent.

Explication : Le module ps_emailalerts (Mail Alerts) est responsable des notifications marchand. Cinq pièges fréquents :

1. La case « Nouvelle commande » n’est pas cochée dans la configuration du module.
2. Le module n’est pas rattaché au bon hook. Il doit être sur actionValidateOrder. Après une mise à jour ou une réinstallation du module, ce hook peut se détacher.
3. Les fichiers de templates email sont manquants dans /modules/mailalerts/mails/fr/. Si vous avez changé de thème ou fait une MAJ, ces fichiers peuvent avoir disparu.
4. La tâche cron n’est pas configurée. Si vous utilisez un module de relance panier abandonné (ps_reminder) ou de newsletter programmée, ces emails ne sont envoyés que si un cron tourne sur votre serveur. Sans cron → le module est installé mais ne fait rien. Zéro erreur visible.
5. Un override sur la classe Mail.php casse l’envoi. Certains thèmes premium ou modules font un override du fichier /classes/Mail.php pour personnaliser le comportement d’envoi. Si cet override est buggé ou incompatible avec votre version de PrestaShop → tous les emails transactionnels sont cassés. Le test email dans le back-office peut même continuer à fonctionner, parce que l’override ne s’applique qu’aux emails envoyés par les contrôleurs front. Après une MAJ, vérifiez le dossier /override/classes/ — si un fichier Mail.php y traîne et que vous ne savez pas d’où il vient, renommez-le en Mail.php.bak et testez.

Résolution : Modules → Module Manager → chercher « Mail Alerts » → Configurer. Vérifiez que « Nouvelle commande » est coché et que votre adresse email est renseignée. Si ça ne suffit pas : désinstallez le module puis réinstallez-le. La réinstallation le repositionne sur les bons hooks.

Au passage — si vous avez installé un module de panier abandonné (ps_reminder) ou un module Brevo qui envoie aussi des emails transactionnels, vérifiez qu’il n’y a pas de conflit. Deux modules qui essaient d’envoyer le même email en même temps, ça peut bloquer les deux.

Cause 7 : L’adresse FROM déclenche un rejet SPF

Symptôme : Les emails du formulaire de contact ne sont jamais reçus par le marchand. Ou bien ils arrivent en spam systématiquement.

Explication : Quand un client envoie un message via le formulaire de contact, PrestaShop utilise l’email du client (par exemple client@gmail.com) comme adresse FROM. Mais l’email est envoyé depuis votre serveur — pas depuis les serveurs de Gmail. Le serveur destinataire voit un email qui prétend venir de @gmail.com mais qui arrive d’un serveur inconnu → le contrôle SPF échoue → l’email est rejeté.

Résolution : L’adresse FROM doit toujours être une adresse de votre domaine (par exemple contact@votre-boutique.fr). L’email du client doit être en Reply-To, pas en FROM. Sur les versions récentes de PrestaShop, ce comportement est corrigé par défaut. Sur les versions plus anciennes (PS 1.6, début 1.7), il faut modifier le contrôleur ContactController.php via un override.

Cause 8 : PS_SHOP_EMAIL incohérent

Symptôme : Le test email échoue avec l’erreur « 554 5.5.1 Error: no valid recipients ». Ou bien le test réussit mais les emails opérationnels échouent.

Explication : PrestaShop utilise la valeur de PS_SHOP_EMAIL (l’email de la boutique) comme adresse FROM dans quasiment tous les emails envoyés. Le problème : cette valeur est stockée à 3 endroits différents, et ils peuvent être incohérents.

Quand le test email est lancé, PrestaShop utilise PS_SHOP_EMAIL comme FROM et comme TO. Si cette adresse ne correspond pas au compte SMTP configuré, certains serveurs refusent l’envoi.

Résolution : Vérifiez que la même adresse email est renseignée à ces 3 endroits :

1. Paramètres avancés → E-mail : l’identifiant SMTP
2. Paramètres de la boutique → Contact → onglet Contacts : l’adresse du contact principal
3. Paramètres de la boutique → Contact → onglet Coordonnées : l’email de la boutique

Si elles ne correspondent pas, corrigez. Au besoin, passez directement par la base de données : table ps_configuration, clé PS_SHOP_EMAIL.

Cause 9 : Une mise à jour qui réinitialise les paramètres

Symptôme : « Tout fonctionnait avant la mise à jour. » Les emails s’arrêtent du jour au lendemain après une MAJ de PrestaShop.

Explication : Plusieurs MAJ sont connues pour casser la configuration email :

• Passage à PS 1.7.7 : la méthode par défaut est passée de mail() à sendmail. Les marchands qui comptaient sur mail() se retrouvent sans rien.
• PS 1.7.8.2 : bug signalé sur le forum allemand PrestaShop. Les paramètres SMTP ne se sauvegardent plus après la MAJ. Le marchand configure, sauvegarde, et la prochaine fois qu’il ouvre la page, tout est revenu aux valeurs par défaut.
• PS 8 → PS 9 : migration de SwiftMailer vers Symfony Mailer. Le port 587 casse (voir cause 3). Les emails vers des domaines externes ne sont plus reçus.

Résolution : Après chaque mise à jour de PrestaShop, vérifiez systématiquement vos paramètres email. C’est une étape qui devrait faire partie de votre checklist post-MAJ. Envoyez un email test. Vérifiez les logs. Si le test échoue, reconfigurez le SMTP manuellement.

Mon conseil : avant toute MAJ, faites une capture d’écran de vos paramètres email. Ça prend 10 secondes et ça peut vous épargner des heures de recherche.

Cause 10 : Les bugs absurdes mais bien réels

Symptôme : Tout semble correct — SMTP configuré, test qui échoue malgré tout, aucune erreur compréhensible.

Explication et résolution : On garde le meilleur pour la fin. Ces bugs sont rares, mais documentés :

• Le nom de la boutique contient « : » (deux-points) → bloque l’envoi de tous les emails. Supprimez les deux-points dans Paramètres de la boutique → Coordonnées.
• Le nom de la boutique est en MAJUSCULES → même effet sur certaines versions. Passez en casse normale.
• Sendmail en mode -bs (SMTP interactif) → provoque des hang-ups et des temps de chargement infinis sur les serveurs à ressources limitées. Solution : modifier le fichier /vendor/swiftmailer/swiftmailer/lib/classes/Swift/SendmailTransport.php et remplacer -bs par -t.
• IP blacklistée sur UCEPROTECT → vos emails n’arrivent plus chez les FAI italiens (Libero, Virgilio, Alice) et parfois chez d’autres. Ce n’est même pas forcément votre IP qui est blacklistée — c’est un autre IP de la même classe. Vérifiez sur mxtoolbox.com → Blacklist Check. Si votre IP est listée, contactez votre hébergeur pour un changement d’IP ou passez par un service d’envoi tiers.
• WHM « SMTP Restrictions » activé sans le savoir → bloque toutes les connexions SMTP sortantes sauf root. Si vous êtes sur un serveur dédié ou VPS avec WHM, vérifiez dans WHM → SMTP Restrictions.
• Erreur UTF-8 SwiftMailer sur Windows → « Malformed UTF-8 characters, possibly incorrectly encoded ». Bug connu sur PS 1.7.7+ avec certains environnements de dev Windows. En production sur Linux, ça ne se produit normalement pas.

La solution définitive pour envoyer 100% de ses emails PrestaShop

On va être directs : le SMTP de votre hébergeur, ça dépanne. Mais ce n’est pas une solution long terme.

Pourquoi ? Parce que votre hébergeur partage son IP entre des dizaines (voire des centaines) de clients. Si l’un d’eux envoie du spam, l’IP est blacklistée et vos emails avec.

Ajoutez à ça les limites d’envoi (30 emails par minute chez o2switch, 99 par jour chez Gmail), l’absence de statistiques, l’absence de tracking ouvertures par rapport aux clics et vous comprenez pourquoi les boutiques sérieuses finissent toutes par migrer vers un service dédié.

Brevo (ex-Sendinblue) : la recommandation la plus directe

Module gratuit sur PrestaShop Addons. Compatible PS 1.7.1 à 9.0. Multiboutique supporté. L’envoi passe par l’API Brevo, pas par le SMTP natif de PrestaShop, ce qui contourne la plupart des problèmes qu’on a listés dans cet article.

Ce que ça change concrètement :

• Vos emails transactionnels (confirmation de commande, expédition, etc.) passent par les serveurs de Brevo, qui ont une réputation d’IP propre et des enregistrements SPF/DKIM préconfigurés.
• Vous avez un historique avec le détail des ouvertures et des clics — donc vous savez immédiatement si un email a été reçu.
• L’envoi est asynchrone — l’API de Brevo répond instantanément, l’email est mis en file d’attente et envoyé en arrière-plan. Vos clients n’attendent plus 3-5 secondes sur la page de confirmation de commande parce que le SMTP traîne. C’est un gain de performance direct sur votre tunnel de commande.
• Le module gère aussi les SMS, le marketing automation et la récupération de panier abandonné — si vous voulez aller plus loin.

Le plan gratuit inclut 300 emails par jour. Pour la plupart des boutiques PrestaShop, c’est largement suffisant pour les emails transactionnels.

Les alternatives

• Mailgun : plus technique, orienté développeurs. API puissante, logs détaillés.
• Mailjet : alternative française à Brevo. Plugin PrestaShop disponible. Bon compromis entre simplicité et fonctionnalités.
• Amazon SES : le moins cher en volume (environ 0,10 $ pour 1 000 emails). Mais la configuration est plus technique.
• Postmark : spécialisé dans l’email transactionnel. Le plus fiable pour les confirmations de commande. Pas de marketing.

Le piège à éviter

Si vous installez Brevo (ou tout autre service d’envoi) et que vous laissez le SMTP natif activé dans PrestaShop, vous risquez des doublons : certains emails partiront par les deux canaux, d’autres par aucun. Règle simple : un seul système d’envoi à la fois. Quand Brevo est actif, il prend le relais sur tous les emails transactionnels.

Et ne cherchez pas; PrestaShop ne permet toujours pas de configurer un SMTP différent par boutique en multi boutique. Toutes les boutiques envoient depuis le même compte. Si vos boutiques ont des domaines différents, ça crée des problèmes d’authentification SPF. Un service comme Brevo, qui gère l’authentification par domaine de manière centralisée, résout ce problème.

Les règles de Google, Yahoo et Microsoft depuis 2024

Ce sujet est traité partout dans l’univers email marketing. Mais personne ne l’explique dans le contexte PrestaShop. C’est pourtant là qu’il a le plus d’impact — parce que les marchands PrestaShop envoient des emails transactionnels sans même savoir que des règles existent.

La chronologie

• Février 2024 : Google et Yahoo annoncent conjointement que tous les expéditeurs doivent authentifier leurs emails avec SPF et DKIM. Les expéditeurs en volume (5 000+ emails/jour) doivent aussi avoir DMARC. Gmail commence à retarder les emails non conformes (erreurs temporaires 4xx).
• Novembre 2025 : Gmail passe au rejet permanent. Les emails non conformes reçoivent un code d’erreur 5xx — plus de seconde chance, plus de dossier spam. L’email rebondit.
• Mai 2025 : Microsoft suit avec la même politique pour Outlook, Hotmail et Live.com. Rejet SMTP immédiat (code 550 5.7.515). Pas de période de grâce.

Ce que ça signifie pour un marchand PrestaShop

Si vos clients utilisent Gmail (72 % des consommateurs selon Mailgun) ou Outlook, et que votre domaine n’a pas de DMARC, vos confirmations de commande sont rejetées. Pas en spam. Rejetées. Le client ne reçoit rien. Et PrestaShop ne vous affiche aucune erreur — parce que de son côté, l’email a bien été « envoyé ».

Le seuil de spam chez Google est fixé à 0,3 %. Ça veut dire que si 3 de vos clients sur 1 000 cliquent « Signaler comme spam » sur vos emails, vous êtes à la limite. Au-delà, Gmail commence à bloquer vos messages même s’ils sont authentifiés.

Les chiffres 2026 à retenir

• SPF : 93 % d’adoption (bien)
• DKIM : 90 % (bien)
• DMARC : seulement 64 % (un tiers des expéditeurs n’ont toujours pas de politique DMARC)
• Taux d’inbox global : 65 % — un email sur trois n’atteint jamais la boîte de réception
• 48 % des marketeurs citent le dossier spam comme leur plus grand défi

Mon conseil : ne vous dites pas « je ne suis pas un expéditeur en volume, ça ne me concerne pas ». En 2026, les règles d’authentification s’appliquent à tous les expéditeurs, quelle que soit leur taille. Google et Microsoft rejettent les emails non authentifiés même pour les petits volumes.

Les questions fréquentes sur les problèmes d’email PrestaShop

Comment éviter les erreurs de mail PrestaShop à l’avenir ?

Si vous êtes arrivé jusqu’ici, c’est que vos emails ne partaient plus — et vous avez trouvé pourquoi. Maintenant, l’idée c’est que ça ne se reproduise pas. Voici ce qu’on recommande systématiquement à nos clients :

1. Passez par un service d’envoi dédié (Brevo, Mailgun, Mailjet). C’est le geste le plus impactant. Vous éliminez d’un coup les problèmes de SMTP hébergeur, de limites d’envoi et de réputation d’IP.
2. Configurez SPF, DKIM et DMARC sur votre domaine. C’est obligatoire depuis 2024 pour atteindre les boîtes Gmail et Outlook. Une fois en place, vous n’y touchez plus — c’est réglé.
3. Vérifiez vos paramètres email après chaque mise à jour PrestaShop. C’est la source de pannes la plus facile à éviter — et la plus souvent ignorée. Un email test après chaque MAJ, ça prend 30 secondes.
4. Testez votre délivrabilité régulièrement avec mail-tester.com. On recommande un test par mois — ou après tout changement de configuration serveur.
5. Surveillez votre boutique. Si vos emails s’arrêtent un samedi soir, est-ce que quelqu’un s’en rend compte avant lundi matin ? C’est exactement ce que fait un contrat de maintenance PrestaShop — surveillance 24/7, alertes automatiques, intervention rapide.

Au passage : les problèmes d’emails peuvent aussi être un symptôme de piratage PrestaShop. Un skimmer peut modifier vos templates email pour rediriger les confirmations de commande vers de fausses pages de paiement. Si vos emails changent d’apparence sans raison, vérifiez l’intégrité de vos fichiers.

Récapitulatif de la résolution d’un problème d’email sur PrestaShop