PrestaShop n’envoie plus d’emails

Quand les e-mails d’une boutique s’arrêtent, le marchand pense d’abord : « PrestaShop est en panne. » Très souvent, c’est faux : PrestaShop a bien envoyé l’e-mail, 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

Pour dépanner vous-même votre boutique, ce simulateur vous envoie directement au bon endroit de l’article.

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 un service d’envoi spécialisé (comme Brevo) est plus fiable : il accepte le message vite, le met en file d’attente et l’envoie en arrière-plan.

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). Cherchez le message dans l’index des messages d’erreur SMTP, puis dans les causes.

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.

Pour ne pas toucher vous-même aux réglages, confiez la panne à notre service de dépannage PrestaShop : dès 150 € HT, prix fixe validé avant toute intervention, 7j/7 de 8 h à 22 h.

Sur les dépannages e-mail qu’on réalise, on retrouve surtout deux causes : l’absence de SPF ou de DKIM, et une mauvaise configuration SMTP, souvent après un changement d’hébergeur ou une mise à jour. Les « bugs absurdes » (cause 10) sont rares, mais ce sont eux qui 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.

Parmi les expéditeurs testés par l’outil Unspam en 2026, 93 % ont un enregistrement SPF et 90 % ont DKIM, mais seulement 48 % ont DMARC. Si votre domaine fait partie de l’autre moitié, vos e-mails sont en sursis.

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:[email protected]

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. Si un service comme Brevo envoie pour vous, lisez d’abord la section DMARC : aligner DKIM avant de durcir la politique.

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 :

Ce tableau vaut pour PrestaShop 1.6, 1.7 et 8. En 9, la liste « Chiffrement » ne propose plus « SSL » : sur le port 465, choisissez « TLS ». En 9.0 et 9.1, « TLS » échoue sur le port 587 : passez au 465, ou, chez Microsoft 365 qui refuse le 465, choisissez « Aucun ». Détails dans le tableau de l’entrée TLS.

Au passage : le piège classique sur Gmail, c’est que Google n’accepte plus la connexion avec le seul mot de passe du compte (l’ancien accès des « applications moins sécurisées »). 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. 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 échoue avec Connection could not be established with host "ssl://…:587". Ou le test affiche « succès » mais aucun e-mail 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 : En 9.0 et 9.1, passez au port 465 en gardant « TLS » (la 9 ne propose plus de choix SSL). Si votre fournisseur n’accepte que le port 587, comme Microsoft 365, choisissez « Aucun » dans « Chiffrement » : Symfony Mailer passe alors de lui-même en STARTTLS si le serveur le propose. Ne le faites que chez un fournisseur qui exige le chiffrement, sinon le mot de passe peut circuler en clair. La 9.2 corrige le problème : « TLS » y fonctionne sur 587 comme sur 465. Détails dans l’index des messages.

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 : pas de limite en usage normal, mais au plus 20 000 envois par jour par un mécanisme automatisé, d’après ses CGV. Chez OVH, une adresse MX Plan est limitée à environ 200 e-mails par heure, et à 300 par heure et par adresse IP, partagée avec les autres sites en mutualisé (documentation OVHcloud).
• 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é : selon l’offre, l’envoi depuis l’hébergement peut être restreint. Si la connexion à smtp.ionos.fr échoue avec les bons paramètres, demandez à Ionos ce que permet votre offre, ou passez par un service d’envoi.
• Gmail : 500 e-mails par jour pour un compte gratuit, 2 000 pour Google Workspace (limites publiées par Google). Une boutique qui envoie plusieurs e-mails par commande atteint vite le plafond.
• 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. Si c’est le client qui ne reçoit pas sa confirmation, ce module n’y est pour rien : PrestaShop l’envoie lui-même, voyez plutôt la question « le test fonctionne mais mes clients ne reçoivent pas la confirmation » et la cause 1.

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 [email protected]) 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 [email protected]). 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 e-mail est lancé, PrestaShop utilise PS_SHOP_EMAIL comme expéditeur. Le destinataire est l’adresse saisie dans « Envoyer un e-mail test à ». Si l’adresse de la boutique (PS_SHOP_EMAIL) ne correspond pas au compte SMTP configuré, certains serveurs refusent l’envoi (voir l’entrée 5.7.60 de l’index).

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 → Magasins, bloc « Coordonnées » (Préférences → Coordonnées & magasins en 1.6) : l’adresse e-mail de la boutique

Si elles ne correspondent pas, corrigez-les depuis le back-office. Ne modifiez pas la base de données vous-même.

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.

Index des messages d’erreur SMTP de PrestaShop

Quand un e-mail ne part pas en SMTP, PrestaShop (1.6, 1.7, 8 ou 9) laisse presque toujours une trace écrite. Elle tient en deux morceaux : une phrase de PrestaShop, puis la réponse brute du serveur SMTP, en anglais. C’est le second morceau qui donne la cause. Voici où le lire.

• Au bouton de test. Paramètres avancés > E-mail (« Emails » ou « Email » en 1.6, selon le pack de langue), bloc « Testez votre configuration e-mail » : saisissez une adresse dans « Envoyer un e-mail test à », puis cliquez sur « Envoyer un e-mail test ». L’erreur s’affiche sous le bouton. Le test part avec les valeurs affichées à l’écran, même si vous ne les avez pas encore enregistrées.
• Pour un vrai e-mail (commande, mot de passe oublié) : Paramètres avancés > Logs (« Log » ou « Logs » en 1.6). Les échecs y sont notés avec le préfixe Swift Error: en 1.6, 1.7 et 8, ou Mailer Error: en 9. La liste des e-mails de la page E-mail ne garde que les messages acceptés par le serveur : un échec n’y apparaît jamais. Dans les Logs, « Erreur – Le modèle d’e-mail suivant n’existe pas » n’est pas une panne SMTP : il manque le modèle de cet e-mail dans la langue du client (en 1.6, le message dit « Le template d’e-mail suivant n’existe pas »), par exemple après l’ajout d’une langue ou un changement de thème.

Avant de changer un réglage, faites une capture d’écran du bloc SMTP : c’est votre retour arrière. Le champ « Mot de passe SMTP » s’affiche toujours vide. Laissé vide, il garde le mot de passe déjà enregistré. Si vous le remplacez, gardez l’ancien à portée de main (espace client du fournisseur, gestionnaire de mots de passe) : la capture ne le montre pas. Ce mot de passe ne se communique à personne, nous compris : on n’en a pas besoin pour lire un message d’erreur.

Repérez ensuite le code à trois chiffres et son complément (550 5.7.60, 535 5.7.8…) et cherchez-le ci-dessous. Sauf mention contraire, ces messages n’existent qu’en anglais.

• Une erreur est survenue. Veuillez vérifier les votre configuration. (bouton de test)
• 550 5.7.60 SMTP; Client does not have permissions to send as this sender (Microsoft 365)
• Relay access denied, Unable to relay : le relai n’est pas autorisé
• 535 5.7.8 Username and Password not accepted (Gmail)
• 535 5.7.3 Authentication unsuccessful (Microsoft 365)
• 535 5.7.8 Authentication failed (Brevo, Mailjet)
• Connection could not be established with host
• Unable to connect with TLS encryption, Unable to connect with STARTTLS
• Expected response code 250 but got code (530 5.7.0 STARTTLS, 550 5.7.26, 553, 554…)

Une erreur est survenue. Veuillez vérifier les votre configuration.

Où il s’affiche. Sous le bouton « Envoyer un e-mail test », en PrestaShop 8 et 9, coquille d’origine comprise. En anglais : An error has occurred. Please check your configuration. En 1.6 et 1.7, la phrase est « Erreur : veuillez vérifier votre configuration » (Error: Please check your configuration). Quand tout va bien, vous lisez « Un e-mail de test a été envoyé à l’adresse e-mail que vous avez fournie. »

Ce que ça veut dire. Rien de précis : PrestaShop signale seulement que sa bibliothèque d’envoi a renvoyé une erreur (SwiftMailer jusqu’à la 8, Symfony Mailer en 9). La cause est presque toujours dans la ligne en anglais juste en dessous. L’expéditeur du test est toujours l’« Adresse e-mail de la boutique », et non l’« Utilisateur SMTP ».

Vérifier sans risque. Le test n’envoie qu’un message et n’enregistre rien. Envoyez-le à une adresse que vous lisez, chez un autre fournisseur que celui de la boutique (une adresse Gmail si la boutique envoie par OVH, par exemple). Pour annuler : rien à annuler tant que vous n’avez pas cliqué sur « Enregistrer ».

Arrêtez-vous si la phrase s’affiche seule, sans ligne en anglais : le serveur a probablement refusé le destinataire. Faites les deux tests décrits dans l’entrée relai, puis regardez Paramètres avancés > Logs ; si rien n’y figure, passez la main. Si le test réussit mais que vos clients ne reçoivent rien, le SMTP n’est plus en cause : voyez la question « le test fonctionne mais mes clients ne reçoivent pas la confirmation » et la cause 1. Si ce sont vos alertes de nouvelle commande qui manquent, voyez les réglages de Mail Alerts et les effets d’une mise à jour.

550 5.7.60 SMTP; Client does not have permissions to send as this sender

Où il s’affiche. Avec Microsoft 365 (Exchange Online), à l’intérieur d’une ligne Expected response code 250 but got code "550", with message "…". Microsoft donne le texte sous la forme « 5.7.60 SMTP; Client does not have permissions to send as this sender ». Le 550 placé devant est le code SMTP d’un refus définitif. Selon Microsoft, le refus peut aussi revenir plus tard, sous forme de message de non-remise (NDR).

Ce que ça veut dire. Microsoft a accepté votre identifiant, mais refuse l’expéditeur. La boîte connectée (l’« Utilisateur SMTP ») n’a pas le droit d’envoyer au nom de l’adresse qui figure en « De ». Dans PrestaShop, cette adresse est l’« Adresse e-mail de la boutique ». Cas typique : la boutique écrit au nom de contact@, mais le SMTP est connecté avec une autre boîte, ou l’adresse de la boutique a changé sans que personne ne touche au SMTP.

Où régler. L’« Utilisateur SMTP » est dans Paramètres avancés > E-mail. L’« Adresse e-mail de la boutique » est dans Paramètres de la boutique > Contact > Magasins, bloc « Coordonnées » (1.7, 8 et 9), ou dans Préférences > Coordonnées & magasins (1.6). Les deux doivent désigner la même boîte. Changez de préférence l’« Utilisateur SMTP » : l’adresse de la boutique est l’expéditeur que voient vos clients, elle doit rester sur votre domaine. Saisissez alors aussi le mot de passe de cette boîte (laissé vide, le champ garde celui de l’ancienne), et vérifiez que le SMTP authentifié y est activé (voir l’entrée 535 5.7.3). L’autre solution : l’administrateur Microsoft 365 donne à la boîte connectée le droit d’envoyer en tant que cette adresse (« Send As »).

Vérifier sans risque. Comparez les deux champs, alignez-les, puis relancez le test : il part justement avec l’adresse de la boutique. Pour annuler : remettez l’adresse de votre capture. Arrêtez-vous si la boutique doit écrire depuis une boîte partagée ou un alias : ces droits se règlent dans Microsoft 365, par son administrateur. Le même décalage d’adresses provoque d’autres refus, détaillés dans la cause 8.

Relay access denied ou Unable to relay : le relai n’est pas autorisé

Où il s’affiche. Le texte dépend du serveur. Postfix, un logiciel de messagerie très répandu, répond 554 5.7.1 <adresse>: Relay access denied. Exchange répond 550 5.7.1 Unable to relay, et Microsoft 365 peut aussi répondre 5.7.57 Client not authenticated to send mail. Ces textes ne s’affichent tels quels qu’en PrestaShop 9. En 1.7 et 8, SwiftMailer met de côté le refus du destinataire : avec Postfix, vous lisez à la place Expected response code 354 but got code "554", with message "554 5.5.1 Error: no valid recipients". En 1.6, et en 1.7 ou 8 avec certains serveurs, la phrase de PrestaShop s’affiche seule, sans ligne en anglais.

Le message en français. La phrase « le destinataire a été rejeté par le serveur car le relai n’est pas autorisé » ne vient pas de PrestaShop : d’après les utilisateurs qui la signalent, c’est l’app Mail d’Apple (iPhone, Mac) qui l’affiche. La cause est la même : le serveur d’envoi attend une identification. Le réglage se fait alors dans le compte configuré dans Mail (serveur d’envoi, utilisateur, mot de passe), pas dans PrestaShop.

Ce que ça veut dire. Le serveur a accepté la connexion, mais il refuse de faire suivre le message vers une adresse extérieure, parce que vous ne vous êtes pas identifié. Deux causes reviennent : « Utilisateur SMTP » et « Mot de passe SMTP » laissés vides (l’aide de PrestaShop dit « Laisser blanc si non applicable. »), ou un « Serveur SMTP » qui est le serveur de réception du domaine (son MX) au lieu du serveur d’envoi.

Où régler. Paramètres avancés > E-mail, option « Utiliser mes propres paramètres SMTP (pour les experts uniquement) ». Dans « Serveur SMTP », mettez le serveur d’envoi indiqué par votre fournisseur (par exemple ssl0.ovh.net pour une adresse OVH MX Plan, smtp.office365.com, smtp.gmail.com, smtp-relay.brevo.com ou in-v3.mailjet.com), remplissez l’utilisateur et le mot de passe, utilisez le port 587 ou 465 plutôt que 25, et choisissez le chiffrement indiqué dans le tableau de l’entrée TLS. Ne laissez pas « Aucun », la valeur par défaut : de la 1.6 à la 8, votre mot de passe partirait en clair.

Vérifier sans risque. Faites deux tests : l’un vers une adresse de votre propre domaine, l’autre vers une adresse Gmail. Si seul le premier passe, c’est bien un refus de relais. Pour annuler : revenez aux valeurs de votre capture. Arrêtez-vous si le serveur est celui de votre hébergeur et qu’il refuse encore une fois identifié : l’envoi depuis ce serveur n’est peut-être pas autorisé pour votre offre. Posez la question à l’hébergeur.

535 5.7.8 Username and Password not accepted (Gmail)

Où il s’affiche. Avec Gmail ou Google Workspace (smtp.gmail.com). PrestaShop l’emballe dans Failed to authenticate on SMTP server with username "…", suivi de la réponse de Google. En 1.6, la ligne s’arrête à « … possible authenticators », sans la réponse du serveur : choisissez alors l’entrée d’après votre « Serveur SMTP » (celle-ci pour Gmail, les suivantes pour Microsoft 365, Brevo et Mailjet). Google range ce refus sous le code 535 (son tableau d’aide écrit 5.7.80, le serveur répond 5.7.8, le code normalisé). Variante : code 534 avec Application-specific password required.

Ce que ça veut dire. Google refuse l’identifiant ou le mot de passe. Cause la plus courante : le mot de passe habituel du compte Google, alors qu’il faut un mot de passe d’application. Ce code généré par Google n’existe que si la validation en deux étapes est activée sur le compte. Autre limite à connaître : 500 e-mails par jour pour un compte Gmail gratuit, 2 000 pour Google Workspace. Au-delà, Google répond Daily user sending limit exceeded.

Où régler. Paramètres avancés > E-mail : « Utilisateur SMTP » = l’adresse Gmail complète, « Mot de passe SMTP » = le mot de passe d’application, « Serveur SMTP » = smtp.gmail.com. De la 1.6 à la 8 : port 587 avec « TLS », ou 465 avec « SSL ». En 9, la liste « Chiffrement » ne propose plus SSL : prenez 465 avec « TLS ».

Vérifier sans risque. Créez le mot de passe d’application, collez-le dans « Mot de passe SMTP » et relancez le test avant d’enregistrer. Pour annuler : remettez les valeurs de votre capture. Si vous renoncez à Gmail, supprimez aussi ce mot de passe d’application dans votre compte Google : il cesse aussitôt de fonctionner. Arrêtez-vous si l’option des mots de passe d’application n’apparaît pas. Elle manque si la validation en deux étapes ne repose que sur des clés de sécurité, si le compte est sous Protection avancée, ou si vous êtes connecté avec un compte professionnel, scolaire ou d’une organisation (Google Workspace par exemple).

535 5.7.3 Authentication unsuccessful (Microsoft 365)

Où il s’affiche. Avec Microsoft 365 (smtp.office365.com), dans la même ligne Failed to authenticate on SMTP server with username "…". Variantes : des messages qui commencent par 535 5.7.139 Authentication unsuccessful, suivis d’une raison, ou 5.7.57 Client not authenticated to send mail.

Ce que ça veut dire. Microsoft refuse l’identification, et le mot de passe n’est pas toujours en cause. L’envoi authentifié (SMTP AUTH) est désactivé sur les organisations créées après janvier 2020, sauf s’il est réactivé boîte par boîte. Les paramètres de sécurité par défaut de Microsoft Entra le bloquent aussi. Si la boîte est protégée par l’ancienne authentification multifacteur « par utilisateur », il lui faut un mot de passe d’application, une option que l’administrateur doit d’abord autoriser.

À noter dans votre agenda : Microsoft désactivera par défaut l’identification par mot de passe en SMTP AUTH fin décembre 2026 (l’administrateur pourra encore la réactiver) et annoncera au second semestre 2027 la date de sa suppression définitive. Le formulaire SMTP de PrestaShop ne connaît que l’identifiant et le mot de passe. Après la suppression, Microsoft répondra 550 5.7.30 Basic authentication is not supported for Client Submission et il faudra passer par un service d’envoi. Mieux vaut prévoir la bascule avant fin décembre, plutôt qu’au premier e-mail refusé.

Où régler. Paramètres avancés > E-mail : smtp.office365.com, port 587 (Microsoft n’accepte pas le 465 pour cet usage et exige TLS 1.2 ou plus). De la 1.6 à la 8, « Chiffrement » sur « TLS ». En 9.0 et 9.1, « TLS » ne marche pas sur le port 587 (voir l’entrée TLS) : choisissez « Aucun ». La connexion passe quand même en chiffré, car Symfony Mailer active STARTTLS de lui-même quand le serveur le propose, et Microsoft l’exige. En 9.2, « TLS » fonctionne. Microsoft limite cet envoi à 30 messages par minute.

Vérifier sans risque. Demandez à l’administrateur Microsoft 365 si le SMTP authentifié est activé pour la boîte utilisée (fiche de l’utilisateur, onglet Courrier, gestion des applications de messagerie). Pour annuler : cette case se décoche comme elle se coche. Arrêtez-vous si la seule solution proposée est de couper les paramètres de sécurité par défaut, ou de retirer l’authentification multifacteur de la boîte : Microsoft déconseille de couper ces paramètres sans en mesurer les conséquences, et la coupure vaut pour tous les comptes de l’organisation. Passez plutôt par un service d’envoi dont le domaine est authentifié.

535 5.7.8 Authentication failed (Brevo, Mailjet)

Où il s’affiche. Avec le relais SMTP de Brevo (smtp-relay.brevo.com), dans la ligne Failed to authenticate on SMTP server with username "…". Chez Mailjet, la même panne s’écrit 4.7.8: Error: authentication failed. Le code 535 5.7.8 signifie, selon la norme, « Authentication credentials invalid » : identifiants refusés.

Ce que ça veut dire. Ces services n’utilisent pas le mot de passe de votre compte. Chez Brevo, l’utilisateur est le « login SMTP » (selon l’ancienneté du compte, votre adresse de connexion ou une adresse en @smtp-brevo.com) et le mot de passe est une clé SMTP, pas une clé API. Elle ne s’affiche qu’une fois, et Brevo la désactive après 90 jours sans envoi réussi. Chez Mailjet, l’utilisateur est la clé API et le mot de passe la clé secrète.

Où régler. « Utilisateur SMTP » et « Mot de passe SMTP » dans Paramètres avancés > E-mail. Brevo : port 465 avec « SSL » (1.6 à 8) ou « TLS » (9), comme l’indique Brevo pour une connexion chiffrée. Mailjet (in-v3.mailjet.com) : 587 avec « TLS » ou 465 avec « SSL » ; en 9.0 et 9.1, prenez 465 avec « TLS ». L’expéditeur, l’« Adresse e-mail de la boutique », doit être validé dans le compte Brevo ou Mailjet.

Avec un module d’envoi. Le module Mailjet, réglé pour envoyer tous les e-mails, remplit lui-même les champs SMTP de PrestaShop et remplace l’« Adresse e-mail de la boutique » par l’adresse enregistrée dans le module : corrigez les clés et l’expéditeur dans le module, pas dans Paramètres avancés > E-mail. Avec ce module, « Wrong API Key » peut aussi signaler un expéditeur non validé. Avec un autre module d’envoi, vérifiez de même qui pilote l’envoi : un seul système à la fois (voir le piège à éviter).

Vérifier sans risque. Créez une nouvelle clé, collez-la et relancez le test avant d’enregistrer. Pour annuler : chez Brevo, l’ancienne clé reste utilisable tant que vous ne la supprimez pas et qu’elle n’a pas été désactivée après 90 jours sans envoi ; remettez-la à sa place. Arrêtez-vous si Brevo répond 525 5.7.1 Unauthorized IP address : le blocage des adresses IP inconnues est activé sur votre compte, et l’IP du serveur doit y être autorisée par la personne qui gère le compte.

Connection could not be established with host ou Could not connect to SMTP host

Où il s’affiche. La première forme est celle de PrestaShop, de la 1.6 à la 9, suivie du nom du serveur et de la raison donnée par PHP. La seconde (SMTP Error: Could not connect to SMTP host., en français « Erreur SMTP : impossible de se connecter au serveur SMTP. ») vient de la bibliothèque PHPMailer : vous la verrez avec un module d’envoi tiers qui l’utilise, pas avec le SMTP de PrestaShop.

Ce que ça veut dire. La boutique n’a même pas réussi à joindre le serveur. Lisez la fin de la ligne :

• Connection refused : le port est fermé ;
• Connection timed out (ou Timed Out) : quelque chose bloque en chemin, par exemple un pare-feu ou un hébergeur qui filtre les sorties SMTP ;
• getaddrinfo failed (ou getaddrinfo for … failed depuis PHP 8.1) : le nom du serveur est mal écrit ou n’existe pas ;
• SSL operation failed : cette fois, le serveur a bien répondu, mais le chiffrement choisi ne va pas avec le port. C’est le cas de « TLS » sur le port 587 en 9.0 et 9.1 (l’adresse du serveur commence alors par ssl://), ou de « SSL » sur le port 587 en 1.7 et 8 (en 1.6, la ligne se termine seulement par [ #0]) : voyez l’entrée TLS.

Où régler. « Serveur SMTP » et « Port », dans Paramètres avancés > E-mail. Recopiez le nom du serveur depuis la documentation du fournisseur, sans https:// ni espace. Les ports d’envoi standard sont 587 et 465. Brevo propose aussi le 2525 quand le 587 est bloqué, Mailjet le 2525 et le 80. Pour le chiffrement, traitez le 2525 comme le 587.

Vérifier sans risque. Essayez l’autre port standard du même fournisseur (587 ou 465), avec le chiffrement indiqué pour votre version dans le tableau de l’entrée TLS. Pour annuler : remettez les valeurs de votre capture. Arrêtez-vous si les deux ports aboutissent à un timed out : les connexions sortantes du serveur sont probablement filtrées. Demandez à votre hébergeur quel serveur d’envoi utiliser, ou passez par un service d’envoi qui propose un autre port.

Unable to connect with TLS encryption ou Unable to connect with STARTTLS

Où il s’affiche. La première forme en 1.6, 1.7 et 8 (SwiftMailer), la seconde en 9 (Symfony Mailer). Attention : en 9.0 et 9.1, « TLS » sur le port 587 ne donne aucun des deux, mais Connection could not be established with host "ssl://…:587", suivi d’une erreur SSL. PHP ajoute parfois sa propre explication : SSL operation failed with code, Failed to enable crypto, ou Peer certificate CN=… did not match expected CN=….

Ce que ça veut dire. La connexion chiffrée n’a pas pu s’établir. Trois causes : un chiffrement qui ne correspond pas au port ; un nom de serveur qui ne correspond pas au certificat (mail.votre-boutique.fr au lieu du vrai nom du serveur du fournisseur, par exemple ssl0.ovh.net pour une adresse OVH MX Plan) ; un serveur web trop ancien pour les versions de TLS demandées (Microsoft 365 exige TLS 1.2 ou plus).

Version	Port 587	Port 465
1.6, 1.7, 8	« TLS » (STARTTLS)	« SSL »
9.0 et 9.1	« TLS » échoue. Préférez le port 465. Si votre fournisseur refuse le 465 (Microsoft 365) : « Aucun », et PrestaShop passe de lui-même en STARTTLS.	« TLS » (il n’y a plus de choix SSL)
9.2	« TLS »	« TLS »

« Aucun » sur le port 587 n’est sûr qu’avec un fournisseur qui exige le chiffrement, comme Microsoft 365. Si le serveur ne propose pas STARTTLS, la connexion reste en clair, mot de passe compris. Dans le doute, gardez le 465 ou passez en 9.2. De la 1.6 à la 8, « Aucun » veut dire sans chiffrement du tout, et c’est la valeur par défaut : vérifiez-la dès que vous passez en SMTP.

Vérifier sans risque. Remettez le couple port et chiffrement du tableau, puis le nom de serveur exact du fournisseur, et relancez le test. En 1.7 et 8, la mention « SSL semble ne pas être configuré sur votre serveur. » s’affiche sous « Chiffrement » sur toutes les boutiques : ignorez-la. Pour annuler : revenez à votre capture. Arrêtez-vous si l’erreur de certificat persiste avec le bon nom de serveur. Le serveur web ou le réseau de l’hébergeur est en cause (par exemple OpenSSL ou certificats racines trop anciens) : c’est à l’hébergeur de corriger.

Expected response code 250 but got code

Où il s’affiche. De la 1.6 à la 8 : Expected response code 250 but got code "…", with message "…". En 9, les chiffres sont entre guillemets : Expected response code "250" but got code "…", with message "…". D’autres codes attendus existent (220 à la connexion, 354 avant l’envoi du texte).

Ce que ça veut dire. Le serveur a refusé une étape de l’envoi. Ce message n’est qu’une enveloppe : la vraie cause est après with message. Les plus courantes :

• 5.7.60 SMTP; Client does not have permissions to send as this sender : voir l’entrée 5.7.60 ;
• 553 5.7.1 <adresse>: Sender address rejected: not owned by user … : le même décalage chez un hébergeur sous Postfix, l’adresse de la boutique n’appartient pas à l’utilisateur SMTP. Voir l’entrée 5.7.60 ;
• Relay access denied, Unable to relay, 530 5.7.0 Authentication required : le serveur attend une identification, voir l’entrée relai ;
• 550 5.7.26 chez Gmail (« This email has been blocked because the sender is unauthenticated. ») ou 550 5.7.515 Access denied, sending domain … does not meet the required authentication level. chez Outlook.com : votre domaine n’est pas authentifié, voir la cause 1 et la section DMARC. Le plus souvent, ces deux refus n’apparaissent pas dans PrestaShop : ils reviennent sous forme d’e-mail de non-distribution dans la boîte de l’adresse de la boutique, ou dans l’historique d’envoi de Brevo ou de Mailjet ;
• 550 5.4.5 Daily user sending limit exceeded. : quota Gmail atteint, voir l’entrée Gmail ;
• 554 5.5.1 Error: no valid recipients, qui suit Expected response code 354 en 1.7 et 8 : le serveur a refusé tous les destinataires, en général parce que l’envoi n’est pas identifié. Voir l’entrée relai, puis la cause 8 ;
• 530 5.7.0 Must issue a STARTTLS command first. chez Gmail : le chiffrement est resté sur « Aucun », la valeur par défaut de la 1.6 à la 8. Choisissez « TLS » sur le port 587, voir l’entrée TLS ;
• Expected response code 220 but got an empty response (1.7 et 8) ou Expected response code "220" but got empty code. (9) : le port et le chiffrement ne vont pas ensemble, voir l’entrée TLS.

Vérifier sans risque. Copiez le texte qui suit with message et cherchez-le dans cet index. Pour annuler : ce message ne modifie rien, il n’y a rien à annuler. Arrêtez-vous si le message parle de liste noire ou de réputation (« blocked », « blacklisted », « reputation ») : ne relancez pas l’envoi en boucle, voyez la question sur les listes noires.

Votre message n’est pas dans cet index, ou deux essais n’ont rien changé ? Passez la main : appelez le 09 72 03 59 17 (réponse en moins d’une heure, 7j/7, de 8 h à 22 h) ou décrivez la panne en une ligne, avec le message d’erreur, sans mot de passe ni clé. Dépannage dès 150 € HT, prix fixe validé avant toute intervention.

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 (environ 200 e-mails par heure pour une adresse OVH MX Plan, 500 par jour pour un compte Gmail gratuit), 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 Brevo et non par le serveur d’envoi réglé dans 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.

En multiboutique, PrestaShop permet un SMTP différent par boutique : sélectionnez la boutique en haut du back-office avant de régler la page E-mail (en 1.6, champ par champ). Aucun avertissement ne s’affiche, et une boutique laissée sur les réglages communs envoie depuis le même compte que les autres. Si vos boutiques ont des domaines différents, cela 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 (plus de 72 % des consommateurs interrogés par Mailgun en 2024 ont un compte Gmail personnel) ou Outlook, et que votre domaine n’est authentifié ni par SPF ni par DKIM, Gmail peut refuser vos confirmations de commande (erreur 550 5.7.26). Pas en spam : refusées, et le client ne reçoit rien. PrestaShop ne vous affiche souvent aucune erreur : quand c’est votre hébergeur qui transmet le message, il l’a bien « envoyé » de son côté. Au-delà de 5 000 messages par jour vers Gmail, DMARC devient obligatoire lui aussi.

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 chez les expéditeurs testés par Unspam (bien)
• DKIM : 90 % (bien)
• DMARC : seulement 48 % (plus de la moitié des expéditeurs testés n’ont pas de politique DMARC)
• Boîte de réception principale : 63 % des e-mails testés de janvier à septembre 2026, et 33 % finissent en spam (même source)
• 48 % des expéditeurs citent le fait d’éviter le dossier spam parmi leurs principaux défis de délivrabilité (Mailgun, 2025)

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.

DMARC : aligner DKIM avant de durcir la politique

DMARC ajoute une condition à SPF et DKIM : au moins l’un des deux doit être « aligné », c’est-à-dire validé pour le domaine du champ « De » que voit votre client. Un sous-domaine du vôtre compte aussi : c’est l’alignement « souple », le réglage par défaut. Google l’exige des expéditeurs de plus de 5 000 messages par jour, et c’est sur ce point qu’une boutique qui passe par Brevo ou Mailjet se fait piéger.

Pourquoi SPF s’aligne mal avec un service d’envoi. SPF ne vérifie pas l’adresse que voit votre client, mais l’adresse technique de retour (le « Return-Path »), celle qui reçoit les rebonds. Quand Brevo, Mailjet ou un autre service envoie pour vous, cette adresse est souvent à son nom, pour qu’il traite lui-même les rebonds. SPF passe alors, mais pour son domaine, pas pour le vôtre : il n’est pas aligné, et DMARC ne le compte pas. Certains services permettent de placer cette adresse de retour sur un sous-domaine à vous ; sinon, tout repose sur DKIM.

Pourquoi DKIM tient la route. DKIM signe chaque message avec une clé dont la partie publique est publiée dans votre DNS. La signature voyage avec le message : elle reste valable quel que soit le serveur qui l’a transmis, tant que le message n’est pas modifié en route. Elle est alignée dès que le domaine de la signature (la mention d= de l’en-tête DKIM-Signature) est le vôtre. C’est le rôle de l’« authentification du domaine » chez Brevo ou Mailjet : vous publiez les enregistrements qu’ils vous donnent, et ils signent avec votre domaine. Sans cette étape, la signature porte en général leur domaine, et DMARC échoue malgré un SPF qui passe.

Ce que veulent dire les trois politiques. La politique est une demande faite aux messageries qui reçoivent vos e-mails. Chacune l’applique à sa façon, mais dans les grandes lignes :

Politique	Ce que la messagerie fait d’un message qui échoue	Quand l’utiliser
p=none	Rien de particulier : elle vous envoie seulement des rapports, si une adresse rua est indiquée	Au départ, pour voir qui envoie avec votre domaine. Elle n’empêche personne d’usurper votre adresse.
p=quarantine	Elle le traite comme suspect, en général en le classant en spam	Quand tous vos expéditeurs légitimes sont alignés
p=reject	Elle le refuse à la réception	Quand les rapports restent propres en quarantine

La progression à suivre.

1. Faites la liste de tout ce qui envoie avec votre domaine : la boutique (ou son service d’envoi), votre messagerie, l’outil de newsletter, la facturation, le transporteur.
2. Faites signer chacun en DKIM avec votre domaine. Chez Brevo ou Mailjet, c’est l’authentification du domaine. Pour votre messagerie (Microsoft 365, Google Workspace, votre hébergeur), activez le DKIM chez ce fournisseur. L’option « Connexion DKIM » de PrestaShop 8 et 9 (Paramètres avancés > E-mail) ne sert que si la boutique envoie sans service qui signe, par sendmail par exemple : il faut alors créer une paire de clés et publier la clé publique dans le DNS.
3. Publiez un enregistrement DMARC en p=none, avec une adresse rua pour recevoir les rapports (exemple dans la cause 1).
4. Vérifiez sur un vrai message : créez un compte client avec une adresse Gmail, passez une commande test ou demandez un nouveau mot de passe, puis, dans Gmail, ouvrez l’e-mail reçu et choisissez « Afficher l’original ». Les lignes SPF, DKIM et DMARC doivent indiquer PASS, et la ligne DKIM doit citer votre domaine, pas celui du prestataire.
5. Lisez les rapports pendant quelques semaines. Ils arrivent en pièces jointes compressées (fichiers XML), à ouvrir avec un lecteur de rapports DMARC. Chaque expéditeur légitime doit y apparaître aligné en DKIM. Un expéditeur que personne ne reconnaît n’est pas forcément une usurpation : ce peut être un message transféré ou un outil oublié dans la liste.
6. Passez alors à p=quarantine, surveillez les rapports, puis passez à p=reject. Le faire trop tôt, c’est envoyer vous-même vos confirmations de commande en spam, ou les faire refuser.

Arrêtez-vous si vous ne savez pas qui gère la zone DNS du domaine, si vous ne pouvez pas lire les rapports, ou s’ils citent des serveurs que personne ne reconnaît : ne passez pas en quarantine à l’aveugle, faites-vous aider. Ne créez jamais un second enregistrement SPF ou DMARC : complétez celui qui existe, car deux enregistrements SPF font échouer SPF. Pour annuler une modification, remettez l’ancien enregistrement TXT : notez-le avant d’y toucher. Le retour arrière prend effet à l’expiration de la durée de cache de l’enregistrement (son TTL). Le vérificateur plus haut lit vos enregistrements SPF, DKIM et DMARC publics, sans rien modifier.

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 e-mails s’arrêtent un samedi soir, est-ce que quelqu’un s’en rend compte avant lundi matin ? Deux bons réflexes : un e-mail test après chaque changement, et un coup d’œil chaque semaine à Paramètres avancés > Logs, où les échecs d’envoi sont notés. Le contrat de maintenance PrestaShop (69 € HT/mois, sans engagement) ajoute la surveillance 24/7 de la boutique et un technicien qui intervient quand ça casse.

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

Tant que l’envoi est bloqué, chaque nouvelle commande reste sans confirmation pour votre client.

Vous préférez qu’on s’en occupe ?

Appelez le 09 72 03 59 17 (réponse en moins d’une heure, 7j/7, de 8 h à 22 h) ou décrivez la panne en une ligne, juste en dessous, avec le message d’erreur s’il y en a un, sans mot de passe ni clé. Dépannage dès 150 € HT, prix fixe validé avant toute intervention. Ces 150 € sont déduits si vous passez ensuite à la maintenance (69 € HT/mois, sans engagement), qui sert justement à éviter que la même panne revienne.