Guides Tutoriel

Faire en sorte que les e-mails de votre boutique arrivent

Pourquoi les emails PrestaShop arrivent en spam et comment SMTP, SPF/DKIM/DMARC et les services transactionnels y remédient, réglages PS 8/9 inclus.

Les confirmations de commande qui finissent en spam : la plainte e-mail n°1 que l'on nous remonte

Un client paie. Le journal des e-mails de PrestaShop indique « envoyé ». L'e-mail de confirmation n'arrive jamais, ou bien il atterrit dans l'onglet Promotions, ou encore il reste six heures dans les spams. Le client panique, ouvre une rétrofacturation, laisse un avis une étoile et écrit au support pour demander « est-ce que vous avez prélevé mon argent ? ». Nous avons vu ce scénario se produire sur plus de boutiques que l'on ne peut compter, et en 2026 c'est toujours le problème d'e-mail le plus courant dans PrestaShop.

La solution se trouve rarement à l'intérieur de PrestaShop. La délivrabilité est décidée par le serveur de messagerie destinataire (Gmail, Outlook, Yahoo), et ce qu'il décide dépend de la façon dont vous vous authentifiez, de la réputation de l'IP émettrice, et du fait que votre DNS dise ou non la vérité sur qui est autorisé à émettre au nom de votre domaine. Le rôle de PrestaShop se limite à remettre le message proprement.

La fonction PHP mail() n'est que du décor

Une installation PrestaShop neuve envoie via la fonction mail() de PHP. C'est le réglage par défaut, et c'est la pire option que l'on puisse imaginer pour une boutique en production :

  • Aucune authentification. Le message arrive sans la moindre preuve que vous l'avez autorisé. Gmail et Outlook traitent le courrier non authentifié comme coupable jusqu'à preuve du contraire.
  • IP partagée, réputation partagée. Sur un hébergement mutualisé, votre courrier part de la même IP que 200 autres sites. Si l'un d'eux fait du spam, vous en pâtissez tous.
  • Aucune signature DKIM. mail() ne signe rien de manière cryptographique. Il n'y a rien que le destinataire puisse vérifier.
  • En-têtes réduits au strict minimum. Les filtres anti-spam jugent cela suspect avant même de regarder le corps du message.
Si votre boutique utilise encore mail(), passer à du vrai SMTP est le changement unique qui réglera plus de problèmes de délivrabilité que toutes les autres étapes de cette page réunies. Faites-le en premier.

Ce qui fait réellement marquer un message comme spam

  • Incohérence de l'adresse d'expéditeur. Envoyer depuis noreply@yourstore.com alors que votre DNS n'a aucun enregistrement SPF autorisant l'IP de votre serveur à le faire.
  • Modèles surchargés d'images. Les modèles PrestaShop par défaut regorgent d'images. Un mauvais ratio image/texte constitue à lui seul un signal de spam.
  • Absence de partie texte brut. PrestaShop envoie du multipart par défaut, mais les modèles personnalisés et les modules de traduction peuvent discrètement casser l'alternative en texte brut.
  • Liens cassés. Les filtres anti-spam résolvent les URL contenues dans votre message. Si votre vitrine est en mode maintenance, présente une chaîne SSL défaillante ou renvoie une erreur 500, votre e-mail est signalé.
  • Encodage corrompu. Les boutiques avec des diacritiques polonais, tchèques, allemands ou français produisent du mojibake dès qu'un maillon de la chaîne n'est pas en UTF-8.

Configuration des e-mails PrestaShop selon la version

Configuration des e-mails dans l'interface d'administration de PrestaShop 8.

Le choix entre sendmail et SMTP, le format des e-mails, l'activation du journal et la signature DKIM. Si vos confirmations de commande partent en spam, c'est ici qu'il faut commencer.

Page des paramètres E-mail du back-office de PrestaShop 8 montrant le choix entre sendmail et SMTP, la configuration DKIM et la journalisation des e-mails

La page de réglages est restée à peu près au même endroit. La bibliothèque qui la sous-tend, elle, a complètement changé en PS 9.

PrestaShop 1.6 et 1.7

Paramètres avancés → E-mail. Choisissez « Définir mes propres paramètres SMTP » et saisissez le serveur, le port, le chiffrement, le nom d'utilisateur et le mot de passe. PS 1.6 utilise la gestion SMTP propre à PHP ; PS 1.7 a introduit Swift Mailer. Choix de chiffrement :

  • TLS (port 587) : Le standard moderne. STARTTLS, la bonne réponse presque partout.
  • SSL (port 465) : Ancien TLS implicite. Certains hébergeurs vieillissants l'exigent encore.
  • Aucun (port 25) : Non chiffré. À éviter.

PrestaShop 8.x

Même écran, même interface. PS 8 embarque l'ultime version de Swift Mailer, avec une meilleure remontée d'erreurs, quand le SMTP échoue, vous obtenez réellement une ligne utile dans var/logs/ au lieu d'un abandon silencieux.

PrestaShop 9 : Symfony Mailer

PS 9 met Swift Mailer à la retraite (il est en fin de vie en amont depuis des années) et le remplace par Symfony Mailer. L'interface d'administration paraît identique, mais tout a changé en dessous :

  • Configuration basée sur un DSN. En interne, le transport est une URI : smtp://user:password@server:port.
  • Détection TLS automatique. Le port 587 négociera automatiquement STARTTLS. La liste déroulante « chiffrement » se comporte parfois différemment après une mise à niveau 8 → 9, retestez.
  • Validation plus stricte. Symfony Mailer tient à ce que l'expéditeur d'enveloppe corresponde à l'en-tête From, et il valide correctement les certificats TLS.
  • Modules cassés. Tout module qui importe Swift_Message ou Swift_SmtpTransport cesse de fonctionner sur PS 9 tant qu'il n'est pas mis à jour.
# Exemples de DSN internes de PS 9 (configurés via l'interface d'administration)
smtp://user:password@mail.example.com:587      # STARTTLS
smtps://user:password@mail.example.com:465     # TLS implicite
smtp://your%40gmail.com:app-pass@smtp.gmail.com:587  # Gmail
native://default                                # PHP mail() (déconseillé)
Retestez toujours l'e-mail après chaque mise à niveau 8 → 9. Nous avons vu des certificats auto-signés, des ports non standard et des serveurs SMTP mal implémentés cesser de fonctionner dès l'instant où Symfony Mailer prend le relais.

Le bouton « envoyer un e-mail de test »

Chaque version le possède. Il est utile, mais il ne confirme qu'une seule chose : que votre boutique peut ouvrir une connexion SMTP. Il ne confirme pas que le message a atteint une boîte de réception. Passez de vraies commandes de test vers une adresse Gmail, une adresse Outlook et une adresse sur votre propre domaine, ces trois-là couvrent environ 90 % de ce qu'utilisent vos clients.

Authentification de domaine : SPF, DKIM, DMARC

SPF, DKIM et DMARC sont trois enregistrements DNS qui, ensemble, prouvent que votre courrier est légitime. Gmail et Yahoo ont rendu SPF et DKIM obligatoires pour les expéditeurs en masse en février 2024. Nous les considérons comme obligatoires pour tout expéditeur, point final.

SPF (Sender Policy Framework)

Un seul enregistrement TXT sur votre domaine qui nomme les IP et services autorisés à émettre en votre nom.

# Base : autorise l'hébergement + Google
v=spf1 include:_spf.google.com include:your-hosting-provider.com ~all

# OVH
v=spf1 include:mx.ovh.com ~all

# Hostinger
v=spf1 include:_spf.hostinger.com ~all

# Avec Mailgun
v=spf1 include:mailgun.org include:_spf.google.com ~all

Là où cela tourne mal :

  • Deux enregistrements SPF. Un seul enregistrement TXT par domaine constitue un SPF valide. Deux enregistrements s'annulent mutuellement. Combinez les services en un seul enregistrement avec plusieurs directives include:.
  • Trop de requêtes. SPF autorise 10 requêtes DNS au total. Chaque include: compte, et les inclusions imbriquées comptent aussi. Faites passer le vôtre dans un validateur avant publication.
  • +all au lieu de ~all. +all indique au monde entier que n'importe qui peut émettre en votre nom, soit exactement l'inverse du but recherché. Commencez avec ~all (softfail), puis durcissez vers -all une fois en confiance.
  • Les sous-domaines ne sont pas hérités. Le SPF de shop.example.com a besoin de son propre enregistrement. Le domaine parent ne le couvre pas.

DKIM

DKIM signe cryptographiquement chaque message sortant. PrestaShop ne signe pas en DKIM : c'est votre relais SMTP, votre hébergeur ou votre service transactionnel qui le fait. Vous publiez leur clé publique dans le DNS, et ils signent avec la clé privée correspondante.

  • Hébergement mutualisé (cPanel/Plesk) : Généralement un clic dans cPanel → Email Deliverability.
  • Gmail / Google Workspace : Console d'administration → Gmail → Authentifier les e-mails. Google vous fournit un enregistrement TXT.
  • Services transactionnels : Leur assistant de vérification de domaine vous indique exactement ce qu'il faut publier.
# Exemple d'enregistrement TXT DKIM
# Name: default._domainkey.yourstore.com (le sélecteur varie selon le fournisseur)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

DMARC

DMARC relie SPF et DKIM et indique au serveur destinataire la marche à suivre lorsque l'authentification échoue.

# Étape 1 : surveillance uniquement
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com;

# Étape 2 : mise en quarantaine des échecs
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourstore.com;

# Étape 3 : rejet des échecs (protection maximale)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourstore.com;

L'adresse rua reçoit des rapports agrégés au format XML. Une liste quotidienne de ceux qui ont tenté d'émettre du courrier au nom de votre domaine. Nous faisons passer les nôtres par la surveillance DMARC gratuite de Postmark, parce que lire du XML brut n'est pas la manière dont quiconque devrait passer son lundi matin.

Déployez DMARC par étapes. De deux à quatre semaines en p=none pendant que vous lisez les rapports et identifiez les expéditeurs légitimes qui échouent. Durcissez ensuite vers p=quarantine pour deux à quatre semaines de plus. Ce n'est qu'alors que vous passerez à p=reject. Passer directement à reject le premier jour bloque du courrier dont vous ignoriez l'existence, souvent un CRM ou un comptable qui envoie des factures en votre nom.

SMTP sur hébergement mutualisé

La plupart des boutiques PrestaShop vivent sur un hébergement mutualisé. Créez une boîte aux lettres dédiée (par exemple orders@yourstore.com) et utilisez ces identifiants dans PrestaShop, jamais votre boîte personnelle.

Réglages des fournisseurs

# cPanel générique
Server: mail.yourstore.com | Port: 587 | Encryption: TLS

# OVH
Server: ssl0.ovh.net | Port: 587 | Encryption: TLS

# Hostinger
Server: smtp.hostinger.com | Port: 587 | Encryption: TLS

# SiteGround
Server: yourstore.com | Port: 465 | Encryption: SSL

# Bluehost
Server: mail.yourstore.com | Port: 465 | Encryption: SSL

SMTP Gmail

Champs de configuration SMTP dans PrestaShop 8.

Lorsque « Définir mes propres paramètres SMTP » est sélectionné, ces champs apparaissent : serveur, port, nom d'utilisateur, mot de passe, chiffrement. C'est ici que vous pointez PrestaShop vers Gmail, SendGrid, Mailgun ou votre propre serveur de messagerie.

Configuration SMTP de PrestaShop 8 affichant les champs serveur, port, nom d'utilisateur, mot de passe et chiffrement

C'est ce que nous utilisons nous-mêmes pour mypresta.rocks, le SMTP Gmail avec un mot de passe d'application (Compte Google → Sécurité → Validation en deux étapes → Mots de passe des applications). Économique, fiable et raisonnable pour une boutique à faible volume.

Server: smtp.gmail.com | Port: 587 | Encryption: TLS
Username: your@gmail.com | Password: (16-char App Password)

Limites : Gmail gratuit 500/jour, Google Workspace 2 000/jour. En cas de pic trop rapide, Google vous bridera temporairement.

Le SMTP Gmail fonctionne très bien pour les boutiques en dessous d'environ 30 commandes par jour. Au-delà, vous commencez à atteindre le plafond, et les clients attendent jusqu'à 24 heures leur confirmation. C'est le moment de passer à un véritable service transactionnel.

SMTP Microsoft 365

Server: smtp.office365.com | Port: 587 | Encryption: TLS
Username: your@yourstore.com | Password: account or App Password

Limite : 10 000 destinataires/jour, 30 messages/minute. Microsoft insiste de plus en plus sur OAuth plutôt que sur l'authentification SMTP basique, vérifiez la politique de votre locataire avant la mise en production.

Services d'e-mail transactionnel

Quand vous dépassez le SMTP de votre hébergement, les services transactionnels vous offrent une infrastructure dédiée à haute réputation, la signature DKIM gérée pour vous, le traitement des rebonds et un tableau de bord qui vous dit ce qui est réellement arrivé à chaque message.

Quand franchir le pas

  • Vous atteignez les limites d'envoi de votre hébergeur.
  • Le courrier atterrit en spam même avec SPF, DKIM et DMARC tous au vert.
  • Vous avez besoin du suivi de livraison et de la gestion des rebonds.
  • La réputation de votre IP partagée vous tire vers le bas et vous n'y pouvez rien.

Lesquels valent le coup

Mailgun : à partir de 15 $/mois pour 10 000 e-mails. API solide, analyses utiles. SMTP sur smtp.mailgun.org:587.

Postmark : à partir de 15 $/mois pour 10 000 e-mails. Le meilleur taux de boîte de réception que nous ayons mesuré. Séparation nette entre flux transactionnel et flux marketing, ce qui est exactement la bonne architecture. SMTP sur smtp.postmarkapp.com:587, Server API Token à la fois dans le nom d'utilisateur et dans le mot de passe.

Amazon SES : 0,10 $ pour 1 000 e-mails. Le moins cher à grande échelle, d'un ordre de grandeur. Générez les identifiants SMTP dans la console SES (pas vos clés AWS IAM). Les nouveaux comptes démarrent en bac à sable jusqu'à ce que vous demandiez l'accès en production. Point de terminaison propre à la région, par exemple email-smtp.eu-west-1.amazonaws.com:587.

SendGrid : offre gratuite 100/jour, payant à partir de 19,95 $/mois. Le nom d'utilisateur est littéralement la chaîne apikey, le mot de passe est votre clé API. SMTP sur smtp.sendgrid.net:587. L'offre gratuite partage les IP avec tous les autres utilisateurs de l'offre gratuite, si bien que la délivrabilité y est mauvaise, prévoyez le budget pour le payant.

Brevo : offre gratuite 300/jour, payant à partir de 9 $/mois. Newsletter et CRM intégrés, basé dans l'UE (pratique pour le RGPD). SMTP sur smtp-relay.brevo.com:587. Dispose de son propre plugin PrestaShop si vous en voulez un.

Nos choix par défaut : Brevo si vous voulez les newsletters au même endroit. Postmark si le taux de boîte de réception transactionnel est ce qui vous importe. Amazon SES à fort volume avec un budget serré. Mailgun comme option polyvalente sûre.

Comment vous vous connectez

Tous parlent le SMTP standard, sans module requis. Vérifiez le domaine, publiez leurs enregistrements SPF et DKIM, générez les identifiants SMTP, collez-les dans PrestaShop, testez.

Messagerie auto-hébergée

Vous pouvez faire tourner votre propre serveur de messagerie. C'est notre cas, nous faisons tourner Mailcow pour une partie de notre infrastructure. Cela vous donne un contrôle total, aucun frais par e-mail, aucun tiers qui lit les données de vos clients. Le coût, c'est un véritable travail d'administration système permanent, et bâtir une réputation à partir de zéro prend des semaines.

Quand cela en vaut la peine

  • Confidentialité. Les données e-mail des clients ne quittent jamais vos machines. Réellement utile pour des lectures strictes du RGPD.
  • Volume. Au-delà de 100 000 messages par mois, un VPS à 40 $ revient moins cher que n'importe quel service transactionnel.
  • Contrôle. Vos règles, vos limites, aucune suspension de compte pour « violation de politique » décidée par un robot.

Quand cela n'en vaut pas la peine

  • Aucune expérience d'administration système. Un serveur de messagerie mal configuré est pire qu'un hébergement mutualisé. Au moins l'IP de l'hébergeur a une certaine réputation.
  • IP toute neuve. Une IP d'envoi flambant neuve est invisible pour les destinataires. La réputation se construit sur plusieurs semaines. Les services transactionnels vous remettent une réputation établie dès le premier jour.
  • Pas d'enregistrement PTR. Sans DNS inverse, la plupart des destinataires rejettent votre courrier d'emblée.
  • Maintenance. Correctifs, certificats, surveillance des listes de blocage, examen des journaux, permanent, pas facultatif.

Ce que nous choisirions

Mailcow : Basé sur Docker, webmail, antispam, antivirus, autodiscover, tout dans la boîte. 4 Go de RAM ou plus. C'est ce que nous faisons tourner.

Mail-in-a-Box : Tout-en-un sur un hôte Ubuntu dédié. Plus simple, mais il s'empare de la machine.

iRedMail : Postfix + Dovecot traditionnels. Le plus flexible, le plus léger, le plus manuel.

Faites passer votre propre messagerie professionnelle par un nouveau serveur auto-hébergé pendant trois mois avant d'y router la moindre commande client. Construisez la réputation lentement. Gardez un service transactionnel branché en secours pendant tout ce temps.

Les types d'e-mails qu'envoie PrestaShop

Doivent atteindre la boîte de réception immédiatement

  • Confirmation de commande (order_conf). Celle qui provoque rétrofacturations et mauvais avis quand elle n'arrive pas. Protégez-la avant toutes les autres.
  • Confirmation de paiement (payment). Les clients sont nerveux tant qu'ils ne l'ont pas vue.
  • Réinitialisation du mot de passe (password_query). Sensible au temps. Dix minutes de retard et le client a déjà abandonné.
  • Création de compte (account). Première impression de votre boutique dans leur boîte de réception.

Devraient arriver rapidement

  • Notification d'expédition (shipping). Le numéro de suivi se trouve ici.
  • Mises à jour de l'état de la commande (order_changed). En traitement, expédiée, livrée.
  • Facture et remboursement. Critiques pour le B2B, rassurants pour tous.
Gardez le courrier transactionnel et les newsletters sur des domaines différents. Les e-mails de commande partent de votre domaine principal ; les newsletters depuis un sous-domaine comme news@mail.yourstore.com. Le jour où une newsletter déclenche des plaintes pour spam, elle n'entraîne pas vos confirmations de commande dans sa chute.

Les modèles se trouvent dans mails/{iso_code}/. Chacun possède une version HTML et une version en texte brut. Conservez les deux, un .txt manquant constitue à lui seul un signal de spam, et nous avons vu des modules de traduction les supprimer silencieusement lors d'une synchronisation.

L'hébergement et l'e-mail

Ce que l'hébergement mutualisé ne peut pas corriger

  • Réputation d'IP partagée. Vous partagez une IP avec des centaines d'autres sites et vous ne pouvez pas contrôler ce qu'ils envoient.
  • Plafonds d'envoi. Généralement 100 à 500/heure, 500 à 5 000/jour. Une vente flash les engloutit en quelques minutes.
  • Aucune IP dédiée. Non proposée à ce niveau de prix.
  • Contrôle DNS limité. Les hébergeurs bon marché ne vous laissent parfois pas publier d'enregistrement DKIM, TXT ou PTR personnalisé.
  • Port sortant 587 bloqué. Oui, cela arrive encore, et cela vous empêche de vous connecter à tout service transactionnel.

Ce qu'un VPS vous apporte

  • Une IP dédiée dont la réputation n'appartient qu'à vous
  • Aucune limite d'envoi artificielle
  • Un enregistrement PTR (DNS inverse) : non négociable pour une délivrabilité sérieuse
  • Un contrôle DNS complet, n'importe quel serveur de messagerie de votre choix

Signaux d'alerte côté hébergement

  • « E-mail illimité ». N'existe pas sur l'hébergement mutualisé. Du marketing, rien de plus.
  • Pas de prise en charge DKIM. Passez votre chemin.
  • Port 587 bloqué. Vous ne pouvez utiliser aucun service transactionnel.
  • IP sur liste de blocage. Vérifiez sur MXToolbox avant de souscrire, pas après.
La meilleure stratégie sur un hébergement mutualisé consiste à ignorer entièrement la messagerie de l'hébergeur. Branchez un service transactionnel dans PrestaShop via SMTP. Votre boutique émet alors à travers leur réputation établie, et le problème de l'IP partagée cesse d'exister.

Ce qui a changé dans PrestaShop 8 et 9

PS 8 : l'ultime Swift Mailer

Le dernier Swift Mailer 6.x stable, avec une meilleure négociation TLS, des journaux d'erreurs plus utiles dans var/logs/, et les métadonnées des messages sortants enregistrées dans ps_mail. Test en ligne de commande depuis la console : php bin/console prestashop:mail:test recipient@example.com.

PS 9 : Symfony Mailer

Remplacement complet du transport. Points clés à connaître :

  • Distingue smtp:// (STARTTLS, port 587) de smtps:// (TLS implicite, port 465). Les deux ne sont plus interchangeables.
  • Plus strict sur la correspondance entre l'expéditeur d'enveloppe et l'en-tête From, certains relais SMTP qui fonctionnaient sur PS 8 cessent d'accepter le courrier.
  • Validation plus stricte des certificats TLS. Les certificats auto-signés qui passaient tant bien que mal sur PS 8 échoueront.
  • Les modules qui importaient Swift_Message ou Swift_SmtpTransport cassent sur PS 9 jusqu'à ce que le développeur les mette à jour.
# E-mail PS 9 via variables d'environnement (avancé)
# .env.local : remplace les réglages du panneau d'administration
MAILER_DSN=smtp://user:password@smtp.example.com:587
MAILER_DSN=smtp://user%40gmail.com:app-pass@smtp.gmail.com:587
# Les caractères spéciaux doivent être encodés en URL : @ = %40, : = %3A

Pour le développement local uniquement, avec un certificat auto-signé :

# Désactiver la vérification TLS (JAMAIS en production)
MAILER_DSN=smtp://user:pass@host:587?verify_peer=0

Tests et surveillance

Avant le lancement

mail-tester.com : envoyez un e-mail de test à l'adresse qu'il vous donne, obtenez une note sur 10 avec les problèmes détaillés ligne par ligne. Visez 9 et plus. Gratuit pour 3 tests/jour. Il vérifie SPF, DKIM, DMARC, les listes de blocage, la qualité du HTML, les en-têtes et l'accessibilité des liens.

MXToolbox : diagnostics DNS. Enregistrements MX, validité du SPF et nombre de requêtes, résolution DKIM, politique DMARC, statut des listes de blocage. À garder en favori.

Une fois en production

Google Postmaster Tools : taux de spam, réputation d'IP, réputation de domaine, succès de l'authentification : le tout du point de vue de Gmail lui-même. Gratuit, nécessite que vous vérifiiez le domaine.

Lisez les en-têtes. Dans Gmail : ouvrez le message → les trois points → « Afficher l'original ». Vous voulez voir :

SPF: PASS with IP 1.2.3.4
DKIM: PASS (signature verified)
DMARC: PASS

La cadence que nous suivons : un survol hebdomadaire de ps_mail pour les échecs et un coup d'œil aux rapports DMARC. Une vérification mensuelle sur mail-tester et un balayage des listes de blocage. Une revérification du DNS après chaque changement. Un e-mail de test après chaque mise à jour du cœur de PrestaShop. Les scripts de mise à niveau ont réécrit app/config/parameters.php chez nous plus d'une fois.

Problèmes courants et par où regarder en premier

« L'e-mail de test fonctionne mais les clients ne reçoivent pas les e-mails de commande »

  • Erreur Smarty dans le modèle. Une variable cassée dans le modèle de commande tue silencieusement l'envoi. Vérifiez var/logs/.
  • Modèle de langue manquant. Pas de mails/{lang_iso}/order_conf.html pour la langue du client et PrestaShop n'envoie rien.
  • Délai d'attente SMTP dépassé. Une commande de 30 lignes avec images peut être assez longue à rendre pour que des serveurs SMTP lents coupent la connexion.
  • Rejet de l'adresse d'expéditeur. Certains relais refusent d'émettre tant que le From ne correspond pas à l'utilisateur authentifié.

Limitation de débit

Vous importez 200 commandes ou envoyez une newsletter à un millier de clients ? Votre serveur SMTP prend le premier lot et refuse le reste. Espacez les envois, vérifiez les plafonds du fournisseur, ou passez à un service transactionnel qui met en file d'attente à votre place.

Problèmes d'encodage (diacritiques PL, CZ, DE, FR)

  • Ligne d'objet brouillée. Votre installation doit être en UTF-8 de bout en bout. Les objets sont encodés selon la RFC 2047.
  • Corps brouillé. Les fichiers de modèle d'e-mail doivent être en UTF-8 sans BOM. Notepad sous Windows aime enregistrer en ANSI, utilisez VS Code.
  • Incohérence de base de données. Les tables devraient être en utf8mb4. Confirmez avec SHOW CREATE TABLE ps_product_lang;

Courrier bloqué après une migration de serveur

  • Le SPF pointe encore vers l'ancienne IP
  • Décalage de clé DKIM parce que le nouvel hébergeur a forgé une nouvelle paire de clés
  • La nouvelle IP a une réputation nulle : réchauffez-la progressivement sur deux semaines
  • Port 587 bloqué sur le nouvel hébergeur
  • Propagation DNS : comptez 24 à 48 heures après la modification des enregistrements

Les messages du formulaire de contact n'arrivent pas

Certains modules définissent l'e-mail du client comme adresse From sur le formulaire de contact. Cela échoue au SPF instantanément, votre serveur n'est pas autorisé à émettre en tant que customer@gmail.com. Le From devrait toujours être le domaine de votre boutique, avec le client en Reply-To. Nous avons corrigé cela sur plus de modules de formulaire de contact que nous n'aimerions le compter.

Liste de contrôle de la délivrabilité

Étape 1 : les fondations

  • ☐ Désactiver la fonction PHP mail() et passer à du vrai SMTP
  • ☐ Créer une boîte aux lettres d'envoi dédiée (par exemple orders@yourstore.com)
  • ☐ Envoyer un test vers Gmail et Outlook : les deux doivent atteindre la boîte de réception

Étape 2 : authentification DNS

  • ☐ Publier un enregistrement SPF : le vérifier sur MXToolbox, sous les 10 requêtes
  • ☐ Activer DKIM et publier la clé publique
  • ☐ Ajouter un enregistrement DMARC en p=none avec rapport rua
  • ☐ Ouvrir un message reçu et confirmer que SPF, DKIM et DMARC affichent tous PASS

Étape 3 : qualité

  • ☐ Obtenir 9 et plus sur mail-tester.com
  • ☐ L'IP émettrice sur aucune liste de blocage
  • ☐ Des modèles existent pour chaque langue, en HTML comme en texte brut

Étape 4 : test en conditions réelles

  • ☐ Passer une commande de test : la confirmation atteint la boîte de réception en quelques secondes
  • ☐ La faire passer par chaque état de commande. Chaque e-mail de statut arrive
  • ☐ Tester la réinitialisation du mot de passe, la création de compte, le formulaire de contact

Étape 5 : surveiller

  • ☐ S'inscrire à Google Postmaster Tools
  • ☐ Mettre en place le traitement des rapports DMARC
  • ☐ Faire passer DMARC à p=quarantine au bout de 2 à 4 semaines, puis à p=reject
  • ☐ Une vérification mensuelle de la délivrabilité inscrite au calendrier

Étape 6 : avancé

  • ☐ Passer à un service transactionnel dès que vous atteignez les limites de l'hébergement
  • ☐ Séparer le transactionnel et le marketing sur des domaines distincts
  • ☐ Enregistrement PTR défini si vous êtes sur VPS/dédié
  • ☐ Gestion des rebonds branchée

Chaque couche (SMTP, SPF, DKIM, DMARC, des modèles propres, une IP émettrice réputée) s'empile sur les précédentes. Sautez-en une et toute la structure s'affaiblit. Parcourez la liste de contrôle dans l'ordre, retestez après chaque changement, et vos confirmations de commande atteindront la boîte de réception où est leur place. Pour des diagnostics plus larges, consultez notre guide de dépannage.

À lire également

Modules associés

Questions liées

Retour en haut