Comparateur indépendant · sans classement payant
Accueil / Blog / Email transactionnel : éviter que les reçus de commande disparaissent en spam
Guide

Email transactionnel : éviter que les reçus de commande disparaissent en spam

Les courriels de commande ne partent pas du même domaine que votre newsletter — et ne devraient pas transiter par le SMTP mutualisé du site. SPF, DKIM, DMARC et API dédiée font la différence.

5 min Mis à jour 19 juil. 2026

Un client commande. Paiement OK. Courriel de confirmation introuvable — ni boîte de réception ni spam, parfois rebond silencieux. Le site envoie via mail() PHP sur mutualisé partagé avec quatre cents autres sites. L'email transactionnel n'est pas un email marketing ralenti : c'est un canal contractuel où la délivrabilité vaut directement des ventes et du SAV.

Transactionnel vs marketing

TypeExemplesExigence
TransactionnelConfirmation commande, reset password, factureDélivrabilité > 99 %, latence basse
MarketingNewsletter, promosConsentement, désinscription
Mixte dangereuxPromo dans footer commandeRéputation partagée

Envoyer commandes et newsletters depuis la même adresse IP non préchauffée, c'est demander à Gmail de tout classer « promotion » — ou pire, « spam ». Les filtres ne distinguent pas votre intention ; ils lisent la réputation technique.

Un reçu de commande perdu coûte plus qu'un abonnement API annuel — surtout en période promo.

Stack recommandée

1. Sous-domaine d'envoi. send.marque.fr ou notifications.marque.fr — jamais le domaine principal si le marketing part aussi de chez vous.

2. API fournisseur. Amazon SES, Mailgun, Brevo, Postmark — selon volume et région UE. Choisissez un fournisseur avec journaux de rebond et webhooks.

3. Authentification DNS. - SPF incluant le fournisseur uniquement pour le sous-domaine send ; - clés DKIM du fournisseur ; - DMARC p=quarantine puis reject après analyse des rapports.

4. Application. Plugin WooCommerce/PrestaShop ou configuration SMTP/API — pas mail() nu sur mutualisé.

5. Supervision. Webhooks rebonds, plaintes, tableau de bord fournisseur — alertes si le taux de rebond dépasse 2 %.

Erreurs e-commerce fréquentes

L'expéditeur noreply@domaine.fr sans alignement DKIM sur le domaine. Le SMTP hébergeur avec limite horaire — file de commandes Black Friday bloquée. L'absence de gestion des rebonds — base d'adresses mortes qui dégrade la réputation. Le contenu HTML lourd copié du marketing dans le modèle de commande. Chaque erreur est réparable ; l'accumulation est coûteuse.

WooCommerce / PrestaShop concrètement

Installez un plugin SMTP/API officiel ou WP Mail SMTP configuré en API. Prévoyez une file d'attente asynchrone si le volume augmente — voir WooCommerce Black Friday. Effectuez une commande test sandbox vers Gmail, Outlook et Yahoo. Activez les journaux d'envoi trente jours minimum après lancement.

Testez aussi depuis un mobile 4G : certains opérateurs filtrent différemment des réseaux bureau.

SPF, DKIM, DMARC : l'ordre compte

Configurez d'abord SPF et DKIM sur le sous-domaine send, puis DMARC en mode observation (p=none) pendant une semaine. Analysez les rapports avant de durcir vers quarantine puis reject. Un DMARC trop agressif trop tôt peut bloquer des courriels légitimes pendant que vous déboguez.

Choisir un fournisseur selon le volume

Pour moins de mille courriels transactionnels par mois, Brevo ou Postmark simplifient la prise en main. Au-delà de dix mille envois mensuels, Amazon SES ou Mailgun deviennent souvent plus économiques — à condition d'investir dans la configuration initiale. Vérifiez la région de traitement si vous traitez des données sensibles : un fournisseur avec datacenter européen documenté facilite la due diligence RGPD. Quel que soit le choix, évitez de changer de fournisseur en pleine période commerciale sans période de préchauffage de la réputation.

Le sommet : le client a payé — Gmail ne doit pas décider seul

Séparez aussi messagerie équipe et envoi applicatif : Email professionnel.

Décider et avancer sans angle mort

Choisissez une API transactionnelle avec région UE si les données sont sensibles. Configurez le sous-domaine send plus SPF, DKIM et DMARC avant le lancement — pas la veille. Testez avec mail-tester et visez un score supérieur à neuf sur dix. Surveillez les rebonds pendant au moins un mois après la mise en ligne. Documentez la procédure en cas de changement de fournisseur, pour que l'équipe suivante ne reparte pas de zéro. Prévoyez aussi un scénario de repli SMTP temporaire si l'API est indisponible — une heure sans confirmation de commande en pleine soldes coûte cher.

Questions fréquentes

Pourquoi les emails de commande finissent en spam ?

Authentification DNS, adresse IP partagée, réputation et contenu — souvent une combinaison. Corrigez les trois axes, pas un seul.

SMTP hébergeur ou API transactionnelle ?

L'API convient au volume de commandes ; le SMTP mutualisé reste acceptable pour un faible volume avec configuration stricte.

Faut-il un sous-domaine pour l'envoi ?

Souvent oui pour séparer la réputation transactionnelle et marketing — et simplifier la configuration DNS.

Comment tester la délivrabilité ?

mail-tester, Postmaster Tools, envois multi-fournisseurs, puis surveillance des rebonds pendant un mois minimum.


Quand un client paie, le courriel de confirmation fait partie du produit — traitez-le comme tel, pas comme un fichier journal oublié.

Comparez les hébergeurs européens

Filtrez par conformité, localisation et usage — puis ouvrez les fiches pour vérifier le périmètre réel.

Voir l'annuaire
Blog

À lire aussi

Tous les articles →