Les e-mails de votre boutique n'arrivent pas : SMTP, SPF, DKIM et DMARC expliqués

« Je n'ai pas reçu la confirmation de commande. » Si vous l'entendez souvent, le problème ne vient pas du client. Les fournisseurs de messagerie (Gmail, Outlook, Yahoo et les autres) sont de plus en plus stricts avec les messages qu'ils reçoivent, et un e-mail qui ne prouve pas clairement d'où il vient finit en spam ou est purement et simplement rejeté. Pour une boutique, cela veut dire des clients inquiets, des appels au service client et des mots de passe que personne ne peut récupérer.

Voyons comment PrestaShop envoie les e-mails et ce qu'il faut configurer pour qu'ils arrivent.

Comment PrestaShop envoie les e-mails

Dans Paramètres avancés → E-mail, vous choisissez comment le courrier part :

• La fonction mail de PHP du serveur. C'est l'option par défaut et la plus pratique, mais l'e-mail part du serveur web, qui bien souvent n'est pas autorisé à envoyer au nom de votre domaine. C'est la cause la plus fréquente des e-mails en spam.
• Un serveur SMTP. La boutique se connecte avec un identifiant et un mot de passe à une vraie boîte mail (celle de votre fournisseur de messagerie ou d'un service d'envoi transactionnel) et envoie par son intermédiaire. C'est l'option recommandée.

Sur ce même écran, vous pouvez envoyer un e-mail de test. Utilisez-le après chaque modification, et envoyez-le à des boîtes de plusieurs fournisseurs.

Les trois vérifications que fait le destinataire

SPF : qui peut envoyer au nom de votre domaine

C'est un enregistrement TXT dans le DNS de votre domaine qui énumère les serveurs autorisés à envoyer des e-mails avec votre domaine comme expéditeur. Quand un e-mail arrive, le destinataire regarde de quel serveur il provient et s'il figure dans cette liste.

Erreurs typiques :

• Avoir deux enregistrements SPF sur le même domaine. Il ne peut y en avoir qu'un ; s'il y en a deux, la vérification échoue. Quand vous ajoutez un nouveau service, on complète l'enregistrement existant, on n'en crée pas un autre.
• Ne pas inclure tous les expéditeurs : le serveur de la boutique, le fournisseur de messagerie, l'outil de newsletter, l'ERP qui envoie les factures.
• Dépasser la limite de requêtes. SPF autorise au maximum dix requêtes DNS lors de son évaluation, et chaque include compte (avec ceux qu'il contient). Avec beaucoup de services, on la dépasse sans s'en rendre compte.

DKIM : la signature du message

Le serveur d'envoi signe chaque e-mail avec une clé privée et publie la clé publique dans le DNS de votre domaine. Le destinataire vérifie la signature : si elle correspond, le message vient bien de celui qu'il prétend et n'a pas été modifié en chemin.

C'est le fournisseur qui envoie (votre service de messagerie ou d'envoi transactionnel) qui l'active et vous donne l'enregistrement à ajouter au DNS. Si vous utilisez la fonction mail de PHP du serveur web, il n'y a normalement pas de signature DKIM, ou alors elle porte le domaine de l'hébergeur, et non le vôtre.

DMARC : que faire en cas d'échec, et en être informé

C'est un autre enregistrement TXT, sur _dmarc.tudominio, qui indique aux destinataires quoi faire d'un e-mail se réclamant de votre domaine mais qui ne passe pas SPF ou DKIM de façon alignée (c'est-à-dire avec le même domaine que l'expéditeur visible). Il a trois politiques :

• p=none : ne fais rien de particulier, informe-moi seulement.
• p=quarantine : traite-le comme suspect (en général, en spam).
• p=reject : rejette-le.

Il peut aussi demander des rapports à l'une de vos adresses, dans lesquels les fournisseurs vous indiquent quels e-mails avec votre domaine ils ont reçus et s'ils passaient les vérifications. C'est la façon de découvrir des services qui envoient en votre nom et que vous aviez oubliés, ou quelqu'un qui usurpe votre domaine.

La prudence veut que l'on commence par p=none, que l'on examine les rapports pendant quelques semaines jusqu'à ce que tout ce qui est légitime passe, puis que l'on durcisse.

Pourquoi c'est plus important aujourd'hui

Les grands fournisseurs de messagerie ont progressivement durci leurs exigences. Depuis 2024, Gmail et Yahoo imposent aux expéditeurs de gros volumes d'avoir SPF, DKIM et DMARC, et aux autres au moins une authentification correcte. Même si votre boutique n'envoie pas des milliers d'e-mails par jour, si votre outil de newsletter le fait avec votre domaine, c'est tout le domaine qui est concerné. Et sans authentification, il est de plus en plus probable qu'un e-mail de commande n'arrive pas dans la boîte de réception.

Autres causes de non-réception

• Réputation du serveur ou de l'IP : s'il partage une IP avec d'autres qui envoient du spam, tout le monde en pâtit.
• Contenu : e-mails constitués d'une seule image, liens raccourcis, beaucoup de texte en majuscules ou objets agressifs. Les e-mails de commande doivent être sobres et avoir une version texte brut.
• Mélanger e-mails de commande et promotions dans le même envoi et avec le même expéditeur. Si les newsletters génèrent des plaintes, elles entraînent les e-mails transactionnels avec elles.
• Boîte pleine ou adresse mal saisie par le client. Valider l'e-mail à l'inscription et examiner les rebonds aide sur ce point.
• Limites du SMTP : beaucoup de boîtes ordinaires limitent le nombre d'e-mails envoyés par heure ou par jour. Lors de grosses campagnes, la boutique peut se heurter à ce plafond.

Comment le vérifier

1. Envoyez un e-mail de test depuis la boutique vers une boîte Gmail et ouvrez le message original : vous verrez si SPF, DKIM et DMARC apparaissent en PASS et avec quel domaine.
2. Consultez les enregistrements TXT de votre domaine avec n'importe quel outil DNS et vérifiez qu'il y a un seul SPF et un DMARC.
3. Dressez la liste de tout ce qui envoie des e-mails avec votre domaine et vérifiez que chacun signe avec DKIM et figure dans le SPF.
4. Examinez les rapports DMARC pendant quelques semaines avant de passer à quarantine ou reject.

Comment le résoudre dans PrestaShop

La délivrabilité dépend du DNS et du serveur de messagerie ; le contenu, des templates. RKR Mail Editor comprend un éditeur visuel des e-mails de PrestaShop avec lequel vous modifiez l'objet, le HTML et la version texte brut de chaque template dans chaque langue, et il ajoute aux e-mails de commande des produits recommandés, un bon de réduction unique pour le prochain achat et des bannières par campagne, avec un lien de désinscription dans chaque e-mail contenant des blocs commerciaux. Si vous avez besoin de configurer le SMTP de la boutique, de revoir votre SPF, d'activer DKIM avec votre fournisseur ou de mettre en place DMARC sans perdre d'e-mails, nous le vérifions et le laissons opérationnel avec un forfait d'heures de support Rekire.