A DMARC गलत नाम पर TXT मान पूरी तरह से लिखा जा सकता है और फिर भी उस संदेश के लिए अप्रासंगिक हो सकता है जिसकी आप जांच कर रहे हैं। इसकी नीति बदलने से पहले, साबित करें कि प्राप्तकर्ता इसे दृश्यमान पते में उपयोग किए गए डोमेन के लिए खोज सकता है।
एक सामान्य जाल कंपनी की वेबसाइट डोमेन का परीक्षण करना है जबकि एप्लिकेशन एक उपडोमेन के रूप में भेजता है। दूसरा DNS फ़ील्ड में पूर्णतः योग्य नाम दर्ज करना है जो ज़ोन नाम जोड़ता है। इलाज एक सटीक नाम तुलना है, जिसके बाद आधिकारिक DNS साक्ष्य दिया जाता है।
संदेश से लुकअप नाम प्राप्त करें
प्रभावित वर्कफ़्लो से प्राप्त संदेश लें और उसके प्रेषक पते में डोमेन की पहचान करें। notices@billing.example.com से एक सिंथेटिक संदेश के लिए, प्रारंभिक नीति खोज _dmarc.billing.example.com पर TXT सवाल उठाती है। एक अभिलिखित example.com , www.example.com या भेजने वाले विक्रेता के असंबंधित डोमेन पर समान लुकअप नहीं है। यदि प्रारंभिक लुकअप में कोई वैध नीति नहीं मिलती है, तो लागू DMARC नियमों के तहत खोज जारी रह सकती है। RFC 9989 , अनुभाग 4.10.1.
का स्थानापन्न न करें Return-Path दृश्यमान डोमेन के लिए डोमेन। अंतर्गत RFC 7208 §2.4, लिफाफे की पहचान मायने रखती है SPF, लेकिन यह इस प्रारंभिक DMARC नीति लुकअप को निर्धारित नहीं करता है। समस्या का निदान करते समय दोनों फ़ील्ड को अलग-अलग कॉलम में रखें।
DNS संपादक खोलने से पहले अपेक्षित पूर्ण स्वामी का नाम लिखें। यह छोटा कदम यूआई के लेबल को सच्चाई का स्रोत बनने से रोकता है।
आधिकारिक क्षेत्र और इनपुट मॉडल खोजें
कौन सा पहचानें नेमसर्वर वर्तमान में संबंधित क्षेत्र में सेवा प्रदान करते हैं। एक रजिस्ट्रार खाता, होस्टिंग डैशबोर्ड या पहले उपयोग की गई DNS सेवा ऐसे रिकॉर्ड प्रदर्शित कर सकती है जो अब आधिकारिक नहीं हैं। यदि billing.example.com को प्रत्यायोजित किया गया है, तो पेरेंट को संपादित करने से पहले यह स्थापित करें कि उस चाइल्ड ज़ोन को कौन नियंत्रित करता है।
इसके नाम या होस्ट फ़ील्ड के लिए संपादक की सहायता की जाँच करें। कुछ इंटरफ़ेस सापेक्ष नाम स्वीकार करते हैं; कुछ लोग पूरे नाम स्वीकार करते हैं और उन्हें सामान्य बनाते हैं। ज़ोन-फ़ाइल कन्वेंशन वेब फ़ॉर्म के बारे में कोई वादा नहीं है। DNS मास्टर फ़ाइलों में, एक बिंदु पर समाप्त होने वाला नाम पूर्ण होता है, जबकि एक सापेक्ष नाम की व्याख्या वर्तमान मूल का उपयोग करके की जाती है। RFC 1035 , खंड 5.1.
As a documented UI example, Cloudflare 's current record workflow says to choose the record type and complete the required fields, which vary by record. प्रदाता के वर्तमान रिकॉर्ड निर्देशों का उपयोग करें और किसी अन्य प्रदाता के फ़ील्ड व्यवहार को उस पर प्रोजेक्ट करने के बजाय सहेजे गए परिणाम को सत्यापित करें। Cloudflare DNS रिकॉर्ड प्रबंधन.
दोहरे नाम वाले मामले पर काम करें
ज़ोन example.com के लिए कॉन्फ़िगर किए गए एक उदाहरण संपादक पर विचार करें जो ज़ोन को प्रत्येक संबंधित नाम मान में जोड़ता है। _dmarc.example.com सापेक्ष मान के रूप में दर्ज करने से _dmarc.example.com.example.com बन जाएगा। उस आकस्मिक नाम पर इंगित एक सत्यापनकर्ता एक रिकॉर्ड ढूंढ सकता है, जबकि इच्छित _dmarc.example.com लुकअप में कोई रिकॉर्ड नहीं है।
तीन वस्तुओं की स्पष्ट रूप से तुलना करें:
- इच्छित पूर्ण स्वामी: _dmarc.example.com ।
- सहेजा गया स्वामी DNS सेवा या ज़ोन निर्यात द्वारा दिखाया गया है।
- इच्छित और संदिग्ध आकस्मिक नामों दोनों के लिए आधिकारिक TXT उत्तर।
यदि गलत नाम वाले उत्तर में इच्छित नीति शामिल है, तो इसे साक्ष्य के रूप में सुरक्षित रखें। स्वीकृत रिकॉर्ड को इच्छित स्वामी के यहां प्रकाशित या सही करें, इस बात का ध्यान रखें कि वहां कोई दूसरा DMARC उम्मीदवार पेश न हो। यह जांचने के बाद कि इसका कोई अलग से उपयोग नहीं किया गया है, सामान्य परिवर्तन नियंत्रण के माध्यम से गलत रिकॉर्ड को हटा दें। इस आलेख के उदाहरण नाम को अपना उत्पादन डोमेन न मानें।
बिना किसी गलत समय सीमा के मरम्मत की पुष्टि करें
सटीक स्वामी और रिकॉर्ड प्रकार के लिए आधिकारिक सेवा से पूछें। फिर टाइमस्टैम्प, प्रतिक्रिया स्थिति और टीटीएल को ध्यान में रखते हुए पुनरावर्ती रिज़ॉल्वर के उत्तर की तुलना करें। यदि इच्छित नाम पहले मौजूद नहीं था, तो एक नकारात्मक कैश अपने शेष जीवनकाल के लिए उस पिछले परिणाम को लौटाना जारी रख सकता है। एक नया चुना गया सकारात्मक TXT TTL पुराने नकारात्मक कैश को नहीं मिटाता है। RFC 2308 §3, RFC 2308 §4 और RFC 2308 §5.
अर्हक बासी-उत्तर का उपयोग टीटीएल समाप्ति के बाद भी जारी रह सकता है RFC 8767 §4, इसलिए टीटीएल वैश्विक अभिसरण समय सीमा नहीं है। डैशबोर्ड सेव नोटिफिकेशन फॉर्म एक्शन की पुष्टि करता है, वैश्विक दृश्यता की नहीं। इसी तरह, एक सही सार्वजनिक DNS उत्तर यह स्थापित नहीं करता है कि आपकी सेवा एक संरेखित डोमेन के साथ मेल पर हस्ताक्षर करती है। मूल मार्ग के माध्यम से एक ताज़ा संदेश भेजें और प्राप्तकर्ता प्रणाली के विश्वसनीय परिणाम का निरीक्षण करें।
मेल प्रमाणीकरण से अलग नामकरण समस्या को बंद करें
परिवर्तन रिकॉर्ड में मूल स्वामी का नाम, संशोधित स्वामी, स्वीकृत मूल्य और परीक्षण टाइमस्टैम्प रखें। यदि DMARC अब लागू होता है लेकिन संदेश विफल हो जाता है, तो जारी रखें पहचान और संरेखण निदान. यह प्रगति है: रिकॉर्ड पाया जा सकता है, और शेष मुद्दा भेजने के पथ से संबंधित है।
यदि प्राप्तकर्ता अभी भी विभिन्न नीतियों की खोज करते हैं, तो उनके देखे गए डोमेन, DNS उत्तरों और कार्यान्वयन व्यवहार की तुलना करें। केवल दो असंबंधित चेकर्स को सहमत कराने के लिए नामों के बीच सही रिकॉर्ड न रखें।
उस निर्णय को रिकॉर्ड करें जिसकी समीक्षा की जा सके
दोहरे नाम वाले फिक्स्चर के लिए, TXT मान बदलने से पहले इच्छित और सहेजे गए निरपेक्ष नामों की तुलना करें। आकस्मिक स्वामी के पास पाई गई एक वैध पॉलिसी यह नहीं दिखाती है कि इच्छित प्रारंभिक लुकअप इसे ढूंढता है। आकस्मिक रिकॉर्ड को साक्ष्य के रूप में सुरक्षित रखें, फिर अलग से अनुमोदित सुधार और हटाने की कार्रवाइयों का उपयोग करें। यह एक उदाहरणात्मक संपादक मॉडल है, यह दावा नहीं है कि Cloudflare इस तरह से नाम जोड़ता है या कोई DNS परिवर्तन किया गया था।