एक सेकंड जोड़ रहा हूँ DMARC नीति पहले वाले को अद्यतन करने का कोई तरीका नहीं है। दोनों मान एक संयुक्त निर्देश नहीं बनते हैं, और DNS उनके लिए एक आदेशित "नवीनतम नीति जीत" नियम प्रदान नहीं करता है।
मरम्मत पूर्णता से शुरू होती है TXT रिकॉर्ड प्रभावित नाम पर सेट करें. पहचानें कि वर्तमान-संस्करण नीति के कितने उम्मीदवार मौजूद हैं, प्रदर्शन स्वरूपण से उनकी सीमाओं को अलग करें और संपादन से पहले स्वामी की इच्छित नीति का समाधान करें।
सटीक DNS स्वामी का निरीक्षण करें
संदेश के प्रेषक पते में डोमेन से प्रारंभ करें। लागू _dmarc नाम को क्वेरी करें और टाइमस्टैम्प के साथ आधिकारिक और प्रासंगिक पुनरावर्ती उत्तर रिकॉर्ड करें।
एक रूट-डोमेन नीति और एक स्पष्ट उपडोमेन नीति अलग-अलग नामों से प्रकाशित की जाती है। वे केवल इसलिए डुप्लिकेट नहीं हैं क्योंकि दोनों मौजूद हैं। उनका रिश्ता खोज और दायरे से संचालित होता है। उपडोमेन-नीति मार्गदर्शिका बताता है कि उस रिश्ते का आकलन कैसे किया जाए।
इसी तरह, डोमेन रूट पर एक नीति TXT प्रासंगिक _dmarc नाम का विकल्प नहीं है। कई स्थानों पर रिकॉर्ड जोड़ने और प्राप्तकर्ता द्वारा किसी एक को चुनने की आशा करने के बजाय इच्छित स्वामी की मरम्मत करें।
किसी रिकॉर्ड को उसके कैरेक्टर स्ट्रिंग से अलग करें
एक एकल TXT संसाधन रिकॉर्ड में एक से अधिक वर्ण स्ट्रिंग हो सकते हैं। DMARC नीचे पार्सिंग से पहले उन स्ट्रिंग्स को क्रम में जोड़ता है RFC 9989 §4.5. स्ट्रिंग्स के चारों ओर प्रदर्शित उद्धरण सामान्यतः लुकअप टूल का प्रतिनिधित्व होते हैं।
यह सिंथेटिक ज़ोन-शैली फिक्सचर एक TXT रिकॉर्ड है:
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; " "rua=mailto:reports@example.com"
इसके संयोजित मान में p और rua टैग के बीच एक विभाजक और स्थान होता है क्योंकि उन वर्णों को स्ट्रिंग्स के अंदर शामिल किया गया था। जब कोई रिज़ॉल्वर उन्हें जोड़ता है तो वह एक लापता विभाजक का आविष्कार नहीं करता है।
इसके विपरीत, दो अलग-अलग TXT संसाधन रिकॉर्ड दो रिकॉर्ड हैं। उन्हें किसी स्प्रेडशीट या घटना नोट में न जोड़ें और फिर उस आविष्कृत मूल्य का विश्लेषण न करें।
नीतिगत उम्मीदवारों की गिनती से पहले फ़िल्टर करें
The RFC 9989 §4.10 DNS ट्री वॉक उन रिकॉर्ड्स को हटा देता है जो वर्तमान संस्करण की पहचान करने वाले वी टैग से शुरू नहीं होते हैं। यदि एक लक्ष्य पर एकाधिक DMARC नीति रिकॉर्ड लौटाए जाते हैं, तो यह उन सभी को उस लक्ष्य पर छोड़ देता है।
इसलिए समान नाम पर एक असंबंधित TXT मान स्वचालित रूप से दूसरी DMARC नीति नहीं है। प्रत्येक मूल रिकॉर्ड को संरक्षित करने और परिभाषित फ़िल्टरिंग लागू करने के बाद संबंधित उम्मीदवारों की गणना करें।
निम्नलिखित सिंथेटिक फिक्स्चर हैं, लाइव लुकअप परिणाम नहीं:
- एक लक्ष्य पर रिकॉर्ड सेट: एक वर्तमान-संस्करण DMARC उम्मीदवार; जांच करने के लिए व्याख्या: उस उम्मीदवार और उसके नीति शब्दार्थ को पार्स करें
- एक लक्ष्य पर रिकॉर्ड सेट: एक DMARC उम्मीदवार प्लस असंबंधित वर्णनात्मक TXT ; जांच के लिए व्याख्या: असंबंधित TXT दूसरा DMARC नीति उम्मीदवार नहीं है
- एक लक्ष्य पर रिकॉर्ड सेट: v=DMARC1; जांच करने के लिए व्याख्या: प्रतिस्पर्धी नीति उम्मीदवार; कोई विलय या अंतिम-रिकॉर्ड चयन नहीं
- एक लक्ष्य पर रिकॉर्ड सेट: दो कैरेक्टर स्ट्रिंग से बना एक रिकॉर्ड; जांच करने के लिए व्याख्या: इसके तारों को क्रम में जोड़ें, फिर पार्स करें
अंतर्गत RFC 9989 §4.7, संस्करण टैग पहले सटीक मान DMARC1 के साथ दिखना चाहिए। एक स्ट्रिंग जो केवल उस पाठ का उल्लेख करती है बाद में परिभाषित रिकॉर्ड पहचान के लिए प्रतिस्थापन नहीं है।
एक त्रुटि लेबल का वादा करने के बजाय परिणाम का पता लगाएं
आरंभिक लुकअप में एकाधिक पॉलिसी उम्मीदवार उस नाम पर कोई वैध पॉलिसी नहीं छोड़ सकते हैं। अंतर्गत RFC 9989 §4.10.1, वर्तमान खोज तब लागू DNS ट्री वॉक के माध्यम से जारी रह सकती है। अन्यत्र पाई जाने वाली उपयोगी नीति संदेश को प्रभावित कर सकती है।
उदाहरण के लिए, एक काल्पनिक उपडोमेन फिक्सचर में, _dmarc.alerts.example.com पर दो उम्मीदवारों को हटा दिया जाता है। यदि खोज के बाद किसी लागू वैध नीति का पता चलता है संगठनात्मक डोमेन, वह नीति लागू हो सकती है। यदि संपूर्ण खोज में कोई नहीं मिलता है, तो DMARC संदेश पर लागू नहीं होता है।
यह वादा न करें कि प्रत्येक डुप्लिकेट समान उत्पादन करता है Authentication-Results कार्यान्वयन में लेबल या SMTP प्रतिक्रिया। प्राप्तकर्ता के वास्तविक परिणाम और उसके लागू खोज पथ को सुरक्षित रखें।
DNS बदलने से पहले एक अनुमोदित नीति का मिलान कर लें
निर्धारित करें कि कौन से मूल्य जानबूझकर हैं। हो सकता है कि दो रिकॉर्ड अलग-अलग टीमों द्वारा बनाए गए हों, पुराने रिपोर्टिंग एकीकरण द्वारा या डेटा को बदलने के बजाय जोड़े गए माइग्रेशन द्वारा।
एक सुसंगत अनुमोदित मूल्य बनाएँ। इच्छित रिपोर्ट गंतव्यों और समीक्षा को सुरक्षित रखें संरेखण, उपडोमेन दायरा और परीक्षण सेटिंग्स। यदि कई समग्र प्राप्तकर्ता अधिकृत हैं, तो अल्पविराम से अलग की गई रूआ गंतव्य सूची परिभाषित की गई है RFC 9989 §4.7 एक नीति में उस अनुरोध को व्यक्त कर सकते हैं; इसके लिए एकाधिक पॉलिसी TXT रिकॉर्ड की आवश्यकता नहीं है।
किसी भी आवश्यक बाहरी रिपोर्टिंग अनुमति को अलग से सत्यापित करें RFC 9990 §4. गंतव्य पते का संयोजन उस गंतव्य पर अनुमति नहीं देता है जिसे आप नियंत्रित नहीं करते हैं।
सुधार करें और सत्यापित करें
पहले की स्थिति को सहेजें, स्वीकृत बाद की स्थिति, मालिक का नाम, टीटीएल और परिवर्तन प्राधिकरण को पूरा करें। प्रतिस्पर्धी उम्मीदवारों को उस नाम पर इच्छित एकल नीति से बदलें।
फिर नए रिकॉर्ड सेट के लिए आधिकारिक सर्वर की जांच करें और प्रासंगिक पुनरावर्ती दृश्यों की जांच करें। पहले कैश किए गए मान कुछ समय तक बने रह सकते हैं, इसलिए एक वर्तमान आधिकारिक उत्तर इस बात का प्रमाण नहीं है कि प्रत्येक रिसीवर ने पुराने सेट को त्याग दिया है।
एक प्रतिनिधि संदेश परीक्षण चलाएँ और उसके विश्वसनीय प्रमाणीकरण और नीति परिणामों का निरीक्षण करें। DNS सुधार एक वैध कॉन्फ़िगरेशन निर्भरता स्थापित करता है; यह असंबंधित नहीं बनाता है DKIM हस्ताक्षर किसी एप्लिकेशन के लिफाफे की पहचान को संरेखित या सही करना।
उपयोग रिकॉर्ड वर्कफ़्लो प्रकाशन और संदेश सत्यापन को जोड़ने के लिए।
अगले एकीकरण पर उसी विरोध को रोकें
डोमेन को एक नीति स्वामी दें और आँख बंद करके दूसरी नीति जोड़ने के बजाय मौजूदा रिकॉर्ड में अंतर प्रस्तावित करने के लिए एकीकरण की आवश्यकता है। प्रत्येक रिपोर्टिंग गंतव्य के व्यावसायिक उद्देश्य और जीवनचक्र को बनाए रखें।
एक उपयोगी माइग्रेशन हैंडऑफ़ नाम जो अप्रचलित कॉन्फ़िगरेशन को हटाता है और जो परिणामी रिकॉर्ड सेट को सत्यापित करता है। स्थायी समाधान प्रत्येक प्रासंगिक नाम पर एक जानबूझकर नीति है, जिसमें खोज, रिपोर्टिंग और वास्तविक मेल व्यवहार को समझा जाता है।
निर्णय और साक्ष्य को अलग रखें
स्प्लिट-स्ट्रिंग फिक्स्चर के लिए, पहली स्ट्रिंग अर्धविराम और स्पेस के साथ समाप्त होती है, इसलिए इसे रुआ के साथ जोड़ने से एक सुसंगत मान प्राप्त होता है। प्रदर्शन क्रम की परवाह किए बिना, दो अलग-अलग रिकॉर्ड दो उम्मीदवार बने रहते हैं। पूर्ण-खोज परिणाम को एकल-नाम दोष से अलग रखें। RFC 8767 §4 इसका मतलब यह भी है कि टीटीएल समाप्ति कैश्ड डेटा के लिए गारंटीशुदा वैश्विक निष्कासन की समय सीमा नहीं है। फिक्स्चर प्रकाशित या पूछताछ नहीं की गई थी।