2026 : les e-mails de commande d’un site indépendant arrivent dans les spams, faut-il vérifier SPF ou DKIM en premier ?

Un client affirme ne pas avoir reçu sa confirmation de commande, alors que votre boutique affiche une commande payée.

Verdict — adapté si vous vérifiez dans l’ordre le déclenchement, le journal du prestataire d’envoi, puis SPF, DKIM et DMARC ; inadapté si vous modifiez les DNS avant de savoir si le message a réellement été envoyé.

Cet article s’adresse aux responsables de boutiques en ligne qui doivent distinguer une notification jamais générée d’un message remis dans les courriers indésirables. Il concerne aussi les équipes qui viennent de changer de service d’envoi ou doivent contrôler plusieurs domaines d’expédition.

Dernière mise à jour : 5 novembre 2026. Les éléments de norme et les indications d’envoi ont été vérifiés dans les documents officiels liés ci-dessous.

La délivrabilité des e-mails dépend d’abord de la preuve d’envoi, pas du premier réglage DNS

Pour une notification de commande, l’ordre de diagnostic compte. Vérifiez d’abord si la boutique a créé le message et si le prestataire tiers l’a enregistré comme envoyé. Ensuite seulement, confrontez les résultats SPF et DKIM à l’adresse visible dans le champ From, puis examinez la politique DMARC.

Cette séquence évite une erreur fréquente : modifier SPF parce qu’un client dit ne rien avoir reçu. La même plainte peut correspondre à des situations différentes : l’événement de commande n’a pas déclenché la notification, l’application a échoué à remettre le message au prestataire, le serveur destinataire l’a refusé ou le message a été placé dans les indésirables. La documentation officielle de dépannage des e-mails WooCommerce décrit plusieurs de ces étapes et ne réduit donc pas l’absence de message à un problème d’authentification DNS.

Commencez par rattacher l’incident à une commande identifiable. Notez son état, l’heure de création et le type de notification attendu : confirmation, facture ou avis d’expédition. Dans WooCommerce, examinez les réglages de notification associés au type de commande et vérifiez si le message a été déclenché. Si votre installation utilise un journal d’e-mails ou une extension de journalisation, cherchez-y l’événement correspondant. L’absence d’entrée ne prouve pas à elle seule la cause, mais elle oriente d’abord vers le déclenchement ou l’application plutôt que vers le classement en courrier indésirable.

Un enregistrement d’envoi distingue l’échec applicatif du problème de remise

Quand vous ne trouvez aucune trace dans la boutique ni chez le prestataire, ne commencez pas par réécrire les enregistrements du domaine. Vérifiez l’activation de la notification, ses destinataires, les événements associés à l’état de la commande et les journaux applicatifs disponibles. Un échec au moment où l’application transmet le message peut aussi être lié au connecteur ou à sa configuration.

Si le prestataire affiche au contraire un événement d’envoi, relevez son identifiant, son horodatage, son statut et la réponse éventuelle du serveur destinataire. Un statut « envoyé » décrit le traitement effectué par le prestataire ; il ne garantit pas que le message soit arrivé dans la boîte principale, ni même qu’il ait été accepté par le système de réception. Vérifiez séparément les dossiers de courrier indésirable et de quarantaine. Lorsque le destinataire accepte de vous aider, demandez-lui l’en-tête complet d’un message test : les résultats d’authentification qui y figurent sont plus utiles qu’une supposition tirée du seul emplacement du message.

Les instructions WooCommerce sur la configuration des services d’envoi aident à distinguer le rôle de l’application et celui du prestataire. Elles ne remplacent toutefois pas les journaux propres au service que vous avez choisi : les statuts, réponses et étapes visibles dépendent de son interface.

SPF autorise une source d’envoi, mais ne corrige pas un domaine mal configuré

Après avoir confirmé que le message a bien été transmis au prestataire, vérifiez la configuration SPF du domaine concerné. Comparez l’identité utilisée pour l’envoi avec les instructions DNS actuelles du service tiers. Vérifiez également si le domaine sert à d’autres usages d’envoi : ajouter une nouvelle source sans recenser les précédentes peut rompre une configuration qui fonctionnait déjà.

SPF ne se configure pas en recopiant une valeur trouvée dans un tutoriel conçu pour un autre service. Utilisez le nom d’hôte et la valeur demandés par votre prestataire, puis recherchez les enregistrements TXT publiés pour le domaine exact qui intervient dans l’authentification. Le standard RFC 7208 sur SPF définit notamment une limite de dix termes nécessitant des recherches DNS lors de l’évaluation SPF. Si les autorisations imbriquées conduisent à dépasser cette limite, le résultat peut échouer ; supprimer au hasard une source d’envoi n’est pas une correction sûre.

Pour voir ce qui est publié, vous pouvez interroger le DNS depuis un terminal :

dig TXT "$DOMAINE" +short

La sortie doit être comparée à la configuration documentée par le service réellement utilisé. Le modèle ci-dessous montre seulement le type de valeur à rechercher ; il ne constitue pas un enregistrement à publier :

v=spf1 [mécanisme indiqué par le prestataire] [politique existante]

Contrôlez qu’il n’existe pas plusieurs enregistrements SPF distincts pour le même domaine, puis identifiez les autres services légitimes qui envoient encore pour votre organisation. Ne remplacez pas la valeur existante sans savoir à quoi elle sert : un site peut utiliser plusieurs sources légitimes, par exemple pour les notifications commerciales et les messages transactionnels d’autres applications. Les consignes de WooCommerce sur l’authentification des e-mails rappellent que ces réglages relèvent du domaine et du service d’envoi configuré.

DKIM validé ne signifie pas automatiquement domaine From aligné

DKIM permet de vérifier une signature associée au message et à un domaine de signature. Il faut donc lire le résultat dans l’en-tête du message reçu, puis comparer le domaine de signature à celui qui apparaît dans l’adresse visible par le client. Le standard RFC 6376 sur DKIM décrit la signature et sa vérification ; cette validation et l’alignement exigé par DMARC sont deux contrôles distincts.

Dans l’en-tête complet d’un message test, repérez les champs d’authentification, le domaine DKIM et le résultat annoncé par le destinataire. Comparez ensuite ces informations avec le domaine du champ From. Si la signature est valide mais utilise un domaine différent, ne concluez pas que l’ensemble de l’authentification est satisfaisant pour DMARC : examinez l’alignement effectif et la configuration demandée par le prestataire.

Vérifiez aussi que le sélecteur DKIM indiqué dans la signature correspond à un enregistrement publié dans le DNS. Le nom du sélecteur et la valeur de la clé doivent venir de la console ou de la documentation du service utilisé ; ils ne sont pas interchangeables entre prestataires. Si vous venez de modifier une entrée, vérifiez qu’elle est visible dans le DNS interrogé et que le message test a été signé après la mise à jour. Une ancienne copie d’en-tête n’atteste pas la configuration actuelle.

Les exigences ne doivent pas être généralisées à partir d’une seule boîte de réception. Le guide officiel destiné aux expéditeurs Gmail distingue les exigences applicables à l’ensemble des expéditeurs de celles qui concernent les expéditeurs en nombre. Il indique notamment un seuil de plus de 5 000 messages par jour envoyés vers des comptes Gmail pour la catégorie concernée et précise des exigences d’authentification et d’alignement. Ce seuil se rapporte à ces règles Gmail ; il ne définit pas une obligation identique pour toutes les plateformes de réception.

DMARC donne une règle au destinataire, sans garantir la boîte principale

DMARC s’appuie sur les résultats SPF et DKIM et leur alignement avec le domaine du champ From. Il permet aussi au propriétaire du domaine de publier une politique et de recevoir des rapports, selon la configuration choisie. La publication d’une politique stricte avant d’avoir inventorié tous les émetteurs légitimes risque de perturber des messages qui ne proviennent pas de la boutique elle-même.

Avant de changer cette politique, examinez les résultats SPF et DKIM dans les messages de test et les rapports disponibles. Identifiez les services qui utilisent le domaine : notifications de commande, facturation, gestion de la relation client ou autres applications autorisées. Si une source légitime échoue à l’alignement, corrigez d’abord sa configuration auprès du prestataire concerné. Les rapports sont un outil d’observation ; ils ne corrigent ni une signature incorrecte ni une source oubliée.

En mai 2026, le RFC 9989 sur DMARC a remplacé les RFC 7489 et 9091 comme texte de référence. Cette évolution actualise le document de norme ; elle ne signifie pas que toutes les boutiques doivent remplacer leur service d’envoi ou modifier automatiquement leurs enregistrements DNS. Pour votre cas, partez des résultats observés et des indications officielles applicables au destinataire.

Le tableau suivant associe les symptômes aux preuves à recueillir avant toute modification. Il ne remplace pas les journaux de votre prestataire : il sert à éviter de traiter un problème de déclenchement comme un échec SPF, ou un classement en indésirable comme une erreur DNS.

Une authentification réussie ne garantit pas une arrivée en boîte principale

SPF, DKIM et DMARC attestent certains aspects de l’autorisation ou de l’identité d’un message. Ils ne constituent pas une promesse de classement en boîte de réception. Si les résultats sont satisfaisants, recherchez plutôt la réponse de la plateforme destinataire, une éventuelle quarantaine, les plaintes ou les retours des utilisateurs, ainsi que les modifications récentes de contenu ou de configuration. Ces signaux doivent être examinés dans leur contexte : une observation sur une boîte ne décrit pas nécessairement le comportement de toutes les autres.

Réalisez un test avec une commande contrôlée, sans envoyer de messages non sollicités. Consignez l’heure, l’état de la commande, le destinataire de test, l’événement enregistré chez le prestataire et les résultats d’authentification de l’en-tête reçu. Recommencez avec des boîtes de réception que vous contrôlez chez différents services, si cela est possible. Vous pourrez alors comparer les résultats sans confondre une acceptation par le prestataire d’envoi avec une livraison dans la boîte principale.

Si l’un des messages est refusé, transmettez au prestataire son identifiant d’événement, l’heure, la réponse du serveur de destination et les résultats SPF, DKIM et DMARC. Évitez de ne communiquer que l’adresse du client ou une capture de la boîte de réception : ces éléments ne permettent pas toujours d’identifier l’étape de l’échec. Si le message est accepté mais classé comme indésirable, indiquez-le précisément ; ce cas n’est pas équivalent à un refus de remise.

Pour contrôler plusieurs domaines, créez une fiche par domaine utilisé dans From : service concerné, identité d’envoi, résultat SPF, domaine DKIM, alignement DMARC, date de la vérification et réponse du destinataire. Cette méthode évite qu’une configuration correcte sur un domaine masque un oubli sur un autre. Elle facilite aussi l’examen des changements DNS : vous pouvez relier chaque résultat au domaine concerné plutôt que d’appliquer une modification générale à l’ensemble de vos zones.

Les limites du serveur d’hébergement ne remplacent pas celles du service d’envoi

Le serveur qui héberge la boutique et le prestataire qui transmet ses notifications remplissent des rôles distincts. Si la boutique dépend d’un service tiers, l’authentification du domaine et l’observation de la remise passent d’abord par ce service et par la configuration DNS. La location d’un serveur physique ne crée pas, à elle seule, une signature DKIM, un enregistrement SPF adapté, une réputation d’expéditeur ou une garantie d’arrivée en boîte principale.

Avant une migration ou un changement d’hébergement, consignez les paramètres de l’application, les notifications activées, le domaine From et les résultats obtenus chez le prestataire. Après le changement, répétez le test de commande et comparez les journaux avant et après. Pour distinguer les responsabilités de l’hébergement de celles d’un service applicatif, vous pouvez consulter les limites des services proposés. Si vous devez aussi contrôler l’accès à un environnement serveur pendant une migration, les modalités d’accès au shell sont à examiner séparément : elles ne remplacent pas la console du prestataire d’envoi.

Questions fréquentes sur les notifications de commande

Dans quel ordre vérifier une notification envoyée aux clients ?

Établissez d’abord si la notification a été déclenchée, puis si le service tiers en a enregistré l’envoi. Après cette confirmation, contrôlez SPF et DKIM dans l’en-tête, puis l’alignement DMARC avec le domaine From. Cet ordre évite de changer le DNS alors que le message n’a jamais quitté l’application, et permet de transmettre au prestataire des preuves exploitables.

Un statut « envoyé » prouve-t-il que le client a reçu le message ?

Non. Le statut peut indiquer que le prestataire a traité ou transmis la demande, sans prouver que le système destinataire l’a acceptée ou classée dans la boîte principale. Recherchez le détail de l’événement et la réponse de destination, puis demandez au client de contrôler les indésirables et la quarantaine. L’en-tête d’un message test fournit des indices complémentaires sur l’authentification.

Que faire après avoir changé de service d’envoi ?

Vérifiez les entrées DNS exigées par le nouveau service, mais conservez d’abord l’inventaire des sources qui utilisent encore le domaine. Confirmez ensuite SPF et DKIM avec un message test envoyé par la boutique, puis examinez l’alignement DMARC. Ne réutilisez pas les valeurs de l’ancien service sans confirmation : une entrée devenue inutile ou un service oublié peut provoquer un échec inattendu.

DMARC validé signifie-t-il que tous les clients verront le message dans leur boîte principale ?

Non. Un résultat DMARC valide indique que les contrôles et l’alignement ont satisfait les critères correspondants pour le message examiné. Le destinataire peut néanmoins appliquer ses propres règles de filtrage, de réputation et de classement. Comparez les journaux et les en-têtes de plusieurs tests autorisés ; ne déduisez pas le comportement de toutes les plateformes à partir d’un seul compte.

Décider à partir des preuves, puis choisir le bon interlocuteur

• Si aucun événement d’envoi n’existe dans la boutique ou chez le prestataire, vérifiez le déclenchement, la notification concernée et les journaux de l’application.
• Si le prestataire a enregistré un envoi et que SPF échoue, comparez l’enregistrement DNS au paramétrage officiel du service réellement utilisé ; ne reprenez pas la valeur d’un autre prestataire.
• Si DKIM est validé mais que DMARC échoue, comparez le domaine de signature au domaine From et demandez au prestataire de confirmer l’alignement attendu.
• Si les authentifications passent mais que le message est refusé, transmettez au service d’envoi la réponse du destinataire et l’identifiant de l’événement.
• Si le message est accepté mais arrive dans les indésirables, documentez ce classement, examinez les retours disponibles et vérifiez les résultats sur des boîtes que vous contrôlez avant de modifier la politique DMARC.

Pour une boutique en production, conservez ces résultats avec la procédure de contrôle des messages transactionnels : elle vous aidera à comparer les réglages avant et après une modification DNS ou une migration. Si vous examinez également l’hébergement, la commande et la préparation d’une boîte de service ne doivent pas être confondues avec l’envoi des notifications de commande : celui-ci reste lié au prestataire tiers et à l’authentification du domaine.

Si votre hébergement partagé limite le contrôle des ressources ou complique l’exploitation d’une boutique durable, vous pouvez comparer cette solution à la location d’un serveur physique AMD dédié auprès d’OSFP Cloud. Ce choix porte sur l’environnement serveur et l’exclusivité des ressources, pas sur la transmission des messages ni sur leur placement en boîte principale. Pour le problème décrit ici, commencez donc par la preuve d’envoi, les journaux du prestataire et les résultats de domaine ; ne changez d’hébergement que si vos besoins d’exploitation le justifient également.

Questions

Par quoi commencer quand les e-mails de commande arrivent dans les spams ?

Commencez par vérifier si le message a été généré et si le service d’envoi l’a pris en charge. Consultez le journal de la boutique, puis celui du prestataire. Si aucun envoi n’apparaît, recherchez un problème de déclenchement ou de configuration de l’application. Si l’envoi est enregistré, examinez les résultats SPF et DKIM, l’alignement DMARC et la réponse du destinataire.

Que vérifier si le prestataire indique que le message est envoyé, mais que le client ne le reçoit pas ?

Un statut d’envoi ne prouve pas que le message est arrivé dans la boîte principale. Relevez l’identifiant de l’événement, l’heure, la réponse du serveur destinataire et tout statut de rejet ou de mise en attente. Demandez aussi au destinataire de vérifier les courriers indésirables et la quarantaine. Ces éléments permettent de distinguer un refus d’une remise classée comme indésirable.

Un service d’envoi tiers nécessite-t-il quand même des enregistrements SPF et DKIM ?

Oui, si le service vous demande de publier des informations d’authentification pour votre domaine. Suivez les valeurs et les noms d’hôte indiqués dans sa documentation, puis vérifiez-les dans le DNS et dans l’en-tête d’un message test. Ne copiez pas une valeur prévue pour un autre prestataire : les autorisations et les sélecteurs DKIM dépendent de la configuration réellement utilisée.

Pourquoi un e-mail peut-il aller dans les spams même lorsque DMARC est validé ?

DMARC indique si SPF ou DKIM est validé avec un domaine aligné sur l’adresse visible dans le champ From, selon la politique publiée. Ce résultat n’impose pas au destinataire de placer le message dans la boîte principale. La réputation, les plaintes, le contenu, les règles locales et les signaux propres au destinataire peuvent encore influer sur le classement ou le refus.