« On a payé une commande, le client ne reçoit pas la confirmation. » C’est probablement le ticket support le plus fréquent sur les boutiques PrestaShop en 2026 — et c’est presque toujours un problème de délivrabilité, pas un bug applicatif. Depuis février 2024, Gmail et Yahoo ont durci leurs exigences pour les expéditeurs en masse, et l’écosystème suit. Hotmail, Outlook, Apple iCloud appliquent désormais des contrôles équivalents.
Pour une boutique e-commerce, l’enjeu n’est pas marginal : un email de confirmation qui finit en spam, c’est un client qui rappelle, un agent support qui gère, un risque de litige et un rétrogradage de la réputation domaine qui dégrade tous les emails suivants. Voici la mise au point complète sur les règles 2026, les vérifications à faire sur sa propre boutique, et les corrections concrètes.
Les règles applicables en 2026 — synthèse opérationnelle
Trois mécanismes d’authentification sont aujourd’hui exigés ou exigibles selon le volume :
- SPF (Sender Policy Framework) : enregistrement DNS qui liste les serveurs autorisés à envoyer du courrier pour le domaine. Soft fail (~all) toléré, hard fail (-all) recommandé une fois la migration validée.
- DKIM (DomainKeys Identified Mail) : signature cryptographique de chaque email avec une clé privée, vérifiable via une clé publique publiée en DNS. Indispensable.
- DMARC (Domain-based Message Authentication, Reporting & Conformance) : politique publiée en DNS qui dit aux serveurs destinataires ce qu’il faut faire des emails qui échouent SPF ou DKIM. p=none = monitoring, p=quarantine = spam, p=reject = rejet pur.
Depuis février 2024, Gmail et Yahoo exigent DMARC publié (au minimum p=none) pour tout expéditeur dépassant 5 000 emails par jour. Outlook et iCloud ont suivi en 2025. À partir d’avril 2025, Gmail a commencé à filtrer plus agressivement les expéditeurs en p=none qui ne progressent pas vers une politique stricte au bout de plusieurs mois.
En 2026, la trajectoire est claire : DMARC p=quarantine ou p=reject est en train de devenir le standard de fait, même pour les expéditeurs sous le seuil de 5 000 emails/jour. Les boutiques qui restent en p=none verront leur délivrabilité se dégrader progressivement.
BIMI : le bonus visuel qui devient un signal de réputation
BIMI (Brand Indicators for Message Identification) permet d’afficher le logo de la marque dans la boîte de réception (rond bleu Gmail, vignette Apple Mail). Pour l’activer, il faut :
- Une politique DMARC en p=quarantine ou p=reject (pas p=none).
- Un logo SVG carré au format SVG Tiny Portable/Secure (.svg).
- Idéalement un certificat VMC (Verified Mark Certificate) émis par DigiCert ou Entrust — payant, autour de 1 200 € à 1 800 € HT par an — pour activer l’affichage chez Gmail et Apple Mail.
Au-delà de l’aspect cosmétique, BIMI envoie aux filtres anti-spam un signal de sérieux et de continuité d’identité. Les boutiques BIMI gagnent en moyenne 2 à 4 points de taux d’ouverture sur les newsletters, et marginalement sur le transactionnel (où le taux d’ouverture est déjà très haut).
Pourquoi vos emails PrestaShop finissent en spam — les six causes principales
1. Envoi via le serveur web par défaut (PHP mail)
PHP mail() depuis un serveur partagé OVH, o2switch, Hetzner ou cPanel quelconque : IP partagée avec des centaines de domaines, pas de signature DKIM par défaut, pas de boucle de rétroaction. Cause numéro un de mise en quarantaine immédiate par Gmail.
La règle saine en 2026 : tous les emails passent par un SMTP authentifié, qu’il soit chez Brevo, Mailjet, Sendgrid, Postmark, AWS SES, Scaleway TEM, ou un SMTP self-hosted bien configuré. Cela impose à PrestaShop d’utiliser le module Symfony Mailer en mode SMTP.
2. SPF non aligné
SPF correct sur le domaine d’envoi, mais l’adresse Return-Path pointe sur un sous-domaine non couvert. Résultat : SPF passe mais ne s’aligne pas avec le From visible. DMARC échoue. Le diagnostic se fait avec un rapport DMARC aggregate (RUA) : on voit immédiatement le décalage.
3. DKIM expirée ou rotation oubliée
La clé DKIM publiée en DNS doit être en rotation périodique (semestrielle ou annuelle). Beaucoup de boutiques l’installent au lancement puis l’oublient. Au bout de quelques années, la clé est compromise statistiquement (longueurs 1024 bits historiquement) et Gmail commence à pénaliser. Il faut une rotation propre, généralement gérée par le fournisseur SMTP.
4. Contenu HTML mal conçu
Email avec trop de liens vers des domaines tiers, ratio texte/image inversé (image en bandeau qui couvre 80 % du contenu, peu de texte), URL raccourcies (bit.ly et autres), absence de version texte plain. Ces signaux sont individuellement faibles, cumulés ils déclenchent les filtres bayésiens.
5. Volume erratique et listes mal entretenues
Boutique qui envoie un email transactionnel par jour pendant trois mois, puis 50 000 newsletters d’un coup. Pic atypique → suspicion. Et si la liste contient des adresses inactives ou des hard bounces non purgés, le taux de plaintes monte. Au-dessus de 0,3 %, Gmail commence à filtrer.
6. Listes empoisonnées
Adresses spam-trap (anciennes adresses recyclées par les FAI pour piéger les spammeurs). Une seule adresse spam-trap touchée plombe la réputation domaine pour plusieurs semaines. La prévention : double opt-in obligatoire, nettoyage régulier, validation au moment de la saisie (vérifier que l’adresse répond avant inscription).
La checklist de mise au propre en 2026 — séquence en 6 étapes
Étape 1 — Audit de l’existant
Vérifier ses enregistrements DNS avec dmarcian, MXToolbox ou Postmark DNS checker : SPF correct, DKIM publié, DMARC publié et lisible. Tester un envoi vers une adresse Gmail personnelle et inspecter les en-têtes (Authentication-Results) pour vérifier le pass/fail.
Étape 2 — Mise en place d’un SMTP transactionnel authentifié
Brevo, Mailjet, Postmark ou AWS SES selon le volume. Configurer PrestaShop via le module Symfony Mailer (PS 8.1+) ou via un module SMTP tiers. Valider l’envoi d’un email test de la boutique : confirmation de commande, reset mot de passe, alerte prix.
Étape 3 — Activation de DMARC en p=none avec reporting
Publier l’enregistrement DMARC avec p=none et l’attribut rua qui pointe vers une adresse dédiée ([email protected]) ou un service de monitoring (dmarcian, Postmark DMARC, OnDMARC). Laisser tourner 2 à 4 semaines pour collecter les rapports aggregate.
Étape 4 — Analyse des rapports DMARC et correction des fuites
Les rapports identifient tous les services tiers qui envoient pour le domaine : SMTP transactionnel, plateforme newsletter, outil de support (Zendesk, Crisp), CRM, paie. Chacun doit être autorisé en SPF et signer en DKIM aligné. C’est l’étape qui prend le plus de temps en pratique.
Étape 5 — Passage à p=quarantine puis p=reject
Une fois les rapports DMARC propres (>95 % d’alignement), monter en p=quarantine pendant 4 à 8 semaines, puis p=reject. À chaque palier, surveiller les bounces et les tickets clients.
Étape 6 — BIMI et certificat VMC (optionnel mais utile)
Une fois en p=quarantine ou p=reject stable, publier un enregistrement BIMI avec logo SVG. Acheter un VMC si la marque est protégée (marque déposée) et que le volume justifie l’investissement.
Le filtrage anti-spam interne — un sujet souvent oublié
Côté entrant, une boutique reçoit beaucoup de spam (contact form, faux devis, faux ordre…) qui pollue les BAL des équipes commerciales et qui parfois s’égare dans la base CRM. Un filtre de qualité côté entrant améliore la productivité et la sécurité (phishing entrant).
Côté DataFirefly, le module dfemailfilter applique un filtrage anti-spam serveur sur les domaines hébergés, avec règles SPF/DKIM/DMARC entrantes, score bayésien et liste noire dynamique. Utile pour le formulaire de contact PrestaShop et les emails B2B.
Conclusion : la délivrabilité comme métrique e-commerce de premier rang
Beaucoup de marchands traitent l’email comme un sujet « informatique » à déléguer. C’est une erreur en 2026. La délivrabilité conditionne désormais : la conversion (panier abandonné non récupéré si l’email n’arrive pas), le support (tickets « je n’ai pas reçu ma facture »), la rétention (newsletters qui finissent au spam = relation client cassée), et la conformité (RGPD : preuve de consentement par double opt-in seulement valide si l’email arrive).
Une mise à niveau SPF/DKIM/DMARC propre prend 4 à 8 semaines de travail concentré et apporte généralement 5 à 15 points de taux d’ouverture côté marketing, sans toucher au contenu. C’est l’un des meilleurs ROI techniques de l’année.
