ईमेल सेवा जोड़ने से मुख्य होने पर भी आपकी प्रेषण संपत्ति बदल जाती है DMARC रिकॉर्ड अछूता रहता है. एक नया खरीदा गया बिलिंग प्लेटफ़ॉर्म, सपोर्ट डेस्क या मार्केटिंग एप्लिकेशन एक अलग पहचान प्रमाणित करते समय आपके डोमेन को फ्रॉम में प्रदर्शित कर सकता है। ऑनबोर्डिंग को बिज़नेस मेल रूट में बदलाव के रूप में समझें, न कि केवल DNS रिकॉर्ड चिपकाने के अनुरोध के रूप में।
इसका उद्देश्य ग्राहकों पर निर्भर होने से पहले एक स्वामित्व, समर्थित और परीक्षणित प्रेषण पथ स्थापित करना है। समीक्षा छोटी हो सकती है, लेकिन इसमें एप्लिकेशन द्वारा उपयोग किए जाने वाले प्रत्येक वर्कफ़्लो और बाद में इसे बनाए रखने के लिए आवश्यक साक्ष्य शामिल होने चाहिए।
इच्छित प्रेषण दायरे को परिभाषित करें
एप्लिकेशन स्वामी से पूछें कि सेवा कौन से संदेश भेजेगी, उपयोगकर्ता कौन से पते देखेंगे, उन्हें कौन प्राप्त करेगा और क्या एप्लिकेशन में अलग-अलग लेनदेन और विपणन पथ हैं। खाता पुनर्प्राप्ति और शेड्यूल किए गए विवरण जैसे कम-आवृत्ति संचालन शामिल करें।
रिकॉर्ड करें कि प्रदाता खाते को कौन नियंत्रित करता है और इसकी प्रेषक सेटिंग कौन बदल सकता है। तकनीकी प्रमाणीकरण के साथ-साथ खाता सुरक्षा और व्यवसाय अनुमोदन भी रखें। DMARC यह स्थापित नहीं करता है कि कोई विशेष अभियान, चालान या अनुरोध आपके संगठन द्वारा अधिकृत किया गया था।
इच्छित डोमेन जानबूझकर चुनें. एक उपडोमेन एक परिचालन सीमा प्रदान कर सकता है, लेकिन इसकी नीति और संरेखण व्यवहार की जाँच होनी चाहिए. यह न मानें कि मुख्य डोमेन की प्रवर्तन नीति स्वचालित रूप से प्रत्येक बच्चे के वर्कफ़्लो को समान परिणाम देती है। उपयोग उपडोमेन नीति मार्गदर्शिका उस सीमा की योजना बनाते समय।
प्रदाता का वास्तविक कॉन्फ़िगरेशन प्राप्त करें
विशिष्ट उत्पाद और भेजने के तरीके के लिए वर्तमान प्रथम-पक्ष निर्देशों का उपयोग करें। पूछें कि प्रेषक में क्या दिखाई देगा, सेवा किस लिफ़ाफ़ा डोमेन का उपयोग करती है, और क्या यह ग्राहक-डोमेन प्रदान करती है DKIM हस्ताक्षर करना. अकेले डोमेन स्वामित्व सत्यापन यह स्थापित नहीं करता है कि संदेशों पर एक संरेखित पहचान के साथ हस्ताक्षर किए गए हैं।
किसी उदाहरण लेख के बजाय अधिकृत सेवा कॉन्फ़िगरेशन से उत्पन्न DNS मानों की प्रतिलिपि बनाएँ। परिवर्तन करने से पहले सटीक DNS स्वामी के नाम, रिकॉर्ड प्रकार, मौजूदा रिकॉर्ड और क्षेत्र स्वामित्व की जाँच करें। ए चयनकर्ता या किसी अन्य खाते से सत्यापन टोकन पुन: प्रयोज्य टेम्पलेट नहीं है।
यदि सेवा की आवश्यकता है SPF बदलें, स्थापित करें कि किस डोमेन के SPF मूल्यांकन किया गया है और परिवर्तन उसके लुकअप बजट को कैसे प्रभावित करता है RFC 7208 §4.6.4. अंतर्गत RFC 7208 §2.4 और RFC 7208 §4.4, जब सेवा किसी भिन्न लिफाफा डोमेन का उपयोग करती है तो विक्रेता को संगठन के रूट SPF में जोड़ना अप्रासंगिक हो सकता है। अनुरोधित परिवर्तन और उसके औचित्य को एक साथ रखें।
तत्परता मैट्रिक्स को विशिष्ट बनाएं
निम्नलिखित एक सिंथेटिक नियोजन उदाहरण है, अवलोकनित परीक्षण डेटा नहीं। इसके "लंबित" सेल जानबूझकर हैं: अनुमोदन से पहले कॉन्फ़िगरेशन दावों को साक्ष्य के साथ प्रतिस्थापित किया जाना चाहिए।
- वर्कफ़्लो: रसीदें; डोमेन से इरादा:
billing.example.com; आवश्यक साक्ष्य: संरेखित DKIM के साथ प्राप्त रसीद, लिफाफा पहचान और पॉलिसी खोज दर्ज की गई; रिलीज़ निर्णय: परीक्षण लंबित - वर्कफ़्लो: पासवर्ड रीसेट; डोमेन से इरादा:
accounts.example.com; साक्ष्य की आवश्यकता: किसी भी गेटवे सहित वास्तविक एप्लिकेशन पथ के माध्यम से संदेश रीसेट करें; रिलीज़ निर्णय: परीक्षण लंबित - वर्कफ़्लो: अभियान; डोमेन से इरादा:
news.example.com; आवश्यक साक्ष्य: वास्तविक अभियान संदेश, प्रमाणीकरण परिणाम और लागू प्राप्तकर्ता-प्रदाता आवश्यकताएँ; रिलीज़ निर्णय: समीक्षा लंबित
अपने कामकाजी रजिस्टर में मालिक, प्रदाता खाता संदर्भ, स्रोत दस्तावेज़, अंतिम परीक्षण तिथि और रोलबैक कार्रवाई जोड़ें। जब भी सेवा विभिन्न प्रेषक पहचान या वितरण बुनियादी ढांचे का उपयोग करती है तो अलग वर्कफ़्लो। एक सफल रसीद अभियान पथ को प्रमाणित नहीं करती है।
बिना किसी बदलाव के नीति अंतर की समीक्षा करें
मौजूदा नीति को कैप्चर करें और बताएं कि क्या ऑनबोर्डिंग से इसमें बदलाव होता है। यदि नया मार्ग मौजूदा नीति के तहत प्रमाणित और संरेखित होता है तो "कोई DMARC नीति परिवर्तन नहीं" एक वैध परिणाम है। यह अभी भी रिकार्ड करने योग्य निर्णय है।
DMARC की संदेश-स्तरीय पास स्थिति के लिए पासिंग संरेखित पहचान की आवश्यकता होती है। प्रवर्तन परिनियोजन के लिए, मार्ग लचीलेपन पर भी विचार करें: RFC 9989 कहते हैं कि जब लेखक डोमेन नीति लागू हो तो डोमेन मालिक को केवल SPF पर निर्भर नहीं रहना चाहिए p=reject. अकेले डायरेक्ट-मेल SPF परीक्षण पर निर्भर रहने के बजाय समर्थित संरेखित DKIM सत्यापित करें। देखना RFC 9989 §5.3.5 और RFC 9989 §8.
किसी पहले से तैयार एप्लिकेशन को समायोजित करने के लिए डिफ़ॉल्ट रूप से मूल नीति को कम न करें। सबसे पहले प्रेषक की समर्थित पहचान कॉन्फ़िगरेशन को हल करें। यदि एक अस्थायी अपवाद आवश्यक है, तो मालिक, समाप्ति और निकास परीक्षण के साथ एक स्कोप अनुमोदन प्राप्त करें। डिलीवरी में सुधार होगा का एक व्यापक वादा करने के बजाय सटीक जोखिम और प्रभावित डोमेन को रिकॉर्ड करें।
व्यवसाय द्वारा उपयोग किए जाने वाले मार्ग का परीक्षण करें
प्रत्येक वर्कफ़्लो के माध्यम से अधिकृत प्राप्तकर्ताओं को गैर-संवेदनशील उदाहरण भेजें। डोमेन, SPF पहचान, प्रत्येक प्रासंगिक DKIM परिणाम, लागू नीति और DMARC परिणाम से विश्वसनीय प्राप्त प्रणाली को रिकॉर्ड करें। इच्छित मार्ग से संबंधित किसी भी गेटवे या अग्रेषण चरण के बाद परीक्षण करें।
वास्तविक डिलीवरी की अलग से जाँच करें। DMARC पास इनबॉक्स प्लेसमेंट या सभी प्राप्तकर्ता-प्रदाता नियमों की संतुष्टि की गारंटी नहीं देता है। उदाहरण के लिए, Gmail की थोक-प्रेषक आवश्यकताओं में SPF , DKIM और DMARC कॉन्फ़िगरेशन, साथ ही अतिरिक्त डिलीवरी आवश्यकताएं शामिल हैं। वर्तमान से परामर्श करें Gmail प्रेषक दिशानिर्देश जब वह श्रोता प्रासंगिक हो.
केवल उन्हीं कार्यप्रवाहों को स्वीकृत करें जिनके पास पर्याप्त साक्ष्य हों। यदि कम-आवृत्ति वाला कार्य अभी तक नहीं किया जा सकता है, तो पूरे आवेदन को पूर्ण के रूप में चिह्नित करने के बजाय इसे निर्धारित स्वामी कार्रवाई के साथ लंबित रखें।
निगरानी करें और जानबूझकर सेवानिवृत्त हों
बाद की तुलना करें समग्र रिपोर्ट और अपेक्षित प्रेषक पैटर्न के साथ एप्लिकेशन डिलीवरी लॉग। रिपोर्टें ट्रैफ़िक का खुलासा कर सकती हैं, लेकिन स्वयं यह साबित नहीं कर सकतीं कि प्रदाता खाता अधिकृत था या हर दुर्लभ वर्कफ़्लो का प्रयोग किया गया था।
लॉन्च से पहले पुनर्प्राप्ति को परिभाषित करें: प्रभावित भेजने वाले वर्कफ़्लो को अक्षम करें, स्वीकृत प्रेषक कॉन्फ़िगरेशन को पुनर्स्थापित करें या पहले से सत्यापित सेवा के माध्यम से रूट करें जहां समर्थित है। DNS रोलबैक में कैशिंग परिणाम होते हैं, जिसमें टीटीएल समाप्ति के बाद बासी-उत्तर के उपयोग को योग्य बनाना शामिल है RFC 8767 §4, इसलिए यह तत्काल सार्वभौमिक उलटफेर नहीं है।
अंत में, सेवानिवृत्ति की शर्त निर्धारित करें। जब एप्लिकेशन हटा दिया जाता है, तो सफाई से पहले इसकी भेजने की अनुमति, प्रदाता खाता और DNS निर्भरता की समीक्षा करें। अपने पास रखें प्रेषक सूची केवल दिन पर ही नहीं, खरीद, परिवर्तन और सेवानिवृत्ति के माध्यम से चालू DMARC प्रवर्तन सक्षम है.
अगला निर्णय स्पष्ट करें
नियोजन स्थिरता में, एक सत्यापित रसीद पथ रीसेट या अभियान पंक्तियों को साफ़ नहीं करेगा। प्रत्येक वास्तविक परिणाम और साक्ष्य तिथि को रिकॉर्ड करें, या "लंबित" रखें। बिना किसी बदलाव वाले नीतिगत निर्णय के लिए, पहचान कॉन्फ़िगरेशन और परीक्षण किए गए मार्ग को अभी भी रिकॉर्ड करें। नियोजन उदाहरण यह दावा नहीं करते कि कोई एप्लिकेशन खाता, DNS रिकॉर्ड या संदेश परीक्षण मौजूद है।