[ DMARC और नीति ]

एकाधिक DMARC रिकॉर्ड: प्रभावित नाम पर रिकॉर्ड सेट की मरम्मत करें

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

EmailAuth अनुसंधान टीम द्वारा · 6 मिनट पढ़ा

[ प्रमुख बिंदु ]

  • अलग TXT स्ट्रिंग्स, अलग रिकॉर्ड और अलग मालिक के नाम।
  • वर्तमान उम्मीदवार फ़िल्टरिंग और उसके बाद की खोज का पता लगाएं।
  • एक सुसंगत नीति को मंजूरी दें और रिपोर्टिंग और मेल को अलग से सत्यापित करें।
इस पेज पर

एक सेकंड जोड़ रहा हूँ 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 इसका मतलब यह भी है कि टीटीएल समाप्ति कैश्ड डेटा के लिए गारंटीशुदा वैश्विक निष्कासन की समय सीमा नहीं है। फिक्स्चर प्रकाशित या पूछताछ नहीं की गई थी।

[ ले लेना ]

अलग TXT स्ट्रिंग्स, अलग रिकॉर्ड और अलग मालिक के नाम। वर्तमान उम्मीदवार फ़िल्टरिंग और उसके बाद की खोज का पता लगाएं। एक सुसंगत नीति को मंजूरी दें और रिपोर्टिंग और मेल को अलग से सत्यापित करें।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

आईटी/मेल एडमिन

रिकॉर्ड सीमाओं को सुरक्षित रखें और खोज का पता लगाएं।

एक TXT डिस्प्ले स्ट्रिंग्स और संसाधन रिकॉर्ड के बीच अंतर छुपा सकता है।

अगले कदम

  1. संपूर्ण आधिकारिक और पुनरावर्ती उत्तर कैप्चर करें.
  2. गिनती से पहले वर्तमान-संस्करण वाले उम्मीदवारों को फ़िल्टर करें।
  3. सही नीति और वास्तविक संदेश संरेखण का परीक्षण करें।

सीआईएसओ/सेकऑप्स

मरम्मत के दौरान विश्वास और रिपोर्टिंग के दायरे की समीक्षा करें।

मूल्यों के संयोजन से रिकॉर्ड की संख्या से अधिक परिवर्तन हो सकता है।

अगले कदम

  1. परिणामी संरेखण और उपडोमेन नीति को अनुमोदित करें।
  2. प्रत्येक रिपोर्टिंग प्राप्तकर्ता की समीक्षा करें.
  3. अप्रचलित एकीकरण कॉन्फ़िगरेशन को स्पष्ट रूप से रिटायर करें।

संस्थापक/गैर-तकनीकी

एक मालिक को पॉलिसी के लिए जवाबदेह बनाएं।

एक नए एकीकरण को उसी डोमेन के लिए प्रतिस्पर्धी निर्देश नहीं बनाना चाहिए।

अगले कदम

  1. टूल ऑनबोर्डिंग से पहले नीति का स्वामित्व निर्दिष्ट करें।
  2. परिवर्तन से पहले और बाद में पठनीय की आवश्यकता है।
  3. किसी महत्वपूर्ण मेल रूट पर सुधार की पुष्टि करें.

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

क्या दो TXT कैरेक्टर स्ट्रिंग हमेशा दो DMARC रिकॉर्ड होते हैं?

नहीं, एक TXT संसाधन रिकॉर्ड में कई स्ट्रिंग हो सकते हैं। DMARC पार्सिंग से पहले उन स्ट्रिंग्स को क्रम से जोड़ता है; अलग-अलग संसाधन रिकॉर्ड अलग-अलग रहते हैं।

RFC 9989 §4.5

क्या DNS अंतिम या नवीनतम DMARC रिकॉर्ड चुनता है?

ऐसा कोई नीति-चयन नियम लागू नहीं होता. संसाधन रिकॉर्ड के प्रदर्शन क्रम या प्रतिस्पर्धी नीतियों को मर्ज करने पर निर्भर न रहें।

RFC 9989 §4.10

क्या प्रत्येक अतिरिक्त TXT रिकॉर्ड को डुप्लिकेट DMARC नीति के रूप में गिना जाता है?

नहीं, रिकॉर्ड सीमाएँ सुरक्षित रखें और वर्तमान-संस्करण रिकॉर्ड-पहचान नियम लागू करें। असंबंधित TXT डेटा स्वचालित रूप से दूसरा पॉलिसी उम्मीदवार नहीं है।

RFC 9989 §4.10

क्या माता-पिता और उपडोमेन प्रत्येक का अपना DMARC रिकॉर्ड हो सकता है?

हाँ। वे अलग-अलग स्वामी के नाम हैं, और खोज किसी संदेश पर लागू नीति निर्धारित करती है। उनका सह-अस्तित्व एक नाम पर दोहराव नहीं है।

RFC 9989 §4.10.1

क्या डुप्लिकेट पॉलिसी उम्मीदवार हमेशा एक ही स्थायी त्रुटि का कारण बनेंगे?

एक सार्वभौमिक लेबल या SMTP परिणाम न मानें। RFC 9989 एक लक्ष्य पर एकाधिक नीति उम्मीदवारों को हटा देता है, और शेष खोज पथ प्रभावित कर सकता है कि किसी अन्य नीति का उपयोग किया जाता है या नहीं।

RFC 9989 §4.10 RFC 9989 §4.10.1

हम दो गंतव्यों पर रिपोर्ट का अनुरोध कैसे कर सकते हैं?

एक नीति के भीतर एक अनुमोदित अल्पविराम से अलग किए गए आरयूए यूआरआई सूची का उपयोग करें। प्रत्येक प्रासंगिक गंतव्य के लिए आवश्यक बाहरी-गंतव्य प्राधिकरण और वास्तविक संग्रह को सत्यापित करें।

RFC 9989 §4.7 RFC 9990 §4

क्या डुप्लिकेट रिकॉर्ड ठीक करने से यह साबित होता है कि हमारा मेल DMARC पास है?

नहीं, रिकॉर्ड-सेट की मरम्मत के बाद प्रतिनिधि संदेश की वास्तविक पहचान, प्रमाणीकरण और संरेखण सत्यापित करें।

RFC 9989 §5.3.5

अगले विक्रेता एकीकरण के दौरान हम इससे कैसे बचेंगे?

डोमेन के पॉलिसी स्वामी को अप्रचलित मूल्यों और गंतव्यों की सेवानिवृत्ति सहित मौजूदा संपूर्ण रिकॉर्ड में प्रस्तावित परिवर्तन की समीक्षा करने की आवश्यकता है।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 9989

    धारा §4.5 · §4.7 · §4.10 · §4.10.1 · §5.3.5 · §3.2.6

  2. RFC 9990

    धारा §4

  3. RFC 8767

    धारा §4

[ शब्दकोष ]

शब्दकोष

DMARC नीति रिकॉर्ड
एक DNS TXT रिकॉर्ड जो सत्यापन को सक्षम करता है और लागू डोमेन के लिए हैंडलिंग प्राथमिकताओं और वैकल्पिक रिपोर्टिंग अनुरोधों को व्यक्त करता है।

RFC 9989 §3.2.6

TXT वर्ण स्ट्रिंग
DMARC के क्रम में एक TXT रिकॉर्ड के भीतर एकाधिक स्ट्रिंग्स को संयोजित किया जाता है; अलग-अलग रिकॉर्ड संयुक्त नहीं हैं.

RFC 9989 §4.5

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

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

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार