Distinguer le courrier électronique professionnel du courrier électronique de masse
SAP Cloud for Customer comporte des considérations d'authentification distinctes pour les messages professionnels et les e-mails de masse. L'article de connaissances de première partie distingue les utilisations transactionnelles telles que les tickets de service et les devis des communications groupées telles que les campagnes et les newsletters. Enregistrez quelle route est dans la portée avant de demander l’activation ou de modifier DNS . Ne présumez pas qu’une modification de la messagerie professionnelle complète un déploiement massif de la messagerie électronique. Distinction SAP Business et e-mail de masse
Ce guide s'applique au Cloud for Customer, communément appelé C4C. Il ne s'agit pas d'une procédure de configuration pour SAP Marketing Cloud, S/4HANA, Business ByDesign ou un autre produit dont la documentation mentionne DKIM. Confirmez le produit exact, l'URL du locataire, l'environnement, les domaines d'envoi et le composant de support avant d'agir.
Créez un inventaire de chaque locataire et de chaque domaine From réel visible, y compris les sous-domaines. Incluez les environnements de test et de production et les messages générés par les flux de travail, et pas seulement la correspondance envoyée manuellement. Les preuves doivent identifier à qui appartient chaque identité et quel processus métier en dépend. Une URL de locataire ne constitue pas à elle seule un inventaire de domaine complet.
Comprendre pourquoi SPF géré est insuffisant
La FAQ publique sur la messagerie professionnelle de SAP indique que SAP maintient son infrastructure SPF et oblige les clients à terminer la configuration DKIM . Cela n'établit pas alignement pour le domaine From d'un client spécifique : collectez l'identité réelle de l'enveloppe et comparez-la avec From. La page séparée du guide de sécurité n'était pas lisible lors de cet examen, donc aucun suffixe d'enveloppe spécifique à l'environnement ou résultat d'alignement n'en est tiré. FAQ sur la messagerie professionnelle SAP
L’ajout d’une inclusion de fournisseur à une stratégie de domaine client non liée ne modifie pas l’identité de l’enveloppe utilisée dans le message. Avant toute modification SPF , enregistrez l’identité évaluée et la raison pour laquelle la modification est requise. Maintenez une stratégie applicable chez ce propriétaire, préservez les autres expéditeurs légitimes et tenez compte de l'évaluation DNS imbriquée. SPF RFC 7208
Pour l’itinéraire commercial documenté, l’alignement DKIM est la voie clé à étudier. N'affaiblissez pas le domaine Application DMARC pour masquer l'absence d'une signature alignée valide. Un résultat SPF réussi et un échec DMARC le résultat peut être cohérent lorsque l’identité SPF réussie n’est pas liée au domaine From visible.
Préparer les enregistrements de courrier professionnel spécifiques au locataire
La FAQ publique de SAP décrit trois CNAME enregistrements par domaine d'envoi et par locataire, en utilisant des informations spécifiques au locataire sélecteur noms. Il demande aux clients de fournir le mappage domaine-locataire et de couvrir tous les domaines personnalisés utilisés pour la messagerie professionnelle. Les exemples de numéros de locataire sont des espaces réservés et non des valeurs publiques à copier dans une zone client. FAQ sur l'activation de la messagerie professionnelle SAP
Obtenez ou confirmez les propriétaires publics exacts actuels et les cibles pour l'environnement du locataire. La FAQ publique donne des exemples spécifiques aux locataires, et non une confirmation de chaque environnement ; ne dérivez pas de cible pour un environnement non confirmé à partir d'un exemple familier crm.ondemand.com . Conservez les instructions de support et demandez à l'administrateur DNS de valider le mappage avant publication. FAQ sur la messagerie professionnelle SAP
Vérifiez chaque propriétaire CNAME proposé pour les données existantes. Un domaine utilisé par plusieurs processus métier peut déjà avoir plusieurs sélecteurs ; les nouveaux enregistrements ne doivent pas écraser les clés non liées. Vérifiez l'extension du nom de propriétaire de la console DNS et publiez uniquement l'ensemble actuellement pris en charge. Stockez les valeurs publiques dans l’enregistrement des modifications, mais n’incluez jamais de matériel de signature privé ou d’informations d’identification de compte.
Après la publication, conservez les résultats de recherche faisant autorité et la liste domaine-locataire pour la demande d'activation du fournisseur. Utilisez le mappage domaine-locataire de la FAQ publique et confirmez explicitement le processus d'activation de la messagerie professionnelle avec SAP pour l'environnement. La publication DNS et l'activation SAP sont des étapes distinctes. Ne signalez pas le travail terminé simplement parce qu'un CNAME existe. FAQ sur la messagerie professionnelle SAP
Gérer les domaines partagés entre les tests et la production
SAP documente un cas dans lequel un message de production utilise un sélecteur dont le nom fait référence à un locataire de test car le même domaine y a été activé en premier. L'article indique qu'un sélecteur peut être actif par domaine dans cette situation documentée et que le nom seul ne pose pas de problème d'envoi. Utilisation du sélecteur SAP entre les locataires
Utilisez cette explication avec précaution. Un nom de sélecteur surprenant n'est pas une preuve d'échec, mais l'article ne prouve pas non plus qu'une signature réelle est valide. Confirmez le profil de domaine du fournisseur, la recherche de clé publique, le domaine de signature et le résultat du destinataire. Évitez de supprimer l'enregistrement portant le nom du test simplement pour rendre les preuves de production plus claires ; il peut toujours servir le profil actif.
Lorsqu'un locataire de test est retiré, examinez les dépendances de signature partagées avant de supprimer DNS . Enregistrez quel locataire a initialement établi le profil de domaine, ce que le fournisseur dit rester actif et quels flux de production l'utilisent encore. Si un changement de sélecteur est nécessaire, obtenez un plan de transition coordonné et conservez les anciennes dépendances jusqu'à ce que le fournisseur confirme que la retraite est sûre.
Traitez les e-mails de masse comme une demande d'activation distincte
L'article sur l'activation par e-mail de masse de SAP décrit un sous-domaine d'envoi, une configuration à trois CNAME et un incident de support. Il demande le type de mailing, la catégorie de destinataire, le volume mensuel attendu, le volume par envoi, le locataire et le sous-domaine. Préparez ces détails opérationnels plutôt que de soumettre uniquement une capture d’écran DNS . Confirmez que les enregistrements émis et les instructions d'activation s'appliquent à l'itinéraire d'envoi de masse actuel. Activation par e-mail de masse SAP
Choisissez le sous-domaine d'envoi avec le propriétaire de la campagne et l'équipe de sécurité. Un sous-domaine peut clarifier la propriété opérationnelle, mais il n’isole pas automatiquement chaque problème de réputation ou de politique. Vérifiez son DNS existant, la politique découverte pour son domaine From, la gestion des réponses et toutes les dépendances sur d'autres systèmes avant de l'utiliser.
L'article envoyé en masse par courrier électronique indique qu'un vérificateur générique peut afficher une erreur attendue pour les enregistrements de réserve alors que l'ensemble complet de trois enregistrements reste requis. Traitez cela comme une qualification spécifique au fournisseur, et non comme une autorisation d'ignorer les échecs DNS arbitraires. Demandez à SAP de confirmer l'état actif et réservé prévu, de vérifier les CNAME exacts et de prouver la signature réellement utilisée par un message reçu. Ne supprimez pas les enregistrements de réserve simplement parce qu’ils n’ont pas été utilisés dans un test.
Capturez indépendamment les preuves commerciales et les courriers de masse
Pour le courrier professionnel, sélectionnez une transaction ou un flux de travail représentatif inoffensif dans chaque locataire libéré. Pour le courrier de masse, utilisez une audience de test contrôlée et un test de campagne pris en charge qui ne contactera pas les destinataires indésirables. Enregistrez l'objet ou la campagne d'origine, l'horodatage, le locataire et l'expéditeur sélectionné. Un résultat de test-locataire ne doit pas se substituer silencieusement aux preuves de production.
Chez un destinataire approuvé, conservez les en-têtes d’origine et les résultats d’authentification. Enregistrez le De visible, l'identité de l'enveloppe, tous les domaines de signature DKIM d= et les sélecteurs s=, ainsi que le résultat du destinataire pour chaque signature pertinente. Le sélecteur identifie la recherche de clé publique DNS ; ce n'est pas lui-même le domaine que DMARC aligne. DKIM RFC 6376
Appliquez les règles actuelles de découverte et d’alignement DMARC aux identités observées. Un chemin DKIM aligné qui passe peut satisfaire DMARC même lorsque SPF passe sans alignement. Un enregistrement de stratégie à lui seul ne peut pas ajouter de signature ou corriger un domaine From qui ne correspond pas. Examinez la politique en vigueur avant de la modifier et utilisez uniquement les destinations de reporting approuvées. DMARC RFC 9989
Si un test échoue, conservez l'échec exact et la recherche publique avant de modifier quoi que ce soit. Aucune signature ne peut indiquer une activation manquante ou un itinéraire différent. Une clé manquante peut indiquer un enregistrement ou une cible de sélecteur incorrect. Une signature valide avec le mauvais domaine de signature indique un alignement ou une sélection de profil de domaine. Ces observations restreignent la demande de support ; ils ne justifient pas de deviner un enregistrement de remplacement.
Exemple fictif de SPF géré et d'un sélecteur inattendu
Cas écrit fictif uniquement : C4C-01 suppose qu'un devis de production comporte From sales@company.example , une signature de passage d=company.example, et un sélecteur dont le nom fait référence au locataire de test. Le sélecteur exact et l'identité SPF ne sont pas fournis, il ne s'agit donc pas d'une recette DNS réutilisable. Sous la signature de passage stipulée, le domaine de signature s'aligne exactement ; le nom inattendu du sélecteur ne constitue pas à lui seul une raison pour le supprimer. Le propriétaire SAP doit vérifier le profil de domaine partagé avant le retrait. Une route de courrier électronique distincte ne comporte aucune preuve d'activation ou de destinataire et reste ouverte. Aucun locataire, requête DNS ou message n'a été exécuté.
Feuille de travail de mise en œuvre et limites de publication
- Portée : produit exact, URL du locataire, environnement, statut de production ou de test, itinéraire commercial ou de masse et propriétaire.
- Carte de domaine : tous les domaines et sous-domaines visibles, les flux de travail associés, le propriétaire de la réponse et les profils partagés.
- DNS : ensemble de trois enregistrements actuellement émis par le fournisseur, cibles spécifiques à l'environnement, conflits existants, durées de vie et preuves de recherche.
- Activation : référence de support, itinéraire demandé, liste de domaine à locataire, réponse du fournisseur et explication du sélecteur actif ou de réserve.
- Planification des emails de masse : objectif de l'envoi, catégorie de destinataire, volumes attendus, sous-domaine choisi et méthode de test contrôlée.
- Preuve du message : référence d'origine, De, identité de l'enveloppe, valeurs DKIM d=/s= , résultats fiables, politique efficace et décision d'alignement.
- Récupération : autorité de suspension, itinéraire précédemment pris en charge, dépendances de sélecteur partagé et approbation du retrait.
La configuration du locataire en direct, DNS public, l'activation réelle, les en-têtes reçus et les captures d'écran actuelles restent non vérifiés. L’examen visuel, l’approbation de la PME humaine et la publication sont en attente. Ce guide est un candidat documentaire inédit ; les cibles spécifiques à l'environnement, le comportement de profil partagé et toute route commerciale ou de masse non testée nécessitent une confirmation avant la publication.
Note sur la disponibilité des sources
Le texte de résolution pour SAP KB3573096 et KB3728757 a été préservé d'une récupération publique réussie le 8 novembre 2026 à 04:12:48 UTC. Une vérification indépendante ultérieure a renvoyé des aperçus requis pour la connexion. Les explications du sélecteur partagé et de l'entreprise contre la masse ci-dessus s'appuient sur ces copies de source primaire préservées ; confirmer l'applicabilité du compte courant avec SAP avant la mise en œuvre.
Séparez un message qui passe de la préparation à l'application
RFC 9989 La section 7.4 nécessite DKIM valide pour une publication de domaine p=reject et met en garde contre l'interopérabilité du courrier indirect. Un seul résultat SPF aligné ne justifie pas en soi le déploiement d’une politique de rejet. Examinez tous les itinéraires légitimes et la propriété des politiques séparément de la configuration de ce fournisseur.