Emails de confirmation de commande en spam

Les emails de confirmation de commande sont critiques. Ils confirment la transaction, donnent le numéro de suivi, et rassurent le client. Mais quand ils arrivent en spam, c'est la catastrophe : clients qui paniquent, qui réassayent leur achat, qui cancellent. Pendant ce temps, vous avez l'impression que l'email a bien été envoyé — parce qu'il a réellement quitté votre serveur.

Le problème n'est pas votre contenu. C'est la façon dont vous l'envoyez. Les filtres anti-spam modernes (Orange, Free, Gmail, Outlook, iCloud) examinent en premier : d'où vient vraiment ce message ? Est-il signé ? Est-ce que le domaine d'expédition a une bonne réputation ?

Ce guide vous explique pourquoi ça arrive — et comment corriger.

Pourquoi les emails transactionnels arrivent-ils en spam ?

Un email transactionnel, c'est la réponse automatique à une action utilisateur : confirmation de commande, réinitialisation mot de passe, facture, etc. Contrairement aux newsletters, ce sont des messages très attendus. Mais les filtres anti-spam ne le savent pas.

Depuis février 2024, Google et Yahoo exigent que tout email en masse (y compris les transactionnels) soit signé avec SPF et DKIM. C'est une norme maintenant, suivie par Orange, Free, La Poste, Outlook et les autres. Sans cela, votre email est suspect. Avec une mauvaise configuration, il finit en spam.

Le filtre ne regarde pas le contenu en premier. Il regarde : qui envoie vraiment ? Est-ce légitime ? Vous avez signé ce message ? La réponse à ces questions décide de la destination : boîte de réception ou dossier spam.

Cause 1 : Le domaine du hébergement partagé

Voici le scénario courant. Vous avez un site WordPress ou PrestaShop chez votre hébergeur (OVH, Ionos, Free, 1&1…). Vous installez un plugin de formulaire, ou vous configurez WooCommerce pour les confirmations de commande.

PHP mail() — la fonction par défaut de PHP — envoie l'email. Mais depuis quel domaine ? Du domaine du serveur web : mail.votre-hote.fr. Pas votresite.com, mais le serveur de l'hébergeur.

Le destinataire (Gmail, Orange, Outlook) vérifie : « cet email dit venir de votresite.com, mais le serveur SMTP dit que c'est mail.votre-hote.fr. Ça ne match pas. Spam. »

Pire : le domaine du serveur de l'hébergeur est partagé. Des centaines d'autres sites utilisent le même serveur. Si un seul de ces sites envoie du spam, la réputation du domaine entier souffre — et votre email en pâtit aussi.

Cela affecte :

• WordPress + Contact Form 7 (sans plugin SMTP dédié)
• WooCommerce (sans configuration relais SMTP)
• PrestaShop (par défaut, domaine du serveur)
• Tout formulaire qui utilise wp_mail() ou PHP mail() natif

Cause 2 : SPF, DKIM, DMARC manquants ou malformés

SPF, DKIM et DMARC sont les trois piliers de l'authentification email. Ils répondent à trois questions :

Si vous n'avez pas configuré ces trois, les filtres anti-spam voient des emails 'unsigned'. Même contenu légitime : pas d'authentification = pas de confiance = spam.

Erreur courante : un SPF mal formaté. Exemple : v=spf1 include:brevo.net ~all au lieu du bon format. Gmail et Outlook rejettent d'emblée les formats invalides. Résultat : softfail ou reject immédiat.

La CNIL (Commission nationale de l'informatique et des libertés) recommande en France une authentification forte pour tout email commercial. SPF + DKIM au minimum.

Cause 3 : Configuration du CMS et de la plateforme

Même avec un bon domaine, si la plateforme n'est pas bien configurée, l'email part quand même du mauvais endroit.

WordPress + Contact Form 7 : sans plugin SMTP (WP Mail SMTP, Easy WP SMTP), les emails vont via la fonction wp_mail(), qui hérite du serveur de l'hébergeur.

WooCommerce : par défaut, utilise wp_mail(). Configuration relais SMTP nécessaire.

PrestaShop : legacy, domaine du serveur pour les emails par défaut. Solution : intégrer un SMTP externe (Brevo, Mailjet).

Shopify : oblige à vérifier le domaine (SPF/DKIM Shopify en DNS), sinon emails partagés de faible réputation.

Mailchimp sans domaine d'envoi personnalisé : les emails viennent de domaines partagés (mcsv.net), de mauvaise réputation. Beaucoup de clients Mailchimp en France trouvent leurs emails en spam pour cette raison.

Solutions concrètes : étape par étape

Voici comment corriger.

1. Identifiez votre configuration actuelle.

   Envoyez un email de test. Ouvrez-le dans Gmail ou Outlook, cliquez sur les trois points, « Afficher le message brut ». Cherchez la ligne Return-Path: ou From:. D'où vient vraiment l'email ? Du domaine de l'hébergeur ? Du vôtre ?

2. Mettez en place un relais SMTP.

   Si c'est le domaine de l'hébergeur, envoyer via relais SMTP est la solution. Brevo (Sendinblue), Mailjet, Sarbacane, Mailgun — tous les ESP français proposent un relais SMTP.

   Pour WordPress : installer le plugin WP Mail SMTP, ajouter les credentials du relais SMTP (Brevo, Mailjet, etc.).

   Pour WooCommerce : dans les settings email, configurer SMTP via le même plugin.

   Pour PrestaShop : menu Configuration > Email, ajouter les paramètres SMTP du relais.

3. Ajouter/corriger les enregistrements DNS.

   Connectez-vous à votre registrar (où vous avez enregistré le domaine). Zone DNS.

   SPF : ajouter un enregistrement TXT : v=spf1 include:brevo.net include:mailjet.com ~all (adapter selon votre ESP).

   DKIM : copier la clé publique que votre ESP génère pour vous. Ajouter un enregistrement TXT dans la zone DNS. L'ESP vous explique la syntaxe exacte.

   DMARC : commencer par v=DMARC1; p=none; rua=mailto:compliance@votresite.com. Cela signifie : « observe les échecs, ne rejette pas encore ». Plus tard, vous pourrez passer à p=quarantine ou p=reject.

4. Testez votre configuration.

   Envoyez un email de test. Dans Gmail/Outlook, en affichant le message brut, cherchez les lignes :

   • SPF=PASS (ou au pire SOFTFAIL, mais pas FAIL)
   • DKIM=PASS
   • DMARC=PASS

   Si tous les trois disent PASS, vous êtes bon. Orange, Free, La Poste accorderont aussi la confiance.