सही खाता और DNS एक्सेस इकट्ठा करें
फ़्लोडेस्क की वर्तमान मैन्युअल प्रक्रिया के लिए एक कस्टम-डोमेन ईमेल पता, फ़्लोडेस्क खाते तक पहुंच और डोमेन के DNS प्रबंधक तक पहुंच की आवश्यकता होती है। यह मानने के बजाय कि रजिस्ट्रार सक्रिय क्षेत्र को होस्ट करता है, पहचानें कि आधिकारिक DNS कौन नियंत्रित करता है। परिवर्तन करने से पहले वर्तमान रिकॉर्ड सुरक्षित रखें, विशेष रूप से अन्य मार्केटिंग टूल या साधारण मेलबॉक्स द्वारा उपयोग किए गए रिकॉर्ड।
तय करें कि क्या डोमेन स्वामी मैन्युअल वर्कफ़्लो का उपयोग करेगा या स्वचालित एंट्री एकीकरण को अधिकृत करेगा। ये आवश्यक रिकॉर्ड प्रकाशित करने के वैकल्पिक तरीके हैं, अलग-अलग प्रमाणीकरण प्रोटोकॉल नहीं। केवल इसलिए कि सत्यापन लंबित है, दोनों को बार-बार न चलाएं।
खाते के मैन्युअल रिकॉर्ड सेट का उपयोग करें
मेरा खाता > डोमेन सेटअप खोलें, डोमेन कार्ड पर अभी प्रमाणित करें चुनें और मैन्युअल विकल्प चुनें। वर्तमान दस्तावेज़ दो संभावित सेटों का वर्णन करता है: पाँच रिकॉर्ड जिसमें एक शामिल है SPF, तीन DKIM और एक DMARC रिकॉर्ड, या तीन रिकॉर्ड जिनमें से प्रत्येक में से एक शामिल है। खाता निर्धारित करता है कि कौन सा सेट लागू होता है। किसी निश्चित गिनती की नकल न करें चयनकर्ता एक असंबंधित ट्यूटोरियल से.
सटीक स्वामी और मूल्य प्राप्त करने के लिए प्रत्येक कॉपी नियंत्रण का उपयोग करें। फ्लोडेस्क निर्दिष्ट करता है CNAME इसकी SPF और DKIM प्रविष्टियों के लिए रिकॉर्ड और ए TXT रिकॉर्ड के लिए DMARC. प्रदर्शित प्रकारों को सुरक्षित रखें. CNAME किसी अन्य नाम का DNS उपनाम है; यह मौजूदा SPF स्ट्रिंग के अंदर चिपकाने के लिए एक टेक्स्ट तंत्र नहीं है।
विशेष रूप से, फ़्लोडेस्क अपने SPF CNAME एक अलग रिकॉर्ड के रूप में जोड़ने के लिए कहता है, न कि इसे मौजूदा SPF TXT नीति के साथ संयोजित करने के लिए। इसका मतलब यह नहीं है कि एक मालिक पर दो v=spf1 पॉलिसियाँ प्रकाशित करना सुरक्षित है। उत्पन्न CNAME का अपना स्वामी और कार्य होता है। यदि उस स्वामी के पास पहले से ही असंगत डेटा है, तो किसी अन्य सेवा को अधिलेखित करने के बजाय DNS व्यवस्थापक के साथ विरोध को रोकें और हल करें।
मौजूदा DMARC निर्णय को सुरक्षित रखें
मैनुअल निर्देश प्रदर्शित DMARC TXT रिकॉर्ड को केवल तभी जोड़ने के लिए कहते हैं यदि कोई DMARC रिकॉर्ड पहले से मौजूद नहीं है। प्रदर्शित नीति बिना नीति वाले सदस्यों के लिए है। दूसरा DMARC रिकॉर्ड न बनाएं या किसी स्थापित अस्वीकार या संगरोध नीति को सेटअप उदाहरण से न बदलें।
डोमेन व्यवस्थापक के साथ सटीक नीति स्वामी और वर्तमान कॉन्फ़िगरेशन की जाँच करें। प्रमाणीकरण सफलता के लिए लागू मोड के तहत एक वैध संरेखित SPF या DKIM पथ की आवश्यकता होती है; किसी नीति को प्रकाशित करना इस बात का प्रमाण नहीं है कि अभियान उसे संतुष्ट करते हैं। संगठन की रिपोर्टिंग और प्रवर्तन निर्णयों को फ़्लोडस्क के जेनरेट किए गए रिकॉर्ड जोड़ने की प्रक्रिया से अलग रखें।
अनावश्यक पुनरारंभ के बिना सत्यापन समाप्त करें
रिकॉर्ड प्रकाशित करने के बाद, फ़्लोडस्क पर लौटें और नेक्स्ट एंड डन के साथ समाप्त करें। सेवा स्वचालित रूप से DNS निगरानी करती है। दस्तावेज़ में 48 घंटों तक की बताई गई विंडो के दौरान लंबित और आंशिक-सत्यापन स्थितियों का वर्णन किया गया है। इसे प्रदाता मार्गदर्शन के रूप में मानें, न कि एक सार्वभौमिक गारंटी के रूप में कि प्रत्येक DNS दोष दो दिनों के बाद स्वयं हल हो जाता है।
विभिन्न रिकॉर्ड दृश्यमान होने पर आंशिक स्थिति उत्पन्न हो सकती है। पहले आधिकारिक उत्तरों की तुलना खाते के सटीक रिकॉर्ड सेट से करें। डुप्लिकेट किए गए डोमेन प्रत्यय, गलत रिकॉर्ड प्रकार, गलत CNAME लक्ष्य और निष्क्रिय DNS होस्ट पर किए गए संपादन की जाँच करें। यदि सही रिकॉर्ड दिखाई दे रहे हैं लेकिन दस्तावेज़ित विंडो के बाद भी स्थिति अनसुलझी है, तो प्रमाणीकरण को बार-बार पुनरारंभ करने के बजाय समर्थन के लिए रिकॉर्ड सेट और स्थिति एकत्र करें।
स्वचालित विकल्प को समझें
डोमेन सेटअप के अंतर्गत स्वचालित प्रवाह भी प्रारंभ हो जाता है. स्वचालित प्रमाणीकरण चुनें और डोमेन प्रदाता को एंट्री के माध्यम से कनेक्ट करें। स्वामी DNS रिकॉर्ड जोड़ने के लिए Entri के लिए आवश्यक पहुंच को अधिकृत करता है। अनुमोदन देने से पहले अनुरोधित पहुंच और इच्छित परिवर्तनों की समीक्षा करें; एकीकरण एक तृतीय पक्ष है, न कि केवल DNS संपादक का एक अलग दृष्टिकोण।
फ्लोडेस्क का कहना है कि एक असमर्थित प्रदाता मैन्युअल विकल्प की ओर ले जाता है। यदि स्वचालित सेटअप समाप्त नहीं होता है, तो तरीकों को बदलने से पहले निरीक्षण करें कि वास्तव में क्या बनाया गया था। डुप्लिकेट नीतियों या कामकाजी रिकॉर्ड के आकस्मिक प्रतिस्थापन से बचें। DNS होस्ट को बाद में बदलने के लिए इन रिकॉर्ड्स को नए आधिकारिक क्षेत्र में संरक्षित करने की भी आवश्यकता होती है; केवल रजिस्ट्रार परिवर्तन ही इस बात का प्रमाण नहीं है कि DNS स्थानांतरित हो गया है या रिकॉर्ड खो गए हैं।
किसी अभियान को सत्यापित करें, न कि केवल डोमेन कार्ड को
उत्पादन वर्कफ़्लो के माध्यम से एक नियंत्रित ईमेल को एक मेलबॉक्स पर भेजें जहाँ मूल हेडर का निरीक्षण किया जा सके। दृश्यमान डोमेन, लिफ़ाफ़ा डोमेन, प्रत्येक DKIM हस्ताक्षरित डोमेन और चयनकर्ता, और विश्वसनीय रिसीवर के प्रमाणीकरण परिणामों को रिकॉर्ड करें। गुजरने वाले पथ की पुष्टि करें संरेखण यह मानने के बजाय कि एक सत्यापित कार्ड भविष्य के हर मार्ग की गारंटी देता है।
उदाहरणात्मक मामला, फ्लोडेस्क अवलोकन नहीं: से hello@example.com है और DKIM d=example.com. यह सटीक DKIM संरेखण प्रदान करता है। यदि कोई असंबद्ध लिफ़ाफ़ा डोमेन SPF पास करता है, तो वह परिणाम अकेले example.com के साथ संरेखित नहीं होता है। दोनों परिणामों को सुरक्षित रखें ताकि बाद में हस्ताक्षर करने में विफलता किसी असंबंधित SPF पास द्वारा छिपाई न जाए।
पुनर्प्राप्ति रिकॉर्ड रखें और किसी भी DNS-होस्ट माइग्रेशन को पूर्ण घोषित करने से पहले उसका परीक्षण करें। प्रमाणीकरण इनबॉक्स प्लेसमेंट की गारंटी नहीं देता है; प्रतिष्ठा, संदेश सामग्री और प्राप्तकर्ता के निर्णय अलग-अलग रहते हैं। यह मार्गदर्शिका केवल प्रथम-पक्ष दस्तावेज़ीकरण और सिंथेटिक उदाहरण को बरकरार रखती है। कोई वास्तविक DNS परिवर्तन, किरायेदार सत्यापन या प्राप्त अभियान निष्पादित नहीं किया गया था, और मानव उत्पादन अनुमोदन लंबित है।
लक्ष्य का अनुमान लगाए बिना रिकॉर्ड टकराव का समाधान करें
लिखित मामले FL-01 के लिए, मान लें कि फ्लोडेस्क पैनल bounce.example.com के रूप में यहां दर्शाए गए जेनरेटेड मालिक से CNAME का अनुरोध करता है, लेकिन DNS इन्वेंट्री से पता चलता है कि वही मालिक पहले से ही काम कर रहा है एक अभिलिखित किसी असंबंधित सेवा के लिए. यह स्वामी उदाहरणात्मक है, वास्तविक फ़्लोडस्क-जनरेटेड लेबल नहीं; अनुरोधित CNAME लक्ष्य अज्ञात है. A रिकॉर्ड को अधिलेखित न करें या लक्ष्य को रूट SPF TXT में पेस्ट न करें। DNS मालिक को निर्भरता की पहचान करनी होगी और आगे बढ़ने से पहले प्रदाता के साथ समर्थित संघर्ष समाधान पर सहमत होना होगा। मौजूदा DMARC नीति को अपरिवर्तित रखें और अभियान को असत्यापित रखें। इस मामले के लिए कोई DNS उत्तर, खाता अनुदान या संदेश प्राप्त नहीं हुआ था।
प्रवर्तन सीमा को सुरक्षित रखें
RFC 9989 धारा 7.4 में डोमेन प्रकाशन के लिए वैध DKIM की आवश्यकता है, अकेले SPF नहीं p=reject, और अप्रत्यक्ष-मेल और मेलिंग-सूची अंतरसंचालनीयता के बारे में चेतावनी देता है। एक भी सफल प्रत्यक्ष-संदेश परीक्षण इस बात का प्रमाण नहीं है कि हर वैध मार्ग मजबूत नीति के लिए तैयार है। वास्तविक अंतर का निदान करते समय मौजूदा अनुमोदित सुरक्षा बनाए रखें; किसी भी नीति परिवर्तन के लिए अपने स्वयं के निर्णय की आवश्यकता होती है।