Les entreprises de commerce électronique dépendent d’e-mails de confiance.

Les clients reçoivent des confirmations de commande, des liens de réinitialisation de mot de passe, des mises à jour d’expédition, des avis de remboursement, des alertes de compte, des notifications de paiement, des messages d’assistance et des campagnes marketing. Si des attaquants peuvent usurper ces messages, se faire passer pour la boutique ou exploiter une authentification e-mail faible, ils peuvent nuire à la confiance des clients et créer des risques de sécurité évitables.

Pour les commerçants Shopify et WooCommerce, la sécurité des e-mails n’est pas seulement une question de délivrabilité.

Elle fait partie de la protection du parcours client autour du paiement, de l’accès au compte et de la communication post-achat.

La norme PCI DSS ne cite pas DMARC, SPF ou DKIM comme protocoles obligatoires autonomes. Cependant, l’exigence 5.4.1 de PCI DSS v4.0.1 requiert des processus et des mécanismes automatisés pour détecter et protéger le personnel contre les attaques de phishing. L’authentification des e-mails peut soutenir cet objectif anti-phishing dans le cadre d’un programme de sécurité et de conformité plus large.

Le bon cadrage est simple :

DMARC ne rend pas à lui seul une entreprise de commerce électronique conforme à la norme PCI DSS. Mais DMARC, SPF, DKIM, MTA-STS et TLS-RPT peuvent aider à réduire l’usurpation de domaine, améliorer la visibilité de l’expéditeur et fournir la preuve que l’authentification des e-mails est surveillée et maintenue.

Pour les commerçants e-commerce, c’est important.

Un faux e-mail de notification de commande, de demande de remboursement, de mise à jour de facture ou de réinitialisation de mot de passe peut devenir le point de départ d’une attaque plus large contre les clients, le personnel ou les flux de paiement.

I. Pourquoi l’authentification des e-mails est importante pour l’e-commerce

Les e-mails e-commerce véhiculent la confiance.

Un client s’attend à ce que les messages de votre boutique soient légitimes. Un agent d’assistance s’attend à ce que les alertes internes soient fiables. Une équipe financière s’attend à ce que les e-mails de facturation proviennent de systèmes connus. Un propriétaire de boutique s’attend à ce que les applications tierces envoient des messages en toute sécurité.

Les attaquants exploitent cette confiance.

Les menaces courantes par e-mail dans l’e-commerce incluent :

• Faux e-mails de confirmation de commande
• Phishing de remboursement et de rétrofacturation
• Usurpation de réinitialisation de mot de passe
• Fausses notifications d’expédition
• Fraude au paiement fournisseur
• Usurpation d’assistance client
• Phishing d’administrateur de boutique
• Phishing de panier abandonné
• Abus de domaines similaires
• Usurpation de domaine exact

DMARC aide à traiter un risque spécifique mais important : les attaquants envoyant des e-mails qui semblent provenir de votre vrai domaine.

Lorsqu’il est correctement mis en œuvre, DMARC permet aux serveurs de messagerie récepteurs d’évaluer si un message prétendant provenir de votre domaine est authentifié et aligné.

Cela aide à protéger le domaine visible que les clients voient dans l’adresse De.

II. Contexte PCI DSS : ce que l’authentification des e-mails soutient

La norme PCI DSS se concentre sur la protection des données de titulaires de carte et le maintien d’environnements de paiement sécurisés.

L’authentification des e-mails ne protège pas directement les données de titulaires de carte stockées. Elle ne remplace pas les contrôles de passerelle de paiement, la configuration de paiement sécurisé, les contrôles d’accès, la gestion des vulnérabilités ou les protections anti-malware.

Mais elle peut soutenir les objectifs de sécurité PCI DSS de plusieurs manières pratiques.

Contrôles anti-phishing

L’exigence 5.4.1 de PCI DSS v4.0.1 se concentre sur les processus et mécanismes automatisés pour détecter et protéger le personnel contre les attaques de phishing.

DMARC, SPF et DKIM peuvent y contribuer en réduisant la capacité des attaquants à usurper des domaines de boutique de confiance par e-mail.

Protection d’accès

Les e-mails de réinitialisation de mot de passe, les alertes administrateur et les messages de vérification de compte font souvent partie du flux de travail d’accès pour les plateformes de commerce électronique.

Si ces e-mails peuvent être usurpés, les attaquants peuvent inciter le personnel ou les clients à saisir des identifiants sur de fausses pages.

Risque fournisseur et tiers

Les applications Shopify, les plugins WooCommerce, les CRM, les outils d’assistance, les plateformes d’avis, les services de marketing par e-mail et les fournisseurs d’e-mails transactionnels peuvent tous envoyer des e-mails au nom d’une boutique.

Les rapports DMARC aident à identifier quels services envoient, lesquels sont correctement alignés et lesquels nécessitent une correction.

Surveillance et preuve

Les rapports DMARC peuvent fournir la preuve que l’organisation surveille l’authentification des e-mails, identifie les sources non autorisées et progresse vers l’application.

Cette preuve peut soutenir les examens de sécurité, les audits internes, les évaluations de fournisseurs et la documentation de conformité.

III. Shopify vs WooCommerce : Responsabilités différentes

Shopify et WooCommerce ont des modèles d’exploitation différents.

Cela affecte la façon dont les commerçants abordent l’authentification des e-mails.

IV. Responsabilités de sécurité des e-mails Shopify

Shopify fournit une plateforme de commerce hébergée. Cela réduit la responsabilité d’infrastructure pour le commerçant, mais cela ne supprime pas le besoin de gérer l’authentification des e-mails au niveau du domaine.

Les commerçants Shopify doivent toujours comprendre :

• Quel domaine est utilisé pour les e-mails destinés aux clients
• Si Shopify est autorisé à envoyer au nom du domaine
• Si les applications Shopify tierces envoient des e-mails
• Si les plateformes marketing utilisent le même domaine
• Si les outils d’assistance envoient depuis le domaine de la boutique
• Si les rapports DMARC sont surveillés
• Si le domaine progresse vers l’application

Shopify gère de nombreux contrôles au niveau de la plateforme, mais l’identité de votre domaine reste votre responsabilité.

Si les clients reçoivent des e-mails de [email protected], ce domaine doit être protégé.

V. Responsabilités de sécurité des e-mails WooCommerce

WooCommerce est généralement auto-géré via l’hébergement WordPress et les plugins connectés.

Cela crée plus de flexibilité, mais aussi plus de responsabilité.

Les commerçants WooCommerce doivent gérer :

• Configuration de messagerie WordPress
• Sélection du fournisseur SMTP
• E-mails générés par les plugins
• Comportement de messagerie de l’hébergement
• Livraison d’e-mails transactionnels
• Enregistrements DNS d’authentification
• Configuration DKIM
• Autorisation SPF
• Rapports DMARC
• Services d’e-mails tiers
• Sécurité de l’accès administrateur et des plugins

Les boutiques WooCommerce doivent éviter de s’appuyer sur le mail PHP par défaut pour les e-mails transactionnels importants. Un fournisseur SMTP dédié ou d’e-mails transactionnels avec prise en charge SPF, DKIM et DMARC est généralement une approche plus sûre et plus fiable.

VI. Étape 1 : Cartographier tous les flux d’e-mails e-commerce

Avant de modifier les enregistrements DNS, cartographiez toutes les sources qui envoient des e-mails pour la boutique.

Incluez les messages destinés aux clients, au personnel et aux fournisseurs.

Les sources courantes incluent :

• E-mails transactionnels Shopify
• E-mails de commande WooCommerce
• E-mails système WordPress
• Fournisseurs SMTP
• Plateformes marketing
• Outils de panier abandonné
• Applications de demande d’avis
• Outils d’assistance et de billetterie
• Plateformes CRM
• Outils d’expédition et d’exécution
• Plateformes d’abonnement
• Plugins de marketplace
• Systèmes de facturation et comptabilité
• Systèmes de notification de paiement
• Outils d’alerte de sécurité
• Fournisseurs de boîtes aux lettres du personnel

Pour chaque expéditeur, documentez :

• Plateforme d’envoi
• Propriétaire métier
• Type de message
• Domaine d’envoi
• Domaine Return-Path
• Domaine de signature DKIM
• Autorisation SPF
• Statut d’alignement DMARC
• Volume de messages
• Criticité métier
• Contact support fournisseur

Cet inventaire est la base d’une application sûre.

Sans cela, un commerçant peut accidentellement bloquer des confirmations de commande, des réinitialisations de mot de passe ou des e-mails d’assistance légitimes.

VII. Étape 2 : Configurer SPF avec soin

SPF identifie quels serveurs sont autorisés à envoyer des e-mails pour un domaine.

Un exemple simplifié pourrait ressembler à ceci :

v=spf1 include:shops.shopify.com include:_spf.google.com include:sendgrid.net ~all

Ceci n’est qu’un exemple. Les commerçants ne doivent pas le copier aveuglément.

L’enregistrement SPF correct dépend des services réels envoyant des e-mails pour le domaine.

Directives importantes pour SPF :

• Inclure uniquement les expéditeurs autorisés.
• Éviter les includes inutiles.
• Rester dans la limite de 10 recherches DNS.
• Supprimer les anciens fournisseurs qui n’envoient plus d’e-mails.
• Ne pas s’appuyer uniquement sur SPF pour DMARC.
• Passer à -all uniquement après avoir identifié et testé les expéditeurs légitimes.

SPF peut être fragile car il dépend du domaine Return-Path et de l’IP d’envoi. Il peut également se casser dans les scénarios de transfert.

C’est pourquoi DKIM est souvent la meilleure base à long terme pour l’alignement DMARC.

VIII. Étape 3 : Activer DKIM pour chaque expéditeur majeur

DKIM ajoute une signature cryptographique aux e-mails sortants.

Pour DMARC, le point clé est l’alignement.

Le domaine de signature DKIM doit s’aligner avec le domaine De visible chaque fois que possible.

Pour les commerçants Shopify, confirmez que Shopify et toutes les applications connectées ou plateformes externes prennent en charge l’envoi authentifié pour votre domaine.

Pour les commerçants WooCommerce, configurez DKIM via le fournisseur SMTP ou d’e-mails transactionnels. La plupart des fournisseurs professionnels génèrent des enregistrements DNS qui doivent être ajoutés au domaine.

Vérifications DKIM courantes :

• DKIM est-il activé ?
• Quel sélecteur est utilisé ?
• Le domaine DKIM d= s’aligne-t-il avec le domaine De ?
• Les expéditeurs tiers signent-ils avec votre domaine ou le leur ?
• Les clés DKIM sont-elles suffisamment fortes pour les normes actuelles du fournisseur ?
• Existe-t-il un processus de rotation documenté ?
• Les anciens sélecteurs sont-ils supprimés lorsqu’ils ne sont plus utilisés ?

Une plateforme tierce peut signer avec son propre domaine. Cela peut authentifier le fournisseur, mais cela peut ne pas aider votre résultat DMARC à moins que le domaine DKIM ne s’aligne avec votre domaine De visible.

IX. Étape 4 : Démarrer la surveillance DMARC

DMARC connecte l’authentification SPF et DKIM au domaine De visible.

Un message passe DMARC lorsqu’au moins l’une des conditions suivantes est vraie :

• SPF passe et le domaine authentifié SPF s’aligne avec le domaine De visible.
• DKIM passe et le domaine de signature DKIM s’aligne avec le domaine De visible.

Commencez par la surveillance avant l’application.

Un enregistrement de surveillance DMARC statique traditionnel peut ressembler à ceci :

v=DMARC1; p=none; rua=mailto:[email protected]

Cet enregistrement peut fonctionner, mais seulement si les rapports sont activement reçus, analysés, examinés et traités.

Pour la plupart des commerçants, les rapports XML DMARC bruts sont difficiles à gérer manuellement.

La meilleure approche consiste à démarrer la surveillance DMARC via Skysnag et obtenir un enregistrement DMARC gratuit généré pour votre domaine :

Skysnag aide les commerçants à identifier les expéditeurs légitimes, détecter les sources non autorisées, corriger les lacunes d’authentification et progresser vers l’application en toute confiance.

Évitez d’activer les rapports médico-légaux via ruf= par défaut. Les rapports d’échec peuvent créer des problèmes de confidentialité et de conservation et ont une adoption limitée parmi les principaux récepteurs. Utilisez-les uniquement après examen de la confidentialité, juridique et de la sécurité.

X. Étape 5 : Configurer l’authentification des e-mails Shopify

Les commerçants Shopify doivent commencer par examiner le domaine utilisé pour la communication de la boutique.

Dans l’administration Shopify, examinez vos paramètres de domaine et confirmez quel domaine est utilisé pour les e-mails destinés aux clients.

Les tâches clés incluent :

• Vérifier la propriété du domaine personnalisé.
• Confirmer que Shopify est autorisé à envoyer des e-mails pour le domaine.
• Examiner les enregistrements DNS recommandés par Shopify.
• Confirmer si les e-mails Shopify passent l’alignement SPF ou DKIM.
• Identifier les applications Shopify qui envoient des e-mails séparément.
• S’assurer que les outils marketing et d’assistance sont inclus dans l’inventaire des expéditeurs.
• Surveiller les rapports DMARC après les modifications DNS.

Les applications Shopify méritent une attention particulière.

Les catégories d’applications courantes qui peuvent envoyer des e-mails incluent :

• Applications de panier abandonné
• Applications de demande d’avis
• Plateformes de fidélité
• Outils d’abonnement
• Applications d’assistance client
• Outils de notification d’expédition
• Outils de facturation
• Applications de marketplace ou de gros

Chaque application doit soit envoyer depuis un domaine authentifié qui s’aligne avec votre domaine de boutique, soit utiliser son propre domaine clairement marqué lorsque cela est approprié.

Ne supposez pas que chaque application hérite automatiquement de l’authentification Shopify.

XI. Étape 6 : Configurer l’authentification des e-mails WooCommerce

Les commerçants WooCommerce doivent éviter d’envoyer des e-mails critiques via un mail d’hébergement non authentifié ou un mail PHP par défaut.

Une meilleure approche consiste à utiliser un fournisseur SMTP dédié ou d’e-mails transactionnels.

Les fournisseurs d’e-mails WooCommerce courants incluent :

• Amazon SES
• SendGrid
• Mailgun
• Postmark
• SMTP.com
• Brevo
• MailerSend
• SMTP Google Workspace
• SMTP Microsoft 365

Étapes de configuration :

• Choisir un fournisseur qui prend en charge SPF, DKIM et l’authentification de domaine personnalisé.
• Installer et configurer un plugin SMTP fiable.
• Définir l’adresse De sur un domaine que vous contrôlez.
• Ajouter les enregistrements DNS SPF et DKIM du fournisseur.
• Envoyer des messages de test à Gmail, Outlook et d’autres fournisseurs.
• Confirmer l’alignement SPF, DKIM et DMARC.
• Surveiller les rapports DMARC pour les e-mails générés par WooCommerce et les plugins.

Exemple d’enregistrement SPF pour un fournisseur SMTP WooCommerce :

v=spf1 include:spf.votrefournisseur.example ~all

Exemple de format d’enregistrement DKIM :

selecteur._domainkey.votreboutique.com TXT "v=DKIM1; k=rsa; p=VOTRE_CLE_PUBLIQUE"

Ces exemples sont des espaces réservés. Utilisez les enregistrements exacts fournis par votre fournisseur d’e-mails.

XII. Étape 7 : Sécuriser le contenu des e-mails e-commerce

L’authentification des e-mails protège l’identité du domaine, mais les commerçants doivent également réduire l’exposition des données sensibles dans les e-mails.

Bonnes pratiques :

• Ne pas inclure les numéros de carte complets dans les e-mails.
• Éviter d’exposer des détails de paiement inutiles.
• Utiliser des références de paiement masquées si nécessaire.
• Diriger les clients vers des portails sécurisés pour les actions de compte sensibles.
• Éviter les liens de connexion qui semblent suspects ou incohérents.
• Utiliser une marque et des adresses d’expéditeur cohérentes.
• Garder les e-mails de commande et de remboursement clairs et prévisibles.
• Examiner les modèles d’e-mails après les modifications de plugins.
• Supprimer les données client inutiles des modèles.
• Éviter d’inclure des détails d’administration sensibles dans les alertes internes.

Pour l’alignement PCI DSS, les e-mails ne doivent pas devenir un canal où les données de paiement sensibles sont inutilement exposées.

XIII. Étape 8 : Progresser vers l’application DMARC

La surveillance n’est pas l’objectif final.

Une fois que les expéditeurs légitimes sont identifiés et alignés, la boutique doit progresser vers l’application.

Un chemin pratique :

1. Commencer par la surveillance DMARC.
2. Identifier tous les expéditeurs légitimes.
3. Corriger les lacunes d’alignement SPF et DKIM.
4. Examiner les applications Shopify, les plugins WooCommerce et les outils tiers.
5. Passer les sous-domaines à faible risque à p=quarantine.
6. Surveiller l’impact.
7. Passer le domaine principal à p=quarantine lorsque prêt.
8. Passer les domaines matures à p=reject après une confiance soutenue.

Avant l’application, confirmez :

• Les confirmations de commande passent DMARC.
• Les e-mails de réinitialisation de mot de passe passent DMARC.
• Les e-mails d’assistance client passent DMARC.
• Les e-mails marketing passent DMARC ou utilisent un domaine authentifié distinct.
• Les applications tierces sont documentées.
• Les fournisseurs sont alignés.
• Les procédures de retour arrière existent.
• Les rapports DMARC sont activement surveillés.

Évitez de vous fier au déploiement basé sur un pourcentage comme stratégie principale. Les programmes actuels conscients de DMARC doivent mettre en œuvre l’application par domaine, sous-domaine, groupe d’expéditeurs et fonction métier.

XIV. Étape 9 : Ajouter MTA-STS et TLS-RPT

DMARC protège l’authentification de l’expéditeur. Il n’impose pas le transport chiffré entre les serveurs de messagerie.

MTA-STS et TLS-RPT aident à renforcer la couche de transport.

MTA-STS permet à un domaine de publier une politique exigeant que les serveurs de messagerie prenant en charge utilisent TLS lors de la livraison du courrier au domaine.

TLS-RPT fournit des rapports sur les problèmes de livraison TLS.

Pour les commerçants e-commerce, ces contrôles peuvent soutenir une posture de confiance e-mail plus forte pour les communications de compte, d’assistance, de commande et opérationnelles.

Exemple de politique MTA-STS :

version: STSv1
mode: enforce
mx: mail.votreboutique.com
max_age: 86400

Exemple d’enregistrement TLS-RPT :

_smtp._tls.votreboutique.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Ceux-ci doivent être mis en œuvre avec soin et testés avant l’application.

XV. Étape 10 : Maintenir les preuves PCI DSS

L’authentification des e-mails doit être documentée dans le cadre du programme de sécurité plus large.

Les preuves utiles peuvent inclure :

• Inventaire des domaines
• Inventaire des expéditeurs
• Enregistrements SPF, DKIM et DMARC
• Enregistrements MTA-STS et TLS-RPT
• Rapports de surveillance DMARC
• Tendances de réussite/échec d’authentification
• Enquêtes sur les expéditeurs non autorisés
• Examens des expéditeurs tiers
• Enregistrements de modification DNS
• Procédures de réponse aux incidents
• Résultats des tests de sécurité des e-mails
• Documentation fournisseur
• Preuve de sensibilisation à la sécurité et de protection contre le phishing
• Historique de politique d’application

Pour les discussions PCI DSS, la formulation la plus sûre est :

« L’authentification des e-mails soutient les contrôles anti-phishing, de protection de domaine et d’intégrité des communications dans le cadre du programme de sécurité PCI DSS plus large de l’organisation. »

Évitez de prétendre que DMARC seul satisfait PCI DSS.

XVI. Calendrier de surveillance et d’examen

Les environnements e-commerce changent constamment.

De nouvelles applications sont installées. Les plateformes marketing changent. Les plugins sont mis à jour. Les fournisseurs SMTP font pivoter l’infrastructure. Les agences lancent des campagnes. Le personnel connecte de nouveaux outils.

Un calendrier d’examen aide à prévenir la dérive.

Hebdomadaire

• Examiner les échecs d’authentification DMARC.
• Vérifier les sources d’envoi inconnues.
• Examiner les problèmes de livraison pour les e-mails de commande et de réinitialisation de mot de passe.
• Enquêter sur les changements soudains dans le volume d’envoi.

Mensuel

• Examiner les applications tierces et les plugins qui envoient des e-mails.
• Valider les includes SPF et supprimer les services inutilisés.
• Confirmer l’alignement DKIM pour les principaux expéditeurs.
• Examiner l’état de préparation à l’application DMARC.

Trimestriel

• Valider les enregistrements DNS.
• Examiner l’accès des fournisseurs et l’inventaire des expéditeurs.
• Tester les flux d’e-mails critiques.
• Examiner les procédures de réponse aux incidents.
• Mettre à jour la documentation de conformité.

Annuel

• Réévaluer les risques de sécurité des e-mails.
• Examiner les preuves PCI DSS.
• Valider tous les domaines et sous-domaines.
• Examiner la conservation des données et la gestion des rapports.
• Confirmer que la posture d’application reste appropriée.

XVII. Erreurs courantes à éviter

Les commerçants e-commerce commettent souvent les mêmes erreurs.

Évitez celles-ci :

• Publier DMARC mais ne jamais examiner les rapports.
• Utiliser p=none indéfiniment.
• Activer ruf= sans examen de confidentialité.
• Supposer que les applications Shopify héritent de l’authentification Shopify.
• Permettre aux plugins WooCommerce de contourner le SMTP authentifié.
• Ajouter trop d’includes SPF et dépasser les limites de recherche.
• Oublier les anciens domaines de campagne ou régionaux.
• Utiliser le même domaine pour tous les e-mails transactionnels et marketing sans segmentation.
• Passer à l’application avant que les e-mails de réinitialisation de mot de passe et de commande ne soient alignés.
• Traiter DMARC uniquement comme une solution de délivrabilité.
• Prétendre que DMARC seul satisfait PCI DSS.

Ces erreurs créent des risques inutiles.

XVIII. Comment Skysnag Protect aide les commerçants e-commerce

Skysnag Protect aide les entreprises de commerce électronique à gérer DMARC, SPF, DKIM, MTA-STS, TLS-RPT et l’état de préparation à l’application dans des environnements d’envoi complexes.

Pour les commerçants Shopify et WooCommerce, Skysnag Protect prend en charge :

• Surveillance DMARC
• Génération gratuite d’enregistrements DMARC
• Découverte d’expéditeurs
• Détection d’expéditeurs non autorisés
• Visibilité de l’alignement SPF et DKIM
• Examen des applications et fournisseurs tiers
• Visibilité des sous-domaines
• Suivi de l’état de préparation à l’application
• Prise en charge MTA-STS et TLS-RPT
• Rapports axés sur la conformité
• Preuves pour les examens et audits de sécurité

Au lieu d’analyser manuellement les rapports XML ou de deviner quels fournisseurs envoient des e-mails, les commerçants peuvent voir quelles sources sont légitimes, lesquelles échouent et quels domaines sont prêts pour l’application.

Démarrez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit :

En savoir plus sur Skysnag Protect :

XIX. Liste de vérification de mise en œuvre

Utilisez cette liste de vérification comme point de départ pratique.

• [ ] Inventorier tous les domaines et sous-domaines utilisés par la boutique.
• [ ] Identifier toutes les applications Shopify, plugins WooCommerce et plateformes tierces qui envoient des e-mails.
• [ ] Documenter le propriétaire métier, le type de message et la criticité de chaque expéditeur.
• [ ] Configurer SPF uniquement pour les expéditeurs autorisés.
• [ ] Examiner les limites de recherche DNS SPF.
• [ ] Activer DKIM pour Shopify, les fournisseurs SMTP WooCommerce et les expéditeurs tiers.
• [ ] Confirmer qu’au moins une méthode d’authentification s’aligne avec le domaine De visible.
• [ ] Démarrer la surveillance DMARC via Skysnag ou une autre destination de rapport surveillée.
• [ ] Éviter les rapports médico-légaux sauf si les équipes de confidentialité, juridique et de sécurité l’approuvent.
• [ ] Examiner les e-mails de confirmation de commande, de réinitialisation de mot de passe, de remboursement et d’assistance.
• [ ] Corriger les expéditeurs légitimes qui échouent DMARC.
• [ ] Passer les domaines matures vers p=quarantine.
• [ ] Passer à p=reject une fois que le courrier légitime est constamment aligné.
• [ ] Mettre en œuvre MTA-STS et TLS-RPT le cas échéant.
• [ ] Maintenir la documentation pour les examens de sécurité PCI DSS.
• [ ] Examiner régulièrement la posture d’authentification.

XX. Points clés à retenir

Les commerçants Shopify et WooCommerce s’appuient sur des e-mails de confiance pour les confirmations de commande, l’accès au compte, l’assistance, les remboursements, les mises à jour d’expédition et la communication client.

La norme PCI DSS n’impose pas DMARC, SPF ou DKIM par leur nom, mais l’authentification des e-mails peut soutenir les objectifs anti-phishing, de protection de domaine, de surveillance des fournisseurs et d’intégrité des communications dans le cadre d’un programme de sécurité PCI DSS plus large.

Les commerçants Shopify doivent examiner l’authentification de domaine personnalisé et le comportement d’envoi des applications tierces.

Les commerçants WooCommerce doivent utiliser des fournisseurs SMTP authentifiés ou d’e-mails transactionnels et éviter de s’appuyer sur le mail WordPress par défaut pour la communication client critique.

La surveillance DMARC doit être le point de départ, pas l’état final.

L’objectif à long terme pour les domaines de boutique importants doit être l’application via p=quarantine ou p=reject, une fois que les expéditeurs légitimes sont alignés.

Pour les entreprises de commerce électronique, l’authentification des e-mails n’est pas seulement une tâche DNS technique. Elle fait partie de la protection de la confiance des clients autour de l’expérience de paiement.

Démarrez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit :