Yotpo के माध्यम से भेजे गए ईमेल को प्रमाणित करें: कॉन्फ़िगरेशन और सत्यापन

दायरा और पूर्वापेक्षाएँ

यह प्रक्रिया योटपो में वर्णित समीक्षा और लॉयल्टी कस्टम-डोमेन मार्ग के लिए है CNAME प्रमाणीकरण मार्गदर्शिका. यह दावा नहीं है कि एसएमएस और ईमेल सहित प्रत्येक योटपो उत्पाद एक ही सेटअप का उपयोग करता है। प्रलेखित मार्ग योटपो के पीछे SendGrid उपयोग करता है और समर्थन-आपूर्ति, डोमेन-विशिष्ट रिकॉर्ड की आवश्यकता होती है। रिकॉर्ड का अनुरोध करने से पहले समीक्षा या लॉयल्टी स्वामी से उत्पाद की ईमेल सेटिंग में दिखाए गए सटीक डोमेन की पुष्टि करवाएं।

प्रलेखित मार्ग कॉन्फ़िगर करें

• चरण 1. डोमेन और मौजूदा DNS स्वामित्व से दिखाई देने वाले उत्पाद, खाते, इच्छित उद्देश्य को रिकॉर्ड करें। उस डोमेन के लिए पहले से ही SendGrid का उपयोग करने वाले किसी अन्य एप्लिकेशन की पहचान करें।
• चरण 2. Yotpo समीक्षा समर्थन या Yotpo लॉयल्टी समर्थन से डोमेन के CNAME सेट का अनुरोध करें। सटीक ईमेल-सेटिंग्स डोमेन दें और मौजूदा SendGrid एकीकरण का खुलासा करें ताकि समर्थन एक गैर-परस्पर विरोधी रिकॉर्ड संरचना प्रदान कर सके।
• चरण 3. प्रत्येक आपूर्ति किए गए होस्ट और लक्ष्य को आधिकारिक DNS ज़ोन में कॉपी करें। योटपो के चित्रण में एक लिफाफा-संबंधित CNAME और दो शामिल हैं DKIM CNAMEs, लेकिन इसके होस्ट और मान स्ट्रिंग प्रति डोमेन अद्वितीय हैं। चित्रण आपके खाते के लिए कॉन्फ़िगरेशन नहीं है.
• चरण 4. रिकॉर्ड प्रकार सुरक्षित रखें। अनुरोधित CNAME a से न बदलें TXT रिकॉर्ड या अधिलेखित करें a चयनकर्ता किसी अन्य प्रेषक को सौंप दिया गया। CNAME स्वामी के लिए, नए प्रतिनिधिमंडल को प्रकाशित करने से पहले परस्पर विरोधी सामान्य रिकॉर्ड का समाधान किया जाना चाहिए।
• चरण 5. प्रकाशित रिकॉर्ड को सत्यापित करने और पूर्ण सक्रियण के लिए Yotpo समर्थन से पूछें। केवल DNS प्रकाशन ही अंतिम प्रलेखित चरण नहीं है।
• चरण 6. समर्थन पूरा होने की पुष्टि के बाद एक प्रतिनिधि समीक्षा या वफादारी संदेश ट्रिगर करें। कॉन्फ़िगरेशन को किसी अन्य उत्पाद या स्टोरफ्रंट पर रोल आउट करने से पहले परिणामी पहचान कैप्चर करें।

उत्पाद-विशिष्ट जोखिम

यदि डोमेन अभी भी सत्यापन में विफल रहता है, तो DNS स्वामी और CNAME लक्ष्य की तुलना नवीनतम समर्थन-जारी सेट से करें, पुराने स्क्रीनशॉट से नहीं। यदि मौजूदा SendGrid चयनकर्ता पर कब्जा कर लिया गया है, तो कार्यशील एकीकरण को हटाने के बजाय सही वैकल्पिक संरचना के लिए समर्थन पर वापस लौटें। एक कार्यशील ट्रैकिंग लिंक या ब्रांडेड डिस्प्ले नाम DKIM स्थापित नहीं कर सकता संरेखण. समर्थन केस पहचानकर्ता को परिवर्तन रिकॉर्ड के साथ रखें ताकि बाद में कुंजी या डोमेन प्रश्नों को मूल प्रतिनिधिमंडल से जोड़ा जा सके।

प्राप्त अंत पर मार्ग सिद्ध करें

एक स्वीकृत बाहरी मेलबॉक्स का उपयोग करें और संपूर्ण कच्चे संदेश को उसके टाइमस्टैम्प और संदेश पहचानकर्ता के साथ सहेजें। इस गाइड में किसी लाइव किरायेदार परीक्षण का दावा नहीं किया गया है। कार्यान्वयन के दौरान पूरा करने के लिए निम्नलिखित एक स्वीकृति कार्यपत्रक है, नहीं एक अभिलिखित देखे गए परिणामों का.

• साक्ष्य क्षेत्र: से दृश्यमान; क्या रिकॉर्ड करना है: वास्तविक पता और डोमेन; स्वीकृति प्रश्न: क्या यह इच्छित प्रेषक पहचान है?
• साक्ष्य क्षेत्र: लिफाफा; क्या रिकॉर्ड करें: Return-Path और रिसीवर-रिपोर्ट की गई SPF कार्यक्षेत्र; स्वीकृति प्रश्न: SPF ने वास्तव में किस डोमेन को प्रमाणित किया?
• साक्ष्य क्षेत्र: SPF ; क्या रिकॉर्ड करें: विश्वसनीय रिसीवर परिणाम और मूल्यांकन की गई पहचान; स्वीकृति प्रश्न: क्या यह पारित हो गया, और क्या वह पहचान संरेखित हुई?
• साक्ष्य क्षेत्र: DKIM ; क्या रिकॉर्ड करें: प्रत्येक d= डोमेन, s= चयनकर्ता और रिसीवर परिणाम; स्वीकृति प्रश्न: क्या कम से कम एक पासिंग हस्ताक्षर संरेखित होता है?
• साक्ष्य क्षेत्र: DMARC; क्या रिकॉर्ड करें: रिसीवर परिणाम और लागू नीति; स्वीकृति प्रश्न: क्या एक संरेखित मार्ग मौजूद है?
• साक्ष्य क्षेत्र: मार्ग; क्या रिकॉर्ड करें: उत्पाद, खाता और संदेश प्रकार; स्वीकृति प्रश्न: क्या परीक्षण ने उत्पादन पथ का उपयोग किया?

DMARC कम से कम एक संरेखित, पासिंग SPF या DKIM पथ की आवश्यकता है। किसी असंबद्ध सेवा डोमेन से पासिंग हस्ताक्षर पर्याप्त नहीं है। सख्त संरेखण के लिए सटीक डोमेन समानता की आवश्यकता होती है; शिथिल संरेखण लागू संगठनात्मक-डोमेन संबंध का उपयोग करता है। सफलता की घोषणा करने से पहले डोमेन की वास्तविक संरेखण सेटिंग्स की जाँच करें। एक उपडोमेन एक स्वचालित सख्त मिलान नहीं है. SPF SMTP पहचान का उपयोग करता है, प्रदर्शन नाम या रिप्लाई-टू का नहीं। से परामर्श करें संरेखण शब्दावली निर्णय दर्ज करते समय.

उपयोग Authentication-Results प्राप्तकर्ता प्रणाली से जिस पर आप भरोसा करते हैं, किसी मनमाने प्रेषक द्वारा प्रदत्त हेडर से नहीं। पहली विफलता पर रुकने के बजाय सभी हस्ताक्षर कैप्चर करें। अग्रेषित मेल के लिए, अग्रेषित प्रतिलिपि के साथ प्रत्यक्ष परीक्षण की तुलना करें: अग्रेषित करने से SPF मूल्यांकन बदल सकता है या हस्ताक्षरित सामग्री बदल सकती है। अपने प्रदाता प्राधिकरण में फारवर्डर का पता जोड़कर उन प्रभावों का निदान न करें।

पहुंच का विस्तार किए बिना विफलताओं का निदान करें

पहले सटीक कॉन्फ़िगर किए गए रिकॉर्ड नामों के साथ आधिकारिक DNS तुलना करें, फिर पुनरावर्ती दृश्यता और सेवा सत्यापन की जांच करें। गलत नाम, काटी गई कुंजी या विरोधाभासी CNAME कैश की प्रतीक्षा करके ठीक नहीं किया जाता है। एक मालिक के पास केवल एक SPF नीति रखें और किसी अन्य प्रेषक को मर्ज करने से पहले मूल्यांकन किए गए शामिल और रीडायरेक्ट में दस डीएनएस-लुकअप-टर्म सीमा की जांच करें। DKIM चयनकर्ता व्यक्तिगत हस्ताक्षर विन्यास से संबंधित हैं; सत्यापन परिणाम को बाध्य करने के लिए किसी अन्य एप्लिकेशन के रिकॉर्ड को अधिलेखित न करें।

यदि प्रमाणीकरण पास हो जाता है लेकिन डिलीवरी खराब है, तो प्राप्तकर्ता की प्रतिक्रिया, प्रतिष्ठा, सामग्री और भेजने की अनुमति का अलग से निरीक्षण करें। DMARC पास स्वीकृति या इनबॉक्स प्लेसमेंट का वादा नहीं करता है। यदि कोई भी पथ संरेखित नहीं होता है, तो विस्तार रोकें और वास्तविक प्रेषक कॉन्फ़िगरेशन को ठीक करें। किसी एक उत्पाद की विफलता को छिपाने के लिए पूरे डोमेन की DMARC नीति को कमजोर न करें।

सुपुर्दगी और वसूली

स्वीकृत DNS अंतर, सार्वजनिक लुकअप परिणाम, सेवा स्थिति और संशोधित प्राप्त-संदेश वर्कशीट को नामित स्वामी के साथ सहेजें। क्रेडेंशियल्स और निजी कुंजी को टिकटों से दूर रखें। विफल होने पर, प्रभावित प्रेषण कार्य को रोक दें या सेवा स्वामी के नियंत्रण में पहले से परीक्षण किए गए मार्ग का उपयोग करें। केवल इस एकीकरण से संबंधित परिवर्तित रिकॉर्ड को पुनर्स्थापित करें; इन-फ़्लाइट संदेशों के लिए आवश्यक सार्वजनिक कुंजियाँ रखें। रोलबैक, कुंजी रोटेशन, डोमेन माइग्रेशन या आउटबाउंड रिले में बदलाव के बाद पुनः परीक्षण करें। परिवर्तन तभी बंद करें जब उत्पाद स्वामी और मेल व्यवस्थापक देखी गई पहचान श्रृंखला को समझा सकें।

प्रदाता सीमा की पुष्टि करें

स्रोत का CNAME चित्रण डोमेन-विशिष्ट है, और इसके उत्पाद मेटाडेटा में अन्य Yotpo उत्पादों के लिए अधूरे प्लेसहोल्डर शामिल हैं। केवल स्पष्ट समीक्षा/वफादारी निर्देशों को ही यहां समर्थित मानें। डोमेन प्रमाणीकरण एक भेजने की भूमिका सौंपता है; यह स्थापित नहीं करता है कि किसी व्यक्तिगत लेखक पर भरोसा किया जाता है या प्रत्येक संदेश सुरक्षित है।

एक काल्पनिक निदान मामले पर काम करें

केवल काल्पनिक लिखित मामला: YO-01 मानता है कि समीक्षाओं को reviews@shop.example की आवश्यकता है, लेकिन s1._domainkey.shop.example पहले से ही किसी अन्य अनुमोदित SendGrid एप्लिकेशन को सौंप देता है। कोई योटपो संदेश कैप्चर नहीं किया गया है, इसलिए लिफाफा और DKIM परिणाम अज्ञात हैं। समीक्षा स्वामी को समर्थन के साथ टकराव का खुलासा करना होगा, डोमेन-विशिष्ट वैकल्पिक सेट प्राप्त करना होगा और परीक्षण से पहले अन्य एप्लिकेशन को संरक्षित करना होगा। लॉयल्टी या असंबंधित SendGrid नमूना इस मार्ग को बंद नहीं कर सकता। इस मामले के लिए किसी किरायेदार, DNS , सर्वर कमांड या संदेश का प्रयोग नहीं किया गया था।

पारित संदेश को प्रवर्तन तत्परता से अलग करें

RFC 9989 धारा 7.4 को डोमेन प्रकाशन के लिए वैध DKIM आवश्यकता है p=reject और अप्रत्यक्ष-मेल अंतरसंचालनीयता के बारे में सावधान करता है। एक एकल संरेखित SPF परिणाम अपने आप में अस्वीकार-नीति रोलआउट को उचित नहीं ठहराता है। इस प्रदाता सेटअप से सभी वैध मार्गों और नीति स्वामित्व की अलग से समीक्षा करें।