Configuration des e-mails dans PrestaShop : SMTP, Gmail et e-mails transactionnels

Dernière révision en juin 2026, tient compte des règles d'authentification Gmail/Yahoo pour les expéditeurs en masse entrées en vigueur en 2024. Les limites et les tarifs des fournisseurs évoluent : vérifiez donc les chiffres actuels auprès de chaque fournisseur. Chemins du back-office vérifiés avec PrestaShop 1.7, 8.x et 9.x.

"Mes clients ne reçoivent pas leurs e-mails de confirmation de commande." C'est l'un des tickets de support les plus fréquents qu'un marchand PrestaShop puisse ouvrir, et ce n'est presque jamais un bug de PrestaShop. L'e-mail paraît être la partie la plus simple de la gestion d'une boutique, la plateforme envoie une confirmation dès qu'une commande est passée, mais le trajet de ce message, de votre serveur jusqu'à la boîte de réception du client, traverse des restrictions d'hébergement, des enregistrements d'authentification et des filtres antispam qui peuvent tous échouer silencieusement. La commande est validée, le paiement est encaissé, et le client ne reçoit rien. Il vous écrit donc, ou pire, il pense que l'achat n'a pas fonctionné et conteste le paiement. Ce guide se concentre précisément sur la délivrabilité fiable des e-mails dans PrestaShop : les réglages exacts du back-office, les choix de fournisseurs SMTP qui comptent vraiment, les enregistrements DNS qui vous évitent le dossier spam, et la manière de prouver que tout fonctionne avant qu'un vrai client ne découvre le contraire.

Les deux méthodes d'envoi d'e-mails proposées par PrestaShop, et pourquoi l'une d'elles vous induit en erreur

Ouvrez Paramètres avancés → E-mail dans votre back-office et vous verrez que PrestaShop propose deux façons d'envoyer des e-mails : la fonction PHP intégrée mail() et "Définir mes propres paramètres SMTP". L'option PHP mail() remet votre message à l'agent de messagerie local (Sendmail ou Postfix) installé sur votre serveur web. Sur le papier, cela fonctionne. En pratique, sur les hébergements mutualisés et managés où tournent la plupart des boutiques PrestaShop, c'est la première cause des "mes e-mails ont disparu" :

• Les hébergeurs la désactivent. De nombreux fournisseurs coupent complètement mail() pour limiter les abus de spam provenant de sites compromis. PrestaShop peut seulement voir une remise locale réussie, les échecs de livraison finale n'apparaissent souvent que dans les journaux du serveur ou du fournisseur, pas dans le back-office.
• Elle n'apporte souvent aucune authentification correcte. PHP mail() ne s'authentifie pas lui-même ; sauf si votre serveur/MTA et votre DNS sont configurés volontairement, un message envoyé ainsi manque souvent d'un alignement SPF, DKIM ou DMARC correct, et Gmail, Outlook et Yahoo traitent désormais par défaut les e-mails non authentifiés d'un expéditeur en masse comme du spam. (Gmail et Yahoo ont officiellement durci ces règles pour les expéditeurs en masse en 2024.)
• Elle ne vous donne aucun retour sur la livraison. La fonction renvoie true ou false au moment de la remise, pas au moment de la livraison. "True" indique que le serveur a accepté le message, mais ne dit rien sur son arrivée en boîte de réception, son rejet ou son filtrage.
• Elle hérite de la réputation d'une IP partagée. En hébergement mutualisé, vous envoyez depuis une IP utilisée aussi par des dizaines d'autres sites ; si l'un d'eux envoie du spam, vos confirmations de commande en paient le prix.

La conclusion pratique est simple : utilisez toujours le SMTP, relié à un vrai service d'e-mail. Le reste de ce guide explique comment le faire correctement.

Configuration SMTP dans PrestaShop, champ par champ

Dans Paramètres avancés → E-mail, choisissez "Définir mes propres paramètres SMTP" et PrestaShop vous demandera les éléments suivants. Tous les fournisseurs ci-dessous remplissent les mêmes champs, seules les valeurs changent :

• Serveur SMTP, le nom d'hôte du fournisseur (par exemple smtp.gmail.com).
• Nom d'utilisateur SMTP, généralement l'adresse d'envoi complète, même si certains services utilisent un libellé fixe (SendGrid demande le mot apikey).
• Mot de passe SMTP, le mot de passe de la boîte mail, un mot de passe spécifique à l'application ou une clé API, selon le fournisseur.
• Chiffrement, TLS (port 587) ou SSL (port 465). Ne choisissez jamais "Désactivé" : vos identifiants seraient envoyés en clair sur Internet.
• Port SMTP, 587 pour TLS (le standard moderne) ou 465 pour SSL.

À quoi cela sert-il de bien régler ces champs ? Vous obtenez une connexion qui s'authentifie comme un expéditeur légitime, condition indispensable pour tout ce qui vient ensuite : signature DKIM, placement en boîte de réception et tableau de bord fournisseur capable de vous dire réellement ce qui est arrivé à chaque message. Voici les trois niveaux de fournisseurs vers lesquels se dirigent la plupart des boutiques PrestaShop.

SMTP Gmail, correct pour une petite boutique, avec un plafond strict

Gmail est le premier choix le plus courant parce que le marchand possède déjà le compte. Les réglages :

Pour générer le mot de passe d'application : dans votre compte Google, allez dans Sécurité → Validation en deux étapes → Mots de passe des applications, créez-en un pour "Mail" / "Autre (nom personnalisé)" avec le libellé "PrestaShop", puis collez la chaîne de 16 caractères dans le champ du mot de passe SMTP de PrestaShop. La validation en deux étapes doit d'abord être activée, sinon Google n'affichera pas l'option des mots de passe d'application.

La limite, c'est le volume. Un compte Gmail gratuit est plafonné à environ 500 destinataires par jour ; Google Workspace porte cette limite à environ 2 000. Chaque commande PrestaShop déclenche généralement deux ou trois e-mails, confirmation client, notification administrateur, puis notification d'expédition, si bien qu'une boutique qui traite plus de 100 commandes par jour peut frôler le plafond de Gmail gratuit. Une fois la limite dépassée, les e-mails commencent à être différés ou rejetés sans signal évident dans le back-office. Gmail est une solution de départ, pas une destination.

SMTP Outlook / Microsoft 365

Microsoft restreint progressivement l'authentification SMTP de base ; sur de nombreux tenants, vous devez donc activer explicitement SMTP authentifié pour la boîte mail dans le centre d'administration Exchange avant que PrestaShop puisse se connecter. Si le test de connexion échoue sur Microsoft 365 alors que les identifiants sont corrects, ce réglage est la cause la plus fréquente.

Services d'e-mail transactionnel. La bonne réponse dès que le volume devient réel

Au-delà de quelques centaines de messages par jour, passez à un service conçu pour l'envoi transactionnel : SendGrid, Mailgun, Brevo ou Amazon SES. Ils vous offrent une réputation d'envoi dédiée, une gestion automatique des rebonds et des plaintes, ainsi qu'un tableau de bord de livraison, ce que Gmail ne fournit pas. Exemple avec SendGrid :

Les tarifs et les limites des offres gratuites changent ; vérifiez donc la page actuelle du fournisseur plutôt que de vous fier à un chiffre dans un article de blog. Mais l'avantage structurel ne change pas : une IP d'envoi dont la réputation est gérée activement par vous et par le fournisseur, des données de rebond qui vous reviennent, et un statut de livraison par message. Pour toute boutique où une confirmation de commande manquée coûte un ticket de support ou une contestation de paiement, cette visibilité est précisément l'intérêt.

Authentification des e-mails : SPF, DKIM et DMARC

Des paramètres SMTP corrects permettent au message de sortir. Trois enregistrements DNS décident ensuite si le serveur de réception lui fait assez confiance pour le déposer dans la boîte de réception. Sans eux, même un SMTP parfaitement configuré finit en spam, c'est la deuxième plainte e-mail la plus fréquente après "rien ne part du tout", et contrairement aux réglages PrestaShop, ces paramètres vivent dans le DNS de votre domaine, pas dans le back-office.

SPF. Qui est autorisé à envoyer en votre nom

SPF (Sender Policy Framework) est un enregistrement TXT DNS qui liste les serveurs autorisés à envoyer des e-mails pour votre domaine. Le serveur destinataire le vérifie pour confirmer que le message provient d'une source autorisée. Exemple d'enregistrement typique pour une boutique qui envoie via Google et SendGrid :

v=spf1 include:_spf.google.com include:sendgrid.net ~all

N'incluez que les services depuis lesquels vous envoyez réellement, chaque include supplémentaire affaiblit légèrement l'enregistrement, et SPF impose une limite stricte de 10 recherches DNS avant d'échouer complètement.

DKIM, une signature qui prouve que rien n'a été altéré

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque message, prouvant qu'il vient de votre domaine et qu'il n'a pas été modifié en transit. Votre fournisseur génère la clé ; vous la publiez sous forme d'enregistrement TXT ou CNAME. Pour Google Workspace sur un domaine personnalisé, activez-la dans Applications → Google Workspace → Gmail → Authentifier l'e-mail. Pour SendGrid, utilisez Settings → Sender Authentication → Authenticate Your Domain, qui vous fournit les enregistrements CNAME à ajouter au DNS.

DMARC, que faire des e-mails qui échouent aux deux premiers contrôles

DMARC relie SPF et DKIM et indique aux destinataires comment traiter les messages qui échouent. Commencez en mode surveillance pour ne rien casser :

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Cela vous signale les échecs sans rien bloquer. Après quelques semaines de rapports propres, passez à p=quarantine (rediriger les échecs vers le spam), puis éventuellement à p=reject (les bloquer). Passer directement à p=reject avant d'avoir confirmé que vos e-mails légitimes passent correctement est une façon classique pour les boutiques de bloquer accidentellement leurs propres confirmations de commande.

Bien régler l'adresse "From" (un tueur discret de délivrabilité)

L'adresse d'expéditeur de PrestaShop se règle dans Paramètres de la boutique → Contact → Magasins (ainsi que l'e-mail de contact propre à chaque boutique). Un échec discret mais très courant : cette adresse "From" doit être alignée avec le domaine que vous avez authentifié pour le SMTP. Envoyer en tant que info@yourstore.com tout en vous authentifiant via smtp.gmail.com avec une identité @gmail.com crée une incohérence d'authentification que SPF/DMARC signalera, et votre e-mail tombera en spam même si chaque réglage pris séparément "semble" correct. Gardez le domaine d'envoi, l'identité SMTP et les enregistrements d'authentification orientés vers le même endroit.

Prouver que cela fonctionne, avant qu'un client ne prouve le contraire

Ne faites pas confiance à un écran de paramètres qui indique "enregistré". Testez le chemin réel de livraison :

• Le test intégré de PrestaShop. Sur la page Paramètres avancés → E-mail, un champ "Envoyer un e-mail de test" est disponible. Envoyez-en un à vous-même et vérifiez qu'il arrive dans la boîte de réception, pas dans les spams.
• mail-tester.com. Envoyez un message à l'adresse indiquée ; l'outil note SPF, DKIM, DMARC, le contenu et l'état des listes noires sur 10. Visez 9+ avant de considérer le travail terminé.
• Testez plusieurs fournisseurs. Envoyez séparément vers Gmail, Outlook/Hotmail et Yahoo, leurs règles antispam diffèrent, et réussir chez l'un ne garantit pas de réussir chez les trois.
• Lisez les en-têtes. Dans un message reçu sur Gmail, ouvrez trois points → Afficher l'original et cherchez SPF: PASS, DKIM: PASS et DMARC: PASS. Si l'un indique FAIL ou NONE, corrigez l'enregistrement DNS correspondant avant la mise en production.

E-mail transactionnel ou marketing, gardez-les sur des circuits séparés

Ce guide parle des e-mails transactionnels : confirmations de commande, avis d'expédition, réinitialisations de mot de passe, les messages que PrestaShop déclenche automatiquement à la suite directe d'une action client. Traitez-les comme un flux différent des newsletters et des promotions marketing, car les mélanger a un coût :

• Contamination de la réputation. Si votre newsletter reçoit des plaintes pour spam et utilise la même IP ou le même domaine que vos confirmations de commande, elle entraîne ces confirmations avec elle.
• Règles juridiques différentes. Un e-mail transactionnel n'a pas besoin de lien de désabonnement (il est nécessaire à l'exécution de l'achat) ; un e-mail marketing, si. Les séparer maintient une ligne de conformité claire.
• Pics de volume. Une campagne newsletter envoyée à 50 000 destinataires peut saturer une connexion SMTP partagée et retarder la confirmation de commande urgente qu'un client attend.

Bonne pratique : envoyez les e-mails transactionnels de PrestaShop via votre service SMTP, et gérez les newsletters depuis une plateforme dédiée (Mailchimp, Brevo, Klaviyo). Si vous voulez relier ces deux univers, par exemple ajouter automatiquement un nouveau client PrestaShop à votre liste newsletter, connectez-les avec une couche d'automatisation plutôt que de mélanger les flux d'envoi ; nous expliquons la méthode sans code dans Zapier et Make pour PrestaShop et, plus précisément pour les déclencheurs de workflows, dans PrestaShop et Zapier sans écrire de code.

La checklist de dépannage quand les e-mails ne partent pas

Voici les cas que nous rencontrons le plus souvent lorsque des marchands nous demandent d'examiner des e-mails PrestaShop cassés, à peu près dans l'ordre où il vaut la peine de les vérifier.

Rien ne part du tout

• Lisez d'abord le journal des e-mails. Lorsque la journalisation est activée, Paramètres avancés → E-mail liste les messages que PrestaShop a tenté d'envoyer (destinataire, modèle, objet, heure). Si les messages sont journalisés mais n'arrivent pas, PrestaShop les génère et les remet correctement, mais ils échouent plus loin (authentification ou spam). Si rien n'est journalisé, l'envoi échoue avant cette étape, revérifiez l'hôte SMTP, le port et les identifiants, et confirmez que la journalisation elle-même est activée.
• Retestez directement les identifiants. Connectez-vous à la boîte mail ou à la console du fournisseur avec exactement le nom d'utilisateur et le mot de passe que vous avez collés dans PrestaShop. Si vous n'y arrivez pas, PrestaShop n'y arrivera pas non plus.
• Vérifiez que le port n'est pas bloqué par un pare-feu. Certains hébergeurs bloquent les sorties 587/465. Si le test de connexion expire, demandez à votre hébergeur de confirmer que ces ports sont ouverts pour le trafic sortant.

Les e-mails partent mais arrivent en spam

• SPF/DKIM manquants ou en échec. Vérifiez avec mxtoolbox.com que les deux enregistrements existent et passent pour votre domaine.
• Incohérence de l'adresse From. Voir la section "From" ci-dessus, c'est la cause de spam la plus souvent négligée.
• Contenu de modèle trop typé spam. Des formulations insistantes autour de "gratuit / remise / agir maintenant" et un mauvais ratio texte/image dans des modèles personnalisés déclenchent les filtres de contenu.

Échecs intermittents

• Limitation de débit. Vous dépassez le plafond d'envoi quotidien du fournisseur ; comparez votre volume réel à la limite du forfait et changez d'offre ou de fournisseur si vous l'avez dépassée.
• Délais de connexion. Un serveur SMTP lent peut dépasser le délai de connexion par défaut de PrestaShop, l'augmenter (par exemple de 5 à 20 secondes) corrige souvent les envois instables.

Envoyé avec succès, mais le client dit n'avoir rien reçu

Vérifiez que l'adresse du client ne contient pas de faute de frappe, consultez le journal des rebonds de votre fournisseur, et demandez-lui de regarder dans les spams et d'autoriser votre adresse d'envoi. "Envoyé" dans PrestaShop signifie seulement que le serveur SMTP a accepté le message, c'est dans le tableau de bord du fournisseur que vous voyez s'il a rebondi. Une fois l'adresse confirmée et la cause de délivrabilité corrigée, vous voudrez renvoyer cette confirmation précise plutôt que de laisser le client sans information : notre module Resend Order Confirmation relance la confirmation de commande directement depuis la page de commande, afin qu'un incident ponctuel de livraison ne se transforme pas en reconstruction manuelle de l'e-mail.

Personnaliser les modèles d'e-mails de PrestaShop

Les modèles d'e-mails de PrestaShop peuvent se trouver dans plusieurs emplacements mails/<language_code>/, le cœur, le thème et les répertoires mails des modules, selon votre version, votre thème et les modules installés, chaque type existant sous forme de fichier HTML avec une version TXT de secours en texte brut. Les versions récentes (1.7/8/9) permettent aussi de modifier l'apparence dans Apparence → Thème d'e-mail. Quelques règles pour que les modèles personnalisés s'affichent correctement partout :

• Utilisez du CSS en ligne, de nombreux clients e-mail suppriment les blocs <style>.
• Construisez la mise en page avec des tableaux ; le rendu HTML des e-mails est pratiquement resté bloqué en 2005.
• Gardez une largeur inférieure à 600px pour le mobile.
• Testez dans plusieurs clients (Gmail web, Outlook desktop, Apple Mail, mobile).
• Ne supprimez jamais les variables comme {firstname}, {lastname} ou {order_name}, PrestaShop les remplace par les vraies données au moment de l'envoi, et les retirer casse la fusion.

Journalisation et vraie surveillance de la livraison

Lorsque la journalisation des e-mails est activée, PrestaShop enregistre chaque tentative d'envoi dans sa base de données, consultable dans Paramètres avancés → E-mail, avec le destinataire, le modèle utilisé, la langue, l'objet et l'heure d'envoi. Mais n'oubliez pas ce que signifie une entrée dans cette liste : PrestaShop a remis le message au serveur SMTP. Ce n'est pas une preuve de livraison en boîte de réception, et le journal ne contient aucun statut livré/rebondi par message. Pour cette vérité, il faut le tableau de bord de votre fournisseur, SendGrid, Mailgun et Amazon SES indiquent tous les taux de messages livrés, rebondis, différés et signalés comme plaintes, message par message. Jetez-y un œil chaque semaine ; un taux de rebond qui grimpe lentement est le premier signal qu'un problème de délivrabilité se forme avant que les clients ne commencent à le remarquer.

Questions fréquentes

Pourquoi mes e-mails de confirmation de commande PrestaShop ne sont-ils pas livrés ?

La cause la plus fréquente est l'utilisation de PHP mail() sur un hébergement qui la désactive ou qui envoie sans authentification, Gmail, Outlook et Yahoo classent désormais les e-mails en masse non authentifiés à la corbeille ou en spam. Passez à "Définir mes propres paramètres SMTP" dans Paramètres avancés → E-mail, reliez PrestaShop à un vrai service d'e-mail, et publiez les enregistrements SPF, DKIM et DMARC. Puis prouvez le chemin avec un test avant de l'utiliser pour de vraies commandes.

Quel port SMTP et quel chiffrement utiliser ?

Le port 587 avec TLS est le standard moderne et celui que recommandent la plupart des fournisseurs ; le port 465 avec SSL est l'ancienne alternative et fonctionne encore. Ne choisissez jamais "Désactivé", cela envoie vos identifiants sans chiffrement. Si un test de connexion expire sur l'un ou l'autre port, votre hébergeur bloque peut-être le SMTP sortant et vous devrez lui demander de l'ouvrir.

Puis-je simplement utiliser mon compte Gmail pour envoyer les e-mails de la boutique ?

Pour une petite boutique, oui, utilisez smtp.gmail.com sur le port 587/TLS avec un mot de passe d'application de 16 caractères (pas votre mot de passe de connexion, et la validation en deux étapes doit être activée d'abord). Mais un compte Gmail gratuit est limité à environ 500 destinataires/jour et Workspace à environ 2 000. Comme chaque commande déclenche deux ou trois e-mails, une boutique au-delà d'environ 100 commandes/jour atteindra ce plafond et les e-mails commenceront à être différés silencieusement. Gmail est une solution de départ, pas une destination, passez à SendGrid, Mailgun, Brevo ou Amazon SES dès que le volume augmente.

Mes e-mails partent mais arrivent en spam, qu'est-ce qui cloche ?

Presque toujours une authentification manquante ou en échec, ou une incohérence de l'adresse From. Vérifiez que SPF et DKIM existent et passent (mxtoolbox.com), et assurez-vous que le domaine de votre adresse "From" correspond au domaine par lequel vous authentifiez le SMTP, envoyer en tant que info@yourstore.com tout en s'authentifiant avec une identité @gmail.com est signalé par SPF/DMARC et envoyé en spam même lorsque chaque réglage "semble" correct.

Un client dit ne jamais avoir reçu sa confirmation, que faire ?

Vérifiez d'abord qu'il s'agit bien d'un échec réel : cherchez une faute de frappe dans l'adresse et consultez le journal des rebonds de votre fournisseur ("Envoyé" dans PrestaShop signifie seulement que le serveur SMTP l'a accepté, pas qu'il a été livré). Corrigez la cause de délivrabilité, puis renvoyez cette confirmation précise plutôt que de laisser le client sans réponse, Resend Order Confirmation la relance depuis la page de commande en un clic.

Les confirmations de commande et ma newsletter doivent-elles passer par le même service ?

Non, gardez-les sur des circuits séparés. Si votre newsletter génère des plaintes pour spam et partage une IP ou un domaine avec vos e-mails transactionnels, elle dégrade aussi vos confirmations de commande. Envoyez les e-mails transactionnels via votre service SMTP et gérez les newsletters depuis une plateforme dédiée (Mailchimp, Brevo, Klaviyo). Reliez les deux avec une couche d'automatisation si nécessaire, plutôt que de mélanger les flux d'envoi.

La place de l'e-mail dans une boutique qui dépasse le travail manuel

Un e-mail transactionnel fiable est une base, mais c'est rarement le seul endroit où une boutique en croissance perd du temps et de l'information. Le même événement de commande qui déclenche une confirmation doit souvent aussi parvenir à votre logiciel de comptabilité et, à terme, à votre ERP, et recopier ces données à la main est exactement le type de travail manuel qui casse dès que le volume augmente. Si vos e-mails de commande sont réglés mais que le reste de votre back-office fonctionne encore au copier-coller, voici les prochains dominos :

• Comptabilité. Envoyer automatiquement les données de facture de chaque commande vers Xero ou QuickBooks, au lieu de les ressaisir, voir connecter PrestaShop à votre logiciel de comptabilité.
• ERP. Lorsque le stock, les commandes et les clients doivent rester synchronisés avec un système de back-office, les schémas d'intégration qui tiennent vraiment dans le temps sont présentés dans les schémas d'intégration PrestaShop-ERP, avec les signaux indiquant qu'il est temps de passer à l'étape suivante dans quand votre boutique dépasse le travail manuel.
• Connecteurs no-code. Pour les connexions plus légères, pousser un nouveau client dans une liste, envoyer une commande vers un outil, consultez Zapier et Make pour PrestaShop.

La délivrabilité des e-mails n'a rien de glamour, et c'est justement pour cela qu'elle est négligée jusqu'au jour où un client qui n'a jamais reçu sa confirmation ouvre un litige. Branchez le SMTP sur un vrai fournisseur, publiez vos enregistrements SPF, DKIM et DMARC, alignez votre adresse "From" et prouvez tout le parcours avec un test avant de lui confier de vraies commandes. Pour des modules qui étendent les capacités de gestion et d'intégration de PrestaShop, conçus pour survivre aux mises à jour de PrestaShop et de PHP au lieu de casser à la suivante, parcourez le catalogue sur mypresta.rocks.