Délivrabilité email PrestaShop : SMTP, SPF et DKIM

Pourquoi les e-mails PrestaShop finissent dans les spams

Votre client passe une commande. L’e-mail de confirmation n’arrive jamais — ou il atterrit dans les spams. Le client vous contacte, perplexe. Vous vérifiez PrestaShop : l’e-mail a été « envoyé ». La délivrabilité des e-mails ne dépend pas du fait que PrestaShop envoie l’e-mail — elle dépend du fait que le serveur de messagerie du destinataire l’accepte et le place dans la boîte de réception.

PHP mail() — L’option par défaut que personne ne devrait utiliser

Une installation fraîche de PrestaShop utilise la fonction intégrée mail() de PHP. C’est la pire option pour une boutique en production :

• Aucune authentification : L’e-mail est envoyé sans aucune preuve que vous l’avez autorisé. Gmail, Outlook et Yahoo traitent les e-mails non authentifiés comme suspects.
• Réputation IP partagée : Sur un hébergement mutualisé, vos e-mails proviennent de la même IP que tous les autres sites. Si l’un d’eux envoie du spam, vos e-mails sont pénalisés.
• Pas de signature DKIM : PHP mail() ne signe pas les messages de manière cryptographique.
• En-têtes manquants : Des en-têtes minimaux signifient que les filtres anti-spam signalent immédiatement le message.

Si votre boutique utilise PHP mail() actuellement, passez au SMTP avant toute autre chose. Ce seul changement résout plus de problèmes de délivrabilité que toutes les autres étapes combinées.

Déclencheurs de spam courants

• Incompatibilité de l’adresse expéditeur : Vous envoyez depuis noreply@votreboutique.com mais votre serveur n’a pas d’enregistrement SPF l’autorisant.
• Modèles riches en HTML : Les modèles PrestaShop contiennent beaucoup d’images. Un ratio images/texte élevé déclenche les filtres.
• Alternative texte brut manquante : PS envoie les deux versions, mais les modèles personnalisés ou les modules cassent parfois la partie texte brut.
• Liens cassés : Les filtres anti-spam suivent les liens. Si l’URL de votre boutique est inaccessible (erreur SSL, mode maintenance), l’e-mail est signalé.
• Problèmes d’encodage : Les boutiques utilisant le polonais, le tchèque ou d’autres caractères diacritiques produisent des caractères altérés lorsque l’encodage est incorrect.

Configuration des e-mails PrestaShop

Les paramètres de messagerie ont été déplacés et la bibliothèque sous-jacente a considérablement changé dans la version 9.

PrestaShop 1.6 et 1.7

Accédez à Paramètres avancés → E-mail. Sélectionnez « Définir mes propres paramètres SMTP » et renseignez le serveur, le port, le chiffrement, le nom d’utilisateur et le mot de passe. PS 1.6 utilise la gestion SMTP intégrée de PHP ; PS 1.7 a introduit Swift Mailer pour des connexions plus fiables. Options de chiffrement :

• TLS (port 587) : Standard moderne utilisant STARTTLS. C’est ce que vous devez choisir.
• SSL (port 465) : TLS implicite hérité. Certains hébergeurs anciens l’exigent.
• Aucun (port 25) : Non chiffré. Ne l’utilisez jamais.

PrestaShop 8.x

Même emplacement, même interface. PS 8 utilise la dernière version de Swift Mailer avec un rapport d’erreurs amélioré. Les erreurs SMTP sont journalisées avec plus de contexte dans var/logs/.

PrestaShop 9.x — Symfony Mailer

PS 9 remplace le Swift Mailer obsolète par Symfony Mailer. L’interface d’administration semble similaire, mais la couche de transport est complètement différente :

• Format DSN : Utilise en interne smtp://user:password@server:port.
• Gestion TLS : Détecte automatiquement STARTTLS sur le port 587. Le menu déroulant « chiffrement » peut se comporter différemment après une mise à niveau depuis PS 8.
• Validation plus stricte : Symfony Mailer est plus strict concernant la correspondance entre l’expéditeur de l’enveloppe et l’en-tête From, ainsi que les certificats TLS.
• Compatibilité des modules : Les modules référençant Swift_Message ou Swift_SmtpTransport ne fonctionneront plus sur PS 9.

# PS 9 internal DSN examples (configured via admin UI)
smtp://user:password@mail.example.com:587      # STARTTLS
smtps://user:password@mail.example.com:465     # Implicit TLS
smtp://your%40gmail.com:app-pass@smtp.gmail.com:587  # Gmail
native://default                                # PHP mail() (not recommended)

Après une mise à niveau vers PS 9, testez toujours les e-mails. La migration de Swift Mailer vers Symfony Mailer peut révéler des cas particuliers avec des certificats auto-signés, des ports non standard ou des serveurs SMTP implémentés de manière approximative.

Le bouton d’envoi d’e-mail de test

Chaque version de PS dispose de « Envoyer un e-mail de test ». Utilisez-le, mais sachez qu’il confirme uniquement que la connexion SMTP fonctionne — pas que l’e-mail arrive dans la boîte de réception. Il envoie du texte simple, pas le HTML riche des confirmations de commande. Testez avec Gmail, Outlook et votre propre domaine.

Authentification du domaine — La sainte trinité

SPF, DKIM et DMARC sont des mécanismes d’authentification basés sur le DNS prouvant que vos e-mails sont légitimes. Gmail et Yahoo ont rendu SPF et DKIM obligatoires pour les expéditeurs en masse en février 2024.

SPF (Sender Policy Framework)

SPF indique aux serveurs de réception quelles adresses IP sont autorisées à envoyer des e-mails pour votre domaine — un simple enregistrement TXT dans le DNS.

# Basic — allows hosting + 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

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

Erreurs courantes :

• Plusieurs enregistrements SPF : Un SEUL enregistrement TXT SPF par domaine. Deux enregistrements = les deux invalides. Combinez les services avec plusieurs directives include:.
• Trop de recherches DNS : SPF autorise un maximum de 10 recherches (chaque include: compte, y compris les imbriquées). Utilisez des validateurs SPF pour vérifier.
• +all au lieu de ~all : +all autorise tout le monde à envoyer en tant que votre domaine. Utilisez ~all (softfail) pendant la configuration, puis -all (hardfail) en production.
• Oubli des sous-domaines : Le SPF pour shop.example.com nécessite son propre enregistrement — il n’hérite pas de example.com.

DKIM (DomainKeys Identified Mail)

DKIM ajoute une signature cryptographique à chaque e-mail sortant. PrestaShop ne gère pas DKIM — c’est votre hébergeur, relais SMTP ou service transactionnel qui effectue la signature. Vous publiez la clé publique dans le DNS.

• Hébergement mutualisé (cPanel/Plesk) : Généralement activé automatiquement. Vérifiez dans cPanel → Délivrabilité des e-mails.
• Gmail/Google Workspace : Console d’administration → Gmail → Authentifier les e-mails. Google fournit un enregistrement TXT.
• Services transactionnels : Chacun fournit des enregistrements DNS lors de leur assistant de vérification de domaine.

# DKIM TXT record example
# Name: default._domainkey.yourstore.com (selector varies by provider)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC relie SPF et DKIM et indique aux serveurs quoi faire lorsque l’authentification échoue.

# Stage 1: Monitor only
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com;

# Stage 2: Quarantine failures
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourstore.com;

# Stage 3: Reject failures (maximum protection)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourstore.com;

La balise rua envoie des rapports agrégés — des fichiers XML montrant qui envoie des e-mails en tant que votre domaine. Utilisez Postmark DMARC monitoring pour les transformer en tableaux de bord lisibles.

Déploiement recommandé : p=none pendant 2 à 4 semaines en lisant les rapports. Corrigez les expéditeurs légitimes qui échouent. Passez à p=quarantine pendant 2 à 4 semaines. Puis p=reject. Passer directement à reject dès le premier jour bloque des e-mails dont vous ignoriez l’existence.

Configuration SMTP pour l’hébergement mutualisé

La plupart des boutiques PrestaShop fonctionnent sur un hébergement mutualisé. Créez un compte e-mail dédié (par ex. orders@votreboutique.com) et utilisez ces identifiants.

Paramètres spécifiques aux fournisseurs

# Generic cPanel
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

Gmail SMTP

Nécessite un mot de passe d’application (Compte Google → Sécurité → Vérification en deux étapes → Mots de passe d’application).

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. Un envoi trop rapide déclenche des blocages temporaires.

Gmail SMTP convient aux boutiques traitant moins de 30 commandes par jour. Au-delà, atteindre les limites signifie que vos clients attendent jusqu’à 24 heures pour recevoir la confirmation de commande.

Microsoft 365 SMTP

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 exige de plus en plus OAuth au lieu de l’authentification SMTP basique — vérifiez les paramètres de votre tenant.

Services d’e-mails transactionnels

Lorsque votre boutique dépasse les capacités du SMTP de l’hébergeur, ces services fournissent une infrastructure dédiée à haute réputation, la signature DKIM, la gestion des rebonds et l’analyse des livraisons.

Quand basculer

• Vous atteignez les limites d’envoi de l’hébergeur
• Les e-mails arrivent en spam malgré des enregistrements DNS corrects
• Vous avez besoin du suivi de livraison et de la gestion des rebonds
• La réputation de l’IP mutualisée vous pénalise

Comparaison des services

Mailgun — À partir de 15 $/mois pour 10 000 e-mails. Excellente API, analyses détaillées. SMTP : smtp.mailgun.org:587.

Postmark — À partir de 15 $/mois pour 10 000 e-mails. Meilleurs taux de réception en boîte du secteur. Sépare le transactionnel du marketing. SMTP : smtp.postmarkapp.com:587. Utilisez le Server API Token comme nom d’utilisateur et mot de passe.

Amazon SES — 0,10 $ pour 1 000 e-mails. Le moins cher à grande échelle. Créez les identifiants SMTP dans la console SES (pas les clés d’accès AWS). Les nouveaux comptes démarrent en mode sandbox. Serveur spécifique à la région : 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 apikey, le mot de passe est votre clé API. SMTP : smtp.sendgrid.net:587. Les IP partagées de l’offre gratuite ont une mauvaise réputation — prévoyez le budget pour l’offre payante.

Brevo — Offre gratuite : 300/jour. Payant à partir de 9 $/mois. Newsletter/CRM intégré, basé dans l’UE (RGPD). SMTP : smtp-relay.brevo.com:587. Dispose d’un plugin dédié pour PrestaShop.

Recommandation : Brevo si vous souhaitez également envoyer des e-mails marketing. Postmark si la délivrabilité transactionnelle est votre priorité. Amazon SES pour les gros volumes avec un budget limité. Mailgun comme solution polyvalente.

Intégration

Tous fonctionnent via le SMTP standard — aucun module nécessaire : (1) vérifiez votre domaine, (2) ajoutez leurs enregistrements DNS (SPF, DKIM), (3) générez les identifiants SMTP, (4) saisissez-les dans les paramètres e-mail de PrestaShop, (5) testez.

E-mail auto-hébergé (avancé)

Gérer votre propre serveur de messagerie offre un contrôle total — aucune limite tierce, pas de frais par e-mail, confidentialité complète. Nous utilisons Mailcow nous-mêmes. Mais le coût en temps et en expertise est réel.

Quand c’est pertinent

• Confidentialité : Toutes les données e-mail restent sur votre serveur. Important dans le cadre d’un RGPD strict.
• Volume : À plus de 100 000 e-mails/mois, un VPS à 40 $/mois est plus avantageux que n’importe quel service transactionnel.
• Contrôle : Règles personnalisées, aucune limite arbitraire, pas de suspension de compte.

Quand ce n’est pas le cas

• Pas d’expérience sysadmin : Un serveur de messagerie mal configuré est pire qu’un hébergement mutualisé.
• Nouvelles IP : Construire une réputation à partir de zéro prend des semaines. Les services transactionnels vous offrent une réputation établie immédiatement.
• Pas d’enregistrement PTR : Sans DNS inverse, la plupart des serveurs rejettent vos e-mails directement.
• Charge de maintenance : Correctifs, certificats, surveillance des listes noires, journaux — un travail continu.

Options

Mailcow : Basé sur Docker, inclut webmail, antispam, antivirus, autodiscover. Nécessite 4 Go+ de RAM. Notre choix.

Mail-in-a-Box : Tout-en-un sur un serveur Ubuntu dédié. Plus simple mais monopolise la machine.

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

Commencez par utiliser l’e-mail auto-hébergé pour votre propre entreprise pendant 3 mois avant d’y acheminer les e-mails des boutiques clients. Construisez votre réputation progressivement. Gardez un service transactionnel en secours.

Types d’e-mails dans PrestaShop

Critiques — Doivent arriver immédiatement

• Confirmation de commande (order_conf) : L’e-mail le plus important. S’il arrive en spam, attendez-vous à des rétrocharges et une perte de confiance.
• Confirmation de paiement (payment) : Les clients sont anxieux tant qu’ils ne voient pas cet e-mail.
• Réinitialisation du mot de passe (password_query) : Sensible au temps. Si cela prend 10 minutes, le client est parti.
• Création de compte (account) : La première impression de votre boutique.

Importants — Doivent arriver rapidement

• Notification d’expédition (shipping) : Contient les informations de suivi.
• Mises à jour du statut de commande (order_changed) : En cours de traitement, expédié, livré.
• Facture et remboursement : Nécessaires pour le B2B et la réassurance client.

Séparez les e-mails transactionnels et marketing. Utilisez votre domaine principal pour les e-mails de commande et un sous-domaine (news@mail.votreboutique.com) pour les newsletters. Cela évite que les plaintes de spam liées aux newsletters nuisent à la réputation de vos confirmations de commande.

Les modèles se trouvent dans mails/{iso_code}/. Chacun possède une version HTML (.html) et une version texte brut (.txt). Maintenez toujours les deux — une alternative texte brut manquante est un signal de spam.

Choix de l’hébergement pour les e-mails

Limitations de l’hébergement mutualisé

• Réputation IP partagée : Vous partagez une IP avec plus de 200 sites. Si l’un envoie du spam, vos e-mails sont pénalisés. Vous ne pouvez pas contrôler cela.
• Limites d’envoi : Généralement 100 à 500/heure et 500 à 5 000/jour. Les ventes flash et les newsletters épuisent rapidement ces quotas.
• Pas d’IP dédiée : Non disponible en hébergement mutualisé. Point final.
• Contrôle DNS limité : Certains hébergeurs bon marché restreignent les enregistrements DKIM, TXT ou PTR personnalisés.
• Ports bloqués : Certains hébergeurs bloquent le port sortant 587, empêchant la connexion aux services transactionnels.

Avantages d’un VPS

• IP dédiée avec votre propre réputation
• Aucune limite d’envoi artificielle
• Enregistrement PTR (DNS inverse) — essentiel pour la délivrabilité
• Contrôle DNS complet, n’importe quel serveur de messagerie de votre choix

Signaux d’alerte

• « E-mails illimités » : Cela n’existe pas en hébergement mutualisé.
• Pas de support DKIM : Fuyez.
• Port 587 bloqué : Impossible d’utiliser les services transactionnels.
• IP sur liste noire : Vérifiez sur MXToolbox avant de vous engager.

Meilleure stratégie pour l’hébergement mutualisé : ignorez complètement la messagerie de l’hébergeur. Utilisez un service transactionnel via SMTP. Votre boutique envoie à travers leur infrastructure à haute réputation, contournant entièrement le problème de l’IP partagée.

Nouveautés dans PrestaShop 8 et 9

PS 8 : Dernière version de Swift Mailer

PS 8 utilise la dernière version stable de Swift Mailer 6.x. Négociation TLS améliorée, meilleurs journaux d’erreurs dans var/logs/, et métadonnées d’e-mail dans ps_mail. Test en ligne de commande : php bin/console prestashop:mail:test recipient@example.com.

PS 9 : Symfony Mailer

Remplacement complet de la couche de transport. Changements clés :

• Distingue smtp:// (STARTTLS, port 587) de smtps:// (TLS implicite, port 465)
• Plus strict sur la correspondance entre l’expéditeur de l’enveloppe et l’en-tête From
• Validation des certificats TLS plus stricte — les certificats auto-signés qui fonctionnaient sous PS 8 peuvent échouer
• Les modules utilisant les classes Swift Mailer (Swift_Message, etc.) ne fonctionnent plus et doivent être mis à jour

# PS 9 email via environment variables (advanced)
# .env.local — overrides admin panel settings
MAILER_DSN=smtp://user:password@smtp.example.com:587
MAILER_DSN=smtp://user%40gmail.com:app-pass@smtp.gmail.com:587
# Special chars must be URL-encoded: @ = %40, : = %3A

Pour les certificats auto-signés en environnement de développement :

# Disable TLS verification (NEVER in 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 à leur adresse et obtenez un score sur 10 avec les problèmes spécifiques. Visez 9+. Gratuit pour 3 tests/jour. Vérifie SPF, DKIM, DMARC, listes noires, qualité HTML, en-têtes et liens.

MXToolbox : Diagnostics DNS — enregistrements MX, validité SPF et nombre de recherches, résolution DKIM, politique DMARC, statut des listes noires.

En continu

Google Postmaster Tools : Affiche le taux de spam, la réputation IP, la réputation du domaine, le succès de l’authentification du point de vue de Gmail. Gratuit, nécessite la vérification du domaine.

En-têtes d’e-mail : Dans Gmail, ouvrez l’e-mail → trois points → « Afficher l’original ». Recherchez :

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

Planning : vérification hebdomadaire de ps_mail pour les échecs et les rapports DMARC. Contrôle mensuel sur mail-tester.com et des listes noires. Revérifiez le DNS après chaque modification. Testez les e-mails après chaque mise à jour de PrestaShop.

Problèmes courants et solutions

« L’e-mail de test fonctionne mais les clients ne reçoivent pas les commandes »

• Erreur de rendu du modèle : Une erreur Smarty dans le modèle de commande empêche silencieusement l’envoi. Vérifiez var/logs/.
• Modèle manquant : Le modèle pour la langue du client n’existe pas dans mails/{lang_iso}/.
• Délai d’attente SMTP : Les confirmations de commande volumineuses (nombreux produits) dépassent le délai sur les connexions SMTP lentes.
• Adresse expéditeur rejetée : Les serveurs SMTP qui exigent que l’adresse expéditeur corresponde à l’utilisateur authentifié.

Limitation du débit

Vous importez 200 commandes ou envoyez une newsletter à 1 000 abonnés ? Votre serveur SMTP accepte le premier lot et rejette le reste. Espacez les envois, vérifiez les limites du fournisseur, ou utilisez un service transactionnel qui gère automatiquement la mise en file d’attente.

Problèmes d’encodage (polonais/tchèque/caractères spéciaux)

• Objet altéré : Assurez-vous que votre installation utilise UTF-8 partout. Les objets sont encodés au format RFC 2047.
• Contenu du modèle cassé : Les fichiers de modèle d’e-mail doivent être en UTF-8 sans BOM. Le Bloc-notes Windows peut enregistrer en ANSI — utilisez VS Code.
• Incohérence de base de données : Les tables doivent utiliser utf8mb4. Vérifiez : SHOW CREATE TABLE ps_product_lang;

E-mails bloqués après une migration

• SPF non mis à jour avec la nouvelle IP du serveur
• Clé DKIM incompatible — le nouvel hébergeur a généré de nouvelles clés
• La nouvelle IP n’a pas de réputation — préchauffez-la progressivement sur 2 semaines
• Port 587 bloqué sur le nouvel hébergeur
• Propagation DNS — attendez 24 à 48 heures après les modifications

Le formulaire de contact n’arrive pas

Certains modules définissent l’e-mail du client comme adresse expéditeur. Cela échoue au niveau SPF car votre serveur ne peut pas envoyer depuis client@gmail.com. L’expéditeur doit toujours être le domaine de votre boutique, avec le client en Reply-To.

Checklist de délivrabilité des e-mails

Étape 1 : Fondations

• ☐ Passer de PHP mail() au SMTP
• ☐ Créer une adresse d’envoi dédiée (par ex. orders@votreboutique.com)
• ☐ Envoyer un e-mail de test à Gmail et Outlook — les deux doivent arriver en boîte de réception

Étape 2 : Authentification DNS

• ☐ Ajouter un enregistrement SPF — vérifier sur MXToolbox, moins de 10 recherches
• ☐ Activer DKIM et publier la clé dans le DNS
• ☐ Ajouter un enregistrement DMARC avec p=none et le reporting rua
• ☐ Vérifier les en-têtes d’e-mail — les trois doivent afficher PASS

Étape 3 : Contrôle qualité

• ☐ Obtenir un score de 9+ sur mail-tester.com
• ☐ IP absente des listes noires
• ☐ Les modèles existent pour toutes les langues, en version HTML et texte brut

Étape 4 : Tests en conditions réelles

• ☐ Passer une commande de test — l’e-mail de confirmation arrive en boîte de réception en quelques secondes
• ☐ Faire passer la commande par chaque statut — chaque e-mail arrive
• ☐ Tester la réinitialisation de mot de passe, la création de compte et le formulaire de contact

Étape 5 : Surveillance

• ☐ S’inscrire sur Google Postmaster Tools
• ☐ Mettre en place le traitement des rapports DMARC
• ☐ Passer DMARC à p=quarantine après 2 à 4 semaines, puis p=reject
• ☐ Planifier des contrôles mensuels de délivrabilité

Étape 6 : Avancé

• ☐ Migrer vers un service transactionnel si vous atteignez les limites de l’hébergeur
• ☐ Séparer les e-mails transactionnels et marketing sur des domaines différents
• ☐ Définir l’enregistrement PTR si vous êtes sur un VPS/serveur dédié
• ☐ Implémenter la gestion des rebonds

Chaque couche — SMTP, SPF, DKIM, DMARC, modèles propres, IP réputée — renforce votre crédibilité. En négliger une affaiblit l’ensemble du système. Suivez cette checklist méthodiquement, testez après chaque modification, et les e-mails de votre boutique PrestaShop atteindront la boîte de réception. Pour les étapes de diagnostic générales, consultez notre guide de dépannage.