ब्रांड नाम के बजाय अधिसूचना से शुरुआत करें
अलग-अलग प्रेषक सेटिंग्स या वितरण मार्गों का उपयोग करते समय एक कर्मचारी अनुस्मारक और एक उम्मीदवार ईमेल एक ही संगठन से आते हुए प्रतीत हो सकते हैं। उस अधिसूचना से शुरुआत करें जिसे व्यवसाय को वितरित करने की आवश्यकता है। इसके सक्सेसफैक्टर्स मॉड्यूल, कंपनी आईडी, डेटासेंटर, कॉन्फ़िगर किए गए पते और किसी भी ग्राहक रिले को रिकॉर्ड करें। जब भी उनमें से कोई एक सीमा बदलती है तो एक अलग इन्वेंट्री पंक्ति जोड़ें। यह मार्गदर्शिका SAP के सार्वजनिक समर्थन दस्तावेज़ में वर्णित सक्सेसफैक्टर्स HCM अधिसूचना मार्ग को संबोधित करती है, न कि SAP नाम वाले प्रत्येक उत्पाद को।
लक्ष्य एक प्राप्त संदेश है जो इच्छित दृश्यमान पहचान को सुरक्षित रखता है और इसमें एक संरेखित प्रमाणीकरण पास होता है। प्रकाशित करना एक अभिलिखित एक मध्यवर्ती कदम है. यदि संगठन के गेटवे में SAP ट्रैफ़िक के लिए विशेष अपवाद है तो एक सफल आंतरिक डिलीवरी भी भ्रामक हो सकती है। आंतरिक स्वीकृति परीक्षण और बाह्य प्रमाणीकरण परीक्षण को अलग रखें।
समर्थन अनुरोध और DNS परिवर्तन एक साथ तैयार करें
में एसएपी केबीए 2688533, " DKIM या SPF कार्यान्वयन का अनुरोध/सक्षम कैसे करें?", एसएपी निर्देश देता है DKIM कंपनी आईडी, डेटासेंटर और संपूर्ण डोमेन सूची के साथ LOD-SF-PLT-NOT घटक के लिए अनुरोध। इसके नोट्स कॉन्फ़िगरेशन को डेटासेंटर-स्कोप बनाते हैं और कुंजी जोड़ने के बाद 48 घंटे तक की अनुमति देते हैं। वही KBA सूची A, SPF और SAP की सेवा के लिए MX पूर्वापेक्षाएँ। इन्हें प्रदाता आवश्यकताओं के रूप में मानें, न कि DKIM की सार्वभौमिक परिभाषा के रूप में।
यदि उन जिम्मेदारियों को विभाजित किया जाता है, तो एक व्यक्ति को SAP मामले में और दूसरे को आधिकारिक DNS ज़ोन में नियुक्त करें। हैंडऑफ़ में सटीक डोमेन, अनुरोधित हस्ताक्षर पहचान, DNS स्वामी, रिकॉर्ड प्रकार, सार्वजनिक मूल्य, टीटीएल और सहमत सक्रियण अपेक्षाएं शामिल होनी चाहिए। निजी कुंजियाँ और क्रेडेंशियल्स को कार्यपत्रक से बाहर रखें। इसका अनुमान मत लगाओ चयनकर्ता किसी अन्य SAP कार्यान्वयन या पुराने स्क्रीनशॉट से।
DNS को संपादित करने से पहले, वर्तमान रिकॉर्ड निर्यात करें और प्रस्तावित DKIM नाम पर किसी भी मौजूदा रिकॉर्ड का मालिक कौन है, इसकी पहचान करें। चयनकर्ता टकराव एक रोक स्थिति है, किसी सक्रिय सेवा को अधिलेखित करने की अनुमति नहीं है। एसएपी से इसका समाधान करने को कहें। यदि कोई DNS फॉर्म स्वचालित रूप से डोमेन प्रत्यय जोड़ता है, तो स्वामी को उस प्रारूप में दर्ज करें जो आवश्यक पूर्णतः योग्य नाम उत्पन्न करता है और बाद में प्रकाशित परिणाम को सत्यापित करता है।
वर्तमान डेटासेंटर SPF प्रविष्टि का चयन करें
उपयोग एसएपी केबीए 2087468, " SPF " और "सक्सेसफैक्टर्स डीसी SPF प्रविष्टियाँ", किसी अन्य खाते से कॉपी की गई सामान्य सूची नहीं। SAP बड़े डेटासेंटर को शामिल करने के प्रति चेतावनी देता है। इसकी तालिका माइग्रेट किए गए डेटासेंटर के लिए प्रतिस्थापन प्रविष्टियों की भी पहचान करती है, इसलिए ऐतिहासिक रूप से सही समावेश आज के कॉन्फ़िगरेशन को स्थापित करने के लिए पर्याप्त नहीं है। किसी प्रविष्टि को चुनने से पहले किरायेदार मालिक के साथ वास्तविक होस्टिंग स्थान की पुष्टि करें।
कॉन्फ़िगर किए गए दृश्यमान प्रेषक को इन्वेंट्री में रखें। वही KBA एकल प्रेषक और मॉड्यूल-विशिष्ट पतों पर चर्चा करता है, लेकिन उपयोगकर्ता को प्रदर्शित पता आपको यह नहीं बताता है कि प्राप्तकर्ता सर्वर SPF के लिए किस डोमेन का मूल्यांकन करता है। RFC 7208 , खंड 2.3 निर्दिष्ट करता है मेल प्रेषक पहचान। SPF पास क्या साबित करता है, यह तय करने से पहले इसे नियंत्रित प्राप्त संदेश या प्रासंगिक डिलीवरी साक्ष्य से प्राप्त करें।
मौजूदा पॉलिसी में केवल आवश्यक प्राधिकरण को उपयुक्त स्वामी के पास मर्ज करें। अन्य वैध प्रेषकों को सुरक्षित रखें. दूसरी SPF नीति न बनाएं, समीक्षा के बिना संगठन की वर्तमान समाप्ति योग्यता को प्रतिस्थापित न करें, या ऐसे नमूने की प्रतिलिपि न बनाएं जो मौजूदा सेवाओं को छोड़ देता है। RFC 7208 की धारा 4.5 और 4.6.4 में रिकॉर्ड चयन और डीएनएस-क्वेरी तंत्र और संशोधक के लिए दस-अवधि की सीमा शामिल है। नेस्टेड लुकअप की गणना करें, न कि केवल शीर्ष-स्तरीय स्ट्रिंग में दिखाई देने वाली संख्या की।
उपयोगी परिवर्तन रिकॉर्ड पहले और बाद की नीति और उसकी मूल्यांकन समीक्षा है। इसे स्पष्ट करना चाहिए कि प्रत्येक नया SAP प्राधिकरण क्यों आवश्यक है और कौन सी घटना इसके निष्कासन को गति प्रदान करेगी। पुरानी और नई प्रविष्टियों की लगातार बढ़ती सूची के बजाय डेटासेंटर माइग्रेशन नए सिरे से जांच का हकदार है।
ग्राहक रिले को एक अलग मार्ग के रूप में मानें
यदि आपका किरायेदार ग्राहक रिले का उपयोग करता है, तो मेल मालिक से किसी भी अंतिम आउटबाउंड गेटवे सहित पूरा पथ बनाने के लिए कहें। SAP KBA का "ग्राहक के मेल सर्वर के माध्यम से रिले मेल" अनुभाग एक वैकल्पिक व्यवस्था का वर्णन करता है। इसकी वर्तमान बाधाएँ किसी रिले को यूं ही शुरू करने का कारण नहीं हैं। रूटिंग परिवर्तन का प्रस्ताव देने से पहले SAP और प्राप्तकर्ता मेल टीम के साथ समर्थित कॉन्फ़िगरेशन और डिलीवरी के लिए जिम्मेदारी की पुष्टि करें।
एक रिले भेजने वाले आईपी, लिफाफे की पहचान, DKIM हस्ताक्षरों के सेट और उस बिंदु को बदल सकता है जहां सामग्री को संशोधित किया गया है। SAP के डिफ़ॉल्ट मार्ग के माध्यम से भेजा गया परीक्षण रिले किए गए उत्पादन पथ को मान्य नहीं कर सकता है। इसी तरह, रूट की शुरुआत में बनाया गया हस्ताक्षर बाद में होने वाले परिवर्तनों से बच नहीं सकता है। रिकॉर्ड करें कि कौन सी सेवा अंतिम संरेखित प्रमाणीकरण परिणाम प्रदान करने की उम्मीद करती है।
टिकट अनुलग्नक या सार्वजनिक DNS रिकॉर्ड में रिले क्रेडेंशियल न डालें। एक अलग रिले कॉन्फ़िगरेशन अधिकृत होने पर संगठन की अनुमोदित क्रेडेंशियल प्रक्रिया और एसएपी के निर्दिष्ट सुरक्षित चैनल का उपयोग करें। यह मार्गदर्शिका क्रेडेंशियल्स को कॉन्फ़िगर नहीं करती है, रूटिंग नहीं बदलती है या एक सार्वभौमिक प्रथा का दावा नहीं करती है Return-Path नियंत्रण मौजूद है.
जारी किए गए सार्वजनिक रिकॉर्ड को प्रकाशित और सत्यापित करें
अनुरोध के लिए दिए गए रिकॉर्ड के साथ लाइव आधिकारिक उत्तर की तुलना करें। पुष्टि करें कि स्वामी डुप्लिकेट नहीं है, संपूर्ण सार्वजनिक कुंजी मौजूद है और रिकॉर्ड प्रकार सही है। कैश्ड उत्तर असहमत होने पर एक से अधिक रिज़ॉल्वर पर परिणाम की जाँच करें और अवलोकन समय बनाए रखें। "सहेजा गया" दिखाने वाला DNS कंसोल वह साक्ष्य नहीं है जिसका उपयोग रिसीवर करता है।
सूचीबद्ध डोमेन और डेटासेंटर के लिए सक्रियण की पुष्टि करने के लिए SAP से पूछें। 48 घंटे बीत जाने को सबूत माने बिना मामले के संदर्भ और सक्रियण समय को रिकॉर्ड करें। यदि किसी नए परीक्षण में अपेक्षित हस्ताक्षर का अभाव है, तो पहले जांच लें कि यह सक्रियण के बाद उत्पन्न हुआ था और इच्छित मार्ग से आया था। बार-बार कुंजी पुनर्जनन अतिरिक्त अनिश्चितता पैदा कर सकता है जबकि मूल रूटिंग समस्या अनसुलझी रहती है।
RFC 6376 , खंड 3.5 सत्यापन कुंजी का पता लगाने के लिए उपयोग किए जाने वाले साइनिंग-डोमेन और चयनकर्ता फ़ील्ड को परिभाषित करता है। अंतिम संदेश से प्रत्येक DKIM d= और s= जोड़ी को कैप्चर करें। एक प्रदाता-डोमेन हस्ताक्षर आपके चुने हुए डोमेन के साथ संरेखित होने में विफल होने पर तकनीकी रूप से मान्य हो सकता है।
प्रत्येक सार्थक अधिसूचना पथ का परीक्षण करें
हानिरहित सामग्री और नियंत्रित प्राप्तकर्ताओं का उपयोग करें। वास्तविक उम्मीदवार विवरण, कर्मचारी रिकॉर्ड, आवेदन संलग्नक या उत्पादन-व्यापी घोषणाओं से बचें। जहां व्यवसाय को कई अधिसूचना प्रकारों की आवश्यकता होती है, वहां प्रतिनिधि संदेशों का चयन करें, बिना यह माने कि एक सफलता उन सभी को कवर करती है। संदेश पहचानकर्ता और यूटीसी भेजने का समय रखें ताकि एसएपी और प्राप्तकर्ता प्रणाली के माध्यम से समान डिलीवरी का पता लगाया जा सके।
प्रत्येक संदेश के लिए, दृश्यमान डोमेन, रिसीवर द्वारा रिपोर्ट की गई लिफाफा पहचान, सभी DKIM पहचान, SPF परिणाम, DKIM परिणाम और रिकॉर्ड करें DMARC परिणाम। अंतिम रिसीवर के विश्वसनीय का उपयोग करें Authentication-Results, संदेश के माध्यम से मनमाने ढंग से समान रूप से नामित हेडर नहीं। पॉलिसी रिकॉर्ड करें और संरेखण वह मोड जिसका रिसीवर ने मूल्यांकन किया।
RFC 9989 , अनुभाग 4.4, "पहचानकर्ता संरेखण समझाया" DMARC के लिए एक संरेखित पासिंग SPF या DKIM परिणाम की आवश्यकता होती है। वर्कशीट को उस पास प्रदान करने वाले तंत्र की पहचान करनी चाहिए। "डिलीवर किया गया," " TLS का उपयोग किया गया" और "एसएपी हमारी अनुमति सूची में दिखाई देता है" अलग-अलग अवलोकन हैं और इन्हें DMARC साक्ष्य क्षेत्र पर कब्जा नहीं करना चाहिए।
यदि SPF एक असंबंधित लिफ़ाफ़ा डोमेन के अंतर्गत गुजरता है, तो दृश्यमान डोमेन में अधिक SPF प्राधिकरण जोड़ने से वह विशेष पास संरेखित नहीं होगा। इसके बजाय इच्छित DKIM पहचान और समर्थित मार्ग की जाँच करें। यदि DKIM विफल रहता है, तो नीति बदलने से पहले गुम कुंजी, बेमेल चयनकर्ता, विकृत सार्वजनिक रिकॉर्ड और हस्ताक्षर के बाद के संशोधन को अलग करें।
मार्ग स्वीकृति वर्कशीट का उपयोग करें
नीचे दिए गए फ़ील्ड का उपयोग करके सक्सेसफैक्टर्स डोमेन-और-डेटासेंटर वर्कशीट के लिए एक अलग समीक्षा रिकॉर्ड बनाएं। प्रति सार्थक प्रेषण मार्ग की एक प्रति पूरी करें। इसमें SAP केस, जारी किया गया DNS रिकॉर्ड, डेटासेंटर प्राधिकरण, सक्रियण पुष्टिकरण, रिसीवर पहचान, संरेखण निर्णय और पुनर्प्राप्ति स्वामी शामिल हैं। न देखे गए फ़ील्ड को खाली छोड़ दें और नमूना मान को प्रतिस्थापित करने के बजाय अगली कार्रवाई को चिह्नित करें।
स्वीकृति रिकॉर्ड को तीन प्रश्नों का उत्तर देना चाहिए: क्या एसएपी ने इच्छित पहचान को सक्रिय किया है, क्या सार्वजनिक DNS इसका समर्थन करता है, और क्या रिसीवर ने उसी सटीक मार्ग से एक संदेश को मान्य किया है? तीनों की आवश्यकता है. बाहरी परीक्षण और संगठन के आंतरिक गेटवे के लिए अलग-अलग परिणाम रिकॉर्ड करें ताकि बाईपास से अंतर न छुपे।
काल्पनिक कार्य उदाहरण: गलत डेटासेंटर धारणा
केवल काल्पनिक लिखित मामला: SF-01 का उद्देश्य hiring@careers.example से माना जाता है, लेकिन पहली अधिसूचना एक प्रदाता का उपयोग करती है जिसका सटीक पता अज्ञात है। DKIM , चयनकर्ता और लिफ़ाफ़ा/ SPF परिणाम अज्ञात हैं। पुराना डेटासेंटर अनुरोध वर्तमान किरायेदार के लिए साक्ष्य नहीं है। एचआर सिस्टम के मालिक को वर्तमान डेटासेंटर और अधिसूचना प्रेषक की पुष्टि करनी होगी, उस मार्ग के लिए सक्रियण प्राप्त करना होगा, फिर एक नए हानिरहित बाहरी संदेश का निरीक्षण करना होगा। कोई DMARC निर्णय का अनुमान नहीं लगाया गया है और किसी किरायेदार, DNS या संदेश का परीक्षण नहीं किया गया था।
विफलता को विस्तृत किये बिना पुनर्प्राप्त करें
व्यवसाय-महत्वपूर्ण परीक्षण विफल होने पर प्रभावित अधिसूचना परिवर्तन को रोकें और यदि कोई मौजूद है तो पहले से स्वीकृत वितरण मार्ग का उपयोग करें। किसी भी उलटफेर के लिए एसएपी और मेल मालिक के साथ समन्वय करें। सार्वजनिक कुंजी को न हटाएं जबकि नए भेजे गए या कतारबद्ध संदेशों को अभी भी इसकी आवश्यकता हो सकती है, और केवल एक मार्ग को सफल दिखाने के लिए पूरे संगठन की DMARC नीति को कमजोर न करें।
डेटासेंटर माइग्रेशन, प्रेषक-डोमेन परिवर्तन, रिले परिवर्तन और अधिसूचना-रूटिंग परिवर्तन के बाद पुनः परीक्षण करें। यह एक अप्रकाशित कार्यान्वयन मसौदा बना हुआ है: लाइव किरायेदार समीक्षा, खाता-जारी रिकॉर्ड, DNS अवलोकन, प्राप्त-संदेश पहचान साक्ष्य, दृश्य समीक्षा और मानव एसएमई अनुमोदन लंबित हैं। दस्तावेज़ी अनुसंधान को चुपचाप पूर्ण परिनियोजन के रूप में मानने के बजाय उन्हें स्वीकृति द्वार के रूप में संरक्षित करें।
स्रोत उपलब्धता और कार्यान्वयन की पुष्टि
दो SAP KB पृष्ठों को संरक्षित 8 नवंबर 2026 स्रोत स्नैपशॉट में सार्वजनिक पाठ के रूप में पुनर्प्राप्त किया गया था। इस समीक्षा के दौरान प्रारंभिक ओपन ने फिर से सार्वजनिक रिज़ॉल्यूशन सामग्री की पहचान की, लेकिन बाद में अनुभाग खुलने पर लॉगिन-आवश्यक पूर्वावलोकन वापस आ गए। इसलिए ऊपर दिए गए विस्तृत निर्देश संरक्षित प्राथमिक-स्रोत प्रतियों पर निर्भर करते हैं, न कि यह दावा कि पूरे पृष्ठ सार्वजनिक रूप से पठनीय बने रहेंगे। परिवर्तन करने से पहले SAP के साथ वर्तमान डेटासेंटर प्रविष्टि, सेवा पूर्वापेक्षाएँ और सक्रियण वर्कफ़्लो की पुष्टि करें। कोई लॉगिन या एक्सेस बायपास का प्रयास नहीं किया गया।
पारित संदेश को प्रवर्तन तत्परता से अलग करें
RFC 9989 धारा 7.4 को डोमेन प्रकाशन के लिए वैध DKIM आवश्यकता है p=reject और अप्रत्यक्ष-मेल अंतरसंचालनीयता के बारे में सावधान करता है। एक एकल संरेखित SPF परिणाम अपने आप में अस्वीकार-नीति रोलआउट को उचित नहीं ठहराता है। इस प्रदाता सेटअप से सभी वैध मार्गों और नीति स्वामित्व की अलग से समीक्षा करें।