Commencez par la notification plutôt que par le nom de la marque
Un rappel aux employés et un e-mail de candidat peuvent sembler provenir de la même organisation tout en utilisant des paramètres d'expéditeur ou des itinéraires de livraison différents. Commencez par la notification que l’entreprise doit envoyer. Enregistrez son module SuccessFactors, son identifiant d'entreprise, son centre de données, l'adresse d'expéditeur configurée et tout relais client. Ajoutez une ligne d'inventaire distincte chaque fois que l'une de ces limites change. Ce guide traite de l'itinéraire de notification SuccessFactors HCM décrit dans la documentation de support publique de SAP, et non de tous les produits portant le nom SAP.
La cible est un message reçu qui préserve l'identité visible prévue et possède une passe d'authentification alignée. Édition un enregistrement est une étape intermédiaire. Une livraison interne réussie peut également être trompeuse si la passerelle de l'organisation dispose d'une exception spéciale pour le trafic SAP. Séparez le test d’acceptation interne et le test d’authentification externe.
Préparer ensemble la demande d'assistance et le changement DNS
Dans SAP KBA 2688533, « Comment demander/activer la mise en œuvre DKIM ou SPF ? », SAP dirige DKIM demandes au composant LOD-SF-PLT-NOT avec l'ID de l'entreprise, le centre de données et la liste complète des domaines. Ses notes rendent la configuration limitée au centre de données et autorisent jusqu'à 48 heures après l'ajout de la clé. Le même KBA répertorie A, SPF et les prérequis MX pour le service SAP. Considérez-les comme des exigences du fournisseur et non comme une définition universelle de DKIM .
Affectez une personne au dossier SAP et une autre à la zone DNS faisant autorité si ces responsabilités sont partagées. Le transfert doit contenir le domaine exact, l'identité de signature demandée, le propriétaire DNS , le type d'enregistrement, la valeur publique, la durée de vie et les attentes d'activation convenues. Conservez les clés privées et les informations d’identification hors de la feuille de calcul. Ne déduisez pas le sélecteur à partir d'une autre implémentation SAP ou d'une ancienne capture d'écran.
Avant de modifier DNS , exportez les enregistrements actuels et identifiez à qui appartient tout enregistrement existant au nom DKIM proposé. Une collision de sélecteur est une condition d’arrêt et non une autorisation d’écraser un service actif. Demandez à SAP de résoudre le problème. Si un formulaire DNS ajoute automatiquement le suffixe de domaine, saisissez le propriétaire dans le format qui produit le nom complet requis et vérifiez ensuite le résultat publié.
Sélectionnez l'entrée SPF actuelle du centre de données
Utiliser SAP KBA 2087468, « SPF » et « Entrées SuccessFactors DC SPF », pas une liste générique copiée à partir d'un autre compte. SAP met en garde contre l'inclusion de grands centres de données. Son tableau identifie également les entrées de remplacement pour les centres de données migrés, de sorte qu'une inclusion historiquement correcte ne suffit pas pour établir la configuration actuelle. Confirmez l'emplacement d'hébergement réel auprès du propriétaire locataire avant de choisir une entrée.
Conservez l’expéditeur visible configuré dans l’inventaire. Le même KBA traite des adresses d'expéditeur unique et spécifiques au module, mais une adresse affichée à l'utilisateur ne vous indique pas quel domaine un serveur de réception évalue pour SPF . RFC 7208 , section 2.3 précise le COURRIER DE identité. Obtenez-le à partir d’un message reçu contrôlé ou de la preuve de livraison pertinente avant de décider ce que prouve un pass SPF .
Fusionnez uniquement l’autorisation requise dans la stratégie existante du propriétaire approprié. Préservez les autres expéditeurs légitimes. Ne créez pas une deuxième stratégie SPF , ne remplacez pas le qualificatif de fin actuel de l'organisation sans examen ou ne copiez pas un exemple qui omet les services existants. Les sections 4.5 et 4.6.4 de RFC 7208 couvrent la sélection des enregistrements et la limite de dix termes pour les mécanismes et modificateurs d'interrogation DNS. Comptez les recherches imbriquées, et pas seulement le nombre d'inclusions visibles dans la chaîne de niveau supérieur.
Le dossier de changement utile est une politique avant et après ainsi que son examen d'évaluation. Il doit expliquer pourquoi chaque nouvelle autorisation SAP est nécessaire et quel événement déclenchera sa suppression. Une migration de centre de données mérite une nouvelle vérification plutôt qu'une liste toujours croissante d'entrées anciennes et nouvelles.
Traitez un relais client comme un itinéraire différent
Si votre locataire utilise un relais client, demandez au propriétaire du courrier de tracer le chemin complet, y compris toute passerelle sortante finale. La section « Relayer le courrier via les serveurs de messagerie d'un client » de SAP KBA décrit une solution alternative. Ses contraintes actuelles ne sont pas une raison pour introduire un relais au hasard. Confirmez la configuration prise en charge et la responsabilité de la livraison avec SAP et l'équipe de réception du courrier avant de proposer une modification de routage.
Un relais peut modifier l'adresse IP d'envoi, l'identité de l'enveloppe, l'ensemble des signatures DKIM et le point de modification du contenu. Un test envoyé via la route par défaut de SAP ne peut pas valider un chemin de production relayé. De même, une signature créée au début du parcours peut ne pas survivre aux modifications ultérieures. Enregistrez quel service est censé fournir le résultat final d’authentification aligné.
Ne placez pas les informations d'identification de relais dans une pièce jointe à un ticket ou dans un enregistrement DNS public. Utilisez le processus d'identification approuvé de l'organisation et le canal sécurisé désigné par SAP lorsqu'une configuration de relais distincte est autorisée. Ce guide ne configure pas les informations d'identification, ne modifie pas le routage et n'affirme pas qu'une coutume universelle Return-Path le contrôle existe.
Publier et vérifier le dossier public émis
Comparez la réponse faisant autorité en direct avec l'enregistrement fourni pour la demande. Confirmez que le propriétaire n'est pas dupliqué, que la clé publique complète est présente et que le type d'enregistrement est correct. Vérifiez le résultat sur plusieurs résolveurs lorsque les réponses mises en cache ne sont pas d'accord et conservez les temps d'observation. Une console DNS indiquant « enregistré » n'est pas la preuve qu'un récepteur utilise.
Demandez à SAP de confirmer l'activation pour les domaines et le centre de données répertoriés. Enregistrez la référence du cas et l’heure d’activation sans considérer le passage des 48 heures comme preuve. Si un nouveau test n'a pas la signature attendue, vérifiez d'abord qu'il a été généré après l'activation et qu'il provient de la route prévue. Une régénération de clé répétée peut créer une incertitude supplémentaire alors que le problème de routage d'origine reste non résolu.
RFC 6376 , section 3.5 définit le domaine de signature et les champs de sélection utilisés pour localiser une clé de vérification. Capturez chaque paire DKIM d= et s= du message final. Une signature de domaine de fournisseur peut être techniquement valide sans s'aligner sur le domaine From choisi.
Testez chaque chemin de notification significatif
Utilisez du contenu inoffensif et des destinataires contrôlés. Évitez les détails réels des candidats, les dossiers des employés, les pièces jointes aux candidatures ou les annonces à l'échelle de la production. Lorsque l'entreprise a besoin de plusieurs types de notifications, sélectionnez des messages représentatifs sans supposer qu'un seul succès les couvre tous. Conservez l'identifiant du message et l'heure d'envoi UTC afin que la même livraison puisse être retracée via SAP et le système de réception.
Pour chaque message, enregistrez le domaine From visible, l'identité de l'enveloppe signalée par le destinataire, toutes les identités DKIM , le résultat SPF , les résultats DKIM et DMARC résultat. Utilisez le fichier de confiance du destinataire final Authentication-Results, et non des en-têtes arbitraires portant des noms similaires transportés dans le message. Enregistrez la politique et alignement mode que le récepteur a évalué.
RFC 9989 , section 4.4, « Alignement des identifiants expliqué » nécessite un résultat SPF ou DKIM de réussite aligné pour DMARC . La feuille de travail doit identifier le mécanisme fournissant ce laissez-passer. « Livré », « TLS utilisé » et « SAP apparaît sur notre liste verte » sont des observations différentes et ne doivent pas occuper le champ de preuve DMARC .
Si SPF passe sous un domaine d’enveloppe non lié, l’ajout d’autorisations SPF supplémentaires au domaine visible From n’alignera pas cette passe particulière. Examinez plutôt l’identité DKIM prévue et l’itinéraire pris en charge. Si DKIM échoue, distinguez les clés manquantes, les sélecteurs incompatibles, les enregistrements publics mal formés et les modifications post-signature avant de modifier la stratégie.
Utiliser la feuille de travail d'acceptation d'itinéraire
Créez un enregistrement d'évaluation distinct pour la feuille de calcul de domaine et de centre de données SuccessFactors à l'aide des champs ci-dessous. Remplissez une copie par itinéraire d’envoi significatif. Il comprend le dossier SAP, l'enregistrement DNS émis, l'autorisation du centre de données, la confirmation d'activation, les identités du destinataire, la décision d'alignement et le propriétaire de la récupération. Laissez les champs non observés vides et marquez l'action suivante plutôt que de remplacer un exemple de valeur.
L'enregistrement d'acceptation doit répondre à trois questions : SAP a-t-il activé l'identité souhaitée, DNS public la prend-il en charge et le destinataire a-t-il validé un message provenant de cette route exacte ? Exigez les trois. Enregistrez les résultats séparément pour le test externe et la passerelle interne de l'organisation afin qu'un contournement ne masque pas la différence.
Exemple concret fictif : hypothèse erronée relative au centre de données
Cas écrit fictif uniquement : SF-01 suppose que l'intention était From hiring@careers.example , mais la première notification utilise un fournisseur From dont l'adresse exacte est inconnue. Les résultats DKIM , sélecteur et enveloppe/ SPF sont inconnus. Une ancienne demande de centre de données ne constitue pas une preuve pour le locataire actuel. Le propriétaire des systèmes RH doit confirmer le centre de données actuel et l'expéditeur de la notification, obtenir l'activation pour cet itinéraire, puis inspecter un nouveau message externe inoffensif. Aucun verdict DMARC n’est déduit et aucun locataire, DNS ou message n’a été testé.
Récupérer sans élargir l’échec
Suspendez la modification de notification concernée lorsque les tests critiques pour l'entreprise échouent et utilisez l'itinéraire de livraison précédemment approuvé s'il en existe un. Coordonnez toute annulation avec SAP et le propriétaire du courrier. Ne supprimez pas une clé publique alors que des messages récemment envoyés ou mis en file d'attente peuvent encore en avoir besoin, et n'affaiblissez pas la politique DMARC de l'ensemble de l'organisation simplement pour faire apparaître un itinéraire réussi.
Retestez après la migration du centre de données, les modifications du domaine de l'expéditeur, les modifications du relais et les modifications du routage des notifications. Il s'agit d'un projet de mise en œuvre non publié : l'examen en direct des locataires, les enregistrements émis par le compte, les observations DNS , les preuves d'identité des messages reçus, l'examen visuel et l'approbation humaine de la PME sont en attente. Conservez-les comme des portes d’acceptation plutôt que de traiter silencieusement la recherche documentaire comme un déploiement terminé.
Disponibilité de la source et confirmation de la mise en œuvre
Les deux pages de la base de connaissances SAP ont été récupérées sous forme de texte public dans les instantanés sources conservés du 8 novembre 2026. Au cours de cet examen, la première ouverture a identifié à nouveau le contenu de la résolution publique, mais la section ultérieure ouvre les aperçus requis par la connexion. Les instructions détaillées ci-dessus s'appuient donc sur les copies de source primaire préservées, et non sur l'affirmation selon laquelle les pages complètes restent lisibles publiquement. Confirmez l'entrée actuelle du centre de données, les prérequis du service et le workflow d'activation avec SAP avant d'apporter des modifications. Aucune tentative de connexion ou de contournement d’accès n’a été effectuée.
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.